Как в каменный век откатился и привычных инструментов не хватает. :)

Товарищи, вот мне нужно выделить область памяти под placement new неизвестного типа. Чтобы не ломать strict aliasing можно использовать uin8_t * или нужен обязательно char * для блока памяти?

Вообще, вопрос сводится к тому, можно ли считать uint8_t псевдонимом unsigned char

Вообще, вопрос сводится к тому, можно ли считать uint8_t псевдонимом unsigned char

Нет потомучто он опционален?

Вообще, вопрос сводится к тому, можно ли считать uint8_t псевдонимом unsigned char

Если ты подключишь cstdint, то да Но при выводе не забудь явно указывать что хочешь получить - число или символ

Вообще, вопрос сводится к тому, можно ли считать uint8_t псевдонимом unsigned char

Область значений одна и та же

Если ты подключишь cstdint, то да Но при выводе не забудь явно указывать что хочешь получить - число или символ

я вообще не хочу из него ничего получать, я хочу делать вот так new (mem) Type(), но заранее не знаю Type. В проекте для таких блоков везде uint8_t, вот я и задумался

Если ты подключишь cstdint, то да Но при выводе не забудь явно указывать что хочешь получить - число или символ

uint8_t может вообще быть не определен

В правиле про алиасинг только char и unsigned char допустимы для такого

uint8_t может вообще быть не определен

http://en.cppreference.com/w/cpp/header/cstdint

Oh well

Тупо зделоли

+

Т.е. int16 и int64 не опциональный, а 32 опциональный.

АФИГЕННА

Пахнет genius-ом

я вообще не хочу из него ничего получать, я хочу делать вот так new (mem) Type(), но заранее не знаю Type. В проекте для таких блоков везде uint8_t, вот я и задумался

дак один фиг потом заморачиваться с alignof ведь, иначе может кака получиться

Т.е. int16 и int64 не опциональный, а 32 опциональный.

шта

все точные optional

все точные optional

В топ и суть. cppreference нужно править.

том*

В топ и суть. cppreference нужно править.

на все строку таблицы же

Где?

Oh well

это отвечает ведь байт может быть больше 8 бит

Где?

так fast не optional

только точные

Я думаю там что-то хитрое в контексте текста книги

текст там таков: The work_queue class could be significantly improved by adding support for rvalue references and calling std::move(tasks_.front()). This will make the code in the critical section much faster, resulting in less threads, suspends, and wakeups, less cache misses and a much better performance. Any operation acquires a unique lock on the mutex_ variable, so even getting resources results in waiting on a locked mutex. As some of the resources are hard to copy, the critical sections consume a lot of time, slowing down any operation on the class.

Такой вопрос: Полухин в книжке по бусту пишет, что де код в критических секциях может в разы ускоряться, если все используемое внутри секции будет поддерживать перемещение, а не только копирование. Это как так? Я всегда искренне считал, что все подкапотные сохранения состояния происходят на уровне операционки, которая знай себе байты перекладывает, не заморачиваясь что байты лежат в программе на с++11+, которая умеет в перемещения вместо копирований. Я был, глубоко неправ, или неправильно понял автора?

@antoshkka , пролей свет в этот тред!

текст там таков: The work_queue class could be significantly improved by adding support for rvalue references and calling std::move(tasks_.front()). This will make the code in the critical section much faster, resulting in less threads, suspends, and wakeups, less cache misses and a much better performance. Any operation acquires a unique lock on the mutex_ variable, so even getting resources results in waiting on a locked mutex. As some of the resources are hard to copy, the critical sections consume a lot of time, slowing down any operation on the class.

это просто критическая секция в плане быстродействия или типа того

только точные

А, да, точно. Глаза с утра кривые

а нет стоп

тут просто про содержимое

типа содержимое быстрее

>resulting in less threads, suspends, and wakeups, less cache misses and a much better performance. просто меньше случаев когда захватить сразу ее не удается

>the critical sections consume a lot of time, slowing down any operation on the class тут имеется ввиду код внутри при захваченом мьютексе

К вопросу о пакетных менеджерах. В какой пакетный менеджер завезли libcurl и openssl для андроида под armabi-v7 и x86?

К вопросу о пакетных менеджерах. В какой пакетный менеджер завезли libcurl и openssl для андроида под armabi-v7 и x86?

Про пакетные манагеры не знаю, но в дроиде всю жизнь использовал собранные руками curl и бекенд в виде mbedtls. Полновесный curl тяжеловат будет.

Товарищи, исходя из какого правила компилятор удлинняет время жизни A до конца функции вот здесь; http://www.cpp.sh/8gs2j

Про пакетные манагеры не знаю, но в дроиде всю жизнь использовал собранные руками curl и бекенд в виде mbedtls. Полновесный curl тяжеловат будет.

Собрать libcurl проблемы нет вообще. Собрать openssl куда сложнее, особенно с учетом разных архитектур.

Собрать libcurl проблемы нет вообще. Собрать openssl куда сложнее, особенно с учетом разных архитектур.

Вот потому mbedtls. а какие требования к именно openssl?

Вот потому mbedtls. а какие требования к именно openssl?

Только для поддержки https.

Только для поддержки https.

Тогда mbedtls вам более чем хватит

Тогда mbedtls вам более чем хватит

Благодарю за совет.

Если таки захотите руками собрать, я делаю примерно так; https://github.com/SBKarr/stappler-deps/blob/master/android/curl-android.sh https://github.com/SBKarr/stappler-deps/blob/master/android/mbedtls-android.sh

Товарищи, исходя из какого правила компилятор удлинняет время жизни A до конца функции вот здесь; http://www.cpp.sh/8gs2j

исходя из правила что этот объект существует до точки следования

исходя из правила что этот объект существует до точки следования

то есть, тренарный целиком внутри точки следования? Понял, туплю.

тоесть у тебя там точка следования это до ;

а чем собственно putInt(rnd > RAND_MAX ? &rnd : A().get()); должно отличаться от putInt(A().get());

а чем собственно putInt(rnd > RAND_MAX ? &rnd : A().get()); должно отличаться от putInt(A().get());

Да ничем, просто мозг заклинило, мне тут коллега рассказывал ужастики про тренарки.

Не подскажет ли кто быстрый и универсальный алгоритм разбиения произвольного многоугольника (в том числе дырявого) на простые выпуклые?

Не подскажет ли кто быстрый и универсальный алгоритм разбиения произвольного многоугольника (в том числе дырявого) на простые выпуклые?

А многоугольник строго выпуклый со строго выпуклой дыркой? Или совсем произвольный?

А многоугольник строго выпуклый со строго выпуклой дыркой? Или совсем произвольный?

Совсем совсем

Совсем совсем

Тогда простого решения нет. Предлагаю взять libtess (или libtess2).

Тогда простого решения нет. Предлагаю взять libtess (или libtess2).

:с Окей, гляну, спасибо.

А ещё же где-то был чат по графике, там лучше должны знать.

Это может помочь: http://algolist.manual.ru/maths/geom/polygon/decompose_seidel.php

Не подскажет ли кто быстрый и универсальный алгоритм разбиения произвольного многоугольника (в том числе дырявого) на простые выпуклые?

триангуляция

ERROR: S client not available

Если таки захотите руками собрать, я делаю примерно так; https://github.com/SBKarr/stappler-deps/blob/master/android/curl-android.sh https://github.com/SBKarr/stappler-deps/blob/master/android/mbedtls-android.sh

спасибо

Это может помочь: http://algolist.manual.ru/maths/geom/polygon/decompose_seidel.php

Вот где-то что-то уже видел про монотонные многоугольники, правда термин пока не ясен. В общем спасибо, буду углубляться в геометрию.

http://shtonda.blogspot.ru/2017/09/cpp-templates-complete-guide-2nd.html

триангуляция

Оно очевидно что триангуляция. Но меня интересуют практические и уже изобретённые алгоритмы, чтобы не сидеть и не выдумывать велосипед. Гуглится как не странно не так тривиально как "триангуляция".

Вот где-то что-то уже видел про монотонные многоугольники, правда термин пока не ясен. В общем спасибо, буду углубляться в геометрию.

Там нужно очень ответственно подходить к точности вычислений, какие-нибудь острые углы или близко расположенные линии могут радикально все попортить

Собсно, приложенный пример кода в статье можно использовать только как пример, он очень активно любит крашиться на реальных данных

Там нужно очень ответственно подходить к точности вычислений, какие-нибудь острые углы или близко расположенные линии могут радикально все попортить

Ну у меня верояятнее всего будет даже фиксированная запятая, так что по крайней мере ошибки нанов иинфинитей мне не грозят..

Ну у меня верояятнее всего будет даже фиксированная запятая, так что по крайней мере ошибки нанов иинфинитей мне не грозят..

Я не знаток в вычгеоме, но есть ощущение, что и с фиксированной запятой можно получить проблемные многоугольники, достаточно лишь работать в большом масштабе

Я не знаток в вычгеоме, но есть ощущение, что и с фиксированной запятой можно получить проблемные многоугольники, достаточно лишь работать в большом масштабе

Да, думаю вы правы.

Я не знаток в вычгеоме, но есть ощущение, что и с фиксированной запятой можно получить проблемные многоугольники, достаточно лишь работать в большом масштабе

Единственное, мне не совсем понятно, как масштаб влияет на проблемность?

Не подскажет ли кто быстрый и универсальный алгоритм разбиения произвольного многоугольника (в том числе дырявого) на простые выпуклые?

https://doc.cgal.org/Manual/3.2/doc_html/cgal_manual/Partition_2/Chapter_main.html

Единственное, мне не совсем понятно, как масштаб влияет на проблемность?

Представь три точки A, B, C, где точка C находится на минимально допустимом (согласно твоей точности) расстоянии от прямой AB, но при этом эта точка C находится достаточно далеко от точек A и B. В таком масштабе ABC может восприниматься как прямая, что на самом деле не является правдой. И вытекающие проблемы могут появиться при вычислениях в районе точки B. Если ABC - часть многоугольника, то задача локализации точки внутри/вне многоугольника рядом с точкой B может фейлиться.

Представь три точки A, B, C, где точка C находится на минимально допустимом (согласно твоей точности) расстоянии от прямой AB, но при этом эта точка C находится достаточно далеко от точек A и B. В таком масштабе ABC может восприниматься как прямая, что на самом деле не является правдой. И вытекающие проблемы могут появиться при вычислениях в районе точки B. Если ABC - часть многоугольника, то задача локализации точки внутри/вне многоугольника рядом с точкой B может фейлиться.

А, да, теперь вдуплил, спасибо.

Нормально ли делать значение по умолчанию в методе интерфейса? class Interface { public: virtual void print(int value = 100500) = 0; };

https://doc.cgal.org/Manual/3.2/doc_html/cgal_manual/Partition_2/Chapter_main.html

Точно, в том же cgal кажется есть (точно не помню) реализация и на основе алгоритма Зейделя. Но они там во многих своих алгоритмах используют предвычисленную константу для оценки точности работы с плавающей запятой. Это конечно лучше, чем работа без такой константы, но в идеале следует работать с типом бесконечной точности

Точно, в том же cgal кажется есть (точно не помню) реализация и на основе алгоритма Зейделя. Но они там во многих своих алгоритмах используют предвычисленную константу для оценки точности работы с плавающей запятой. Это конечно лучше, чем работа без такой константы, но в идеале следует работать с типом бесконечной точности

Не понимаю утверждение про константу совсем. Базис CGAL как раз в корректной работе с точностью и их ядрах, которые помогают писать корректные предикаты не особо жертвуя скоростью.

Не понимаю утверждение про константу совсем. Базис CGAL как раз в корректной работе с точностью и их ядрах, которые помогают писать корректные предикаты не особо жертвуя скоростью.

Я с cgal толком не работал и знаю только совсем поверхностно эту тему. Насколько я понимаю, для каждого конкретного предиката можно вычислить его точность. И, возможно, для основных предикатов типа задачи локализации точки относительно прямой точность уже предвычислена и захардкожена в константах. Как просчитывается точность алгоритма, построенного на предикатах - не знаю. Мне просто донесли мысль, что лучше сразу двигаться в направлении типов с бесконечной точностью

А, все, вижу их доку, у них как раз типы с произвольной точностью)

Я с cgal толком не работал и знаю только совсем поверхностно эту тему. Насколько я понимаю, для каждого конкретного предиката можно вычислить его точность. И, возможно, для основных предикатов типа задачи локализации точки относительно прямой точность уже предвычислена и захардкожена в константах. Как просчитывается точность алгоритма, построенного на предикатах - не знаю. Мне просто донесли мысль, что лучше сразу двигаться в направлении типов с бесконечной точностью

В CGAL в принципе можно использовать любую модель. Если везде использовать бесконечную точность то будет медленно. На практике обычно применяют вещественные числа, но когда вычисляется предикат и ядро понимает что вещественной точности не хватает (например получается маленькое число которое надо сравнить с нулем), то ядро пересчитывает предикат с точной арифметикой.

Кстати о графике, никто не видел где-нибудь вычислений точек самопересечения контура, заданного кривыми безье? По сути, из двух кривых нужно найти, что они пересекаются, и где пересекаются, остальное просто.

Представь три точки A, B, C, где точка C находится на минимально допустимом (согласно твоей точности) расстоянии от прямой AB, но при этом эта точка C находится достаточно далеко от точек A и B. В таком масштабе ABC может восприниматься как прямая, что на самом деле не является правдой. И вытекающие проблемы могут появиться при вычислениях в районе точки B. Если ABC - часть многоугольника, то задача локализации точки внутри/вне многоугольника рядом с точкой B может фейлиться.

Сейчас подумал, мне кажется достаточно проверять ab, bc и са на вхождение друг в друга. И в случае положительного ответа не считать данный треугольник треугольником.. Впрочем простота этой проверки уже будет зависить от алгоритма разбиения сложного многоугольника.

Такой вопрос: Полухин в книжке по бусту пишет, что де код в критических секциях может в разы ускоряться, если все используемое внутри секции будет поддерживать перемещение, а не только копирование. Это как так? Я всегда искренне считал, что все подкапотные сохранения состояния происходят на уровне операционки, которая знай себе байты перекладывает, не заморачиваясь что байты лежат в программе на с++11+, которая умеет в перемещения вместо копирований. Я был, глубоко неправ, или неправильно понял автора?

^ всё просто - move конструкторы и assinment работают как правило быстрее чем copy, поэтому если использовать move то мы в критической секции будем меньше времени находиться. И соответственно двум потокам "столкнуться" в одной критической секции будет сложнее

текст там таков: The work_queue class could be significantly improved by adding support for rvalue references and calling std::move(tasks_.front()). This will make the code in the critical section much faster, resulting in less threads, suspends, and wakeups, less cache misses and a much better performance. Any operation acquires a unique lock on the mutex_ variable, so even getting resources results in waiting on a locked mutex. As some of the resources are hard to copy, the critical sections consume a lot of time, slowing down any operation on the class.

threads, suspends, and wakeups редакторы,гады, вставили лишнюю запятую после threads

Сейчас подумал, мне кажется достаточно проверять ab, bc и са на вхождение друг в друга. И в случае положительного ответа не считать данный треугольник треугольником.. Впрочем простота этой проверки уже будет зависить от алгоритма разбиения сложного многоугольника.

А как ты собираешься проверять? В моем понимании, это как раз выливается в задачу локализации точки относительно прямой с соответствующими заботами о точности

А как ты собираешься проверять? В моем понимании, это как раз выливается в задачу локализации точки относительно прямой с соответствующими заботами о точности

Ну мне сейчас на ум приходят только задачки из 5-6 класса по вхождению отрезков друг в друга :D

Ну мне сейчас на ум приходят только задачки из 5-6 класса по вхождению отрезков друг в друга :D

Начни писать код, увидишь к чему всё идёт, а потом загугли, как этот код сократить с целью минимизации вычислений. Вероятнее всего ты придешь к косому произведению

Ну нет, обычно они эти моменты нормально пишут. Это только у нас тут случай какой-то вопиющий с GLUT.

давно было это все, хватало и тупого display(), использовавшего статические функции. Можно еще было внутри него свой роутер по ID'у окна сделать, в качестве варианта: std::map<int, YourFunctorType> handlers; void display() { handlers[glutGetWindow()].second(); } вот как-то так примерно

Нет, скорее, отказатся от glut'a :)

да, бери glfw

да, бери glfw

Взял gtkmm)