Возможно, повторю чьи-то доводы. Апории Зенона -- это про рассуждения и логику, к реальному миру и физике они имеют косвенное отношение. Логические рассуждения основаны на цепочке логических следствий, т.е. после добавления утверждения вся цепочка остается тавтологией. Соответственно, надо с чего-то начинать и так появляются аксиомы. И вот, мы наталкиваемся на момент, когда не можем пополнить рассуждение новым высказыванием. Это означает, что с нашими аксиомами что-то не так.
Добавляем в число аксиом возможность завершения некоторых бесконечных процессов. И не получаем противоречий! Да, как-то предельный переход царапает сложившуюся картину мира. Но главный критерий -- на его основе получается создать богатую и полезную теорию. Как-то так.
А что касается физики -- в ее основе лежат эмпирические факты. Ахиллес легко обгоняет черепаху, значит рассуждения Зенона (главное, система аксиом) неправильно описывают реальность. Точка.
Достаточно широко применяется в контролируемых клинических испытаниях, там, кстати, много фокусов придумано для случая "относительно долгого созревания эффекта".
Ага, и по моему опыту в Windows ответы WS-Discovery на сокет переставали приходить через пару минут после первого запуска. Как это отключить -- не знаю, хотя работающие программы от производителей камеры были и в Wireshark пакеты с ответами для них были. А так -- только через dasHost, он как-то получает всю информацию.
Реализаций mDNS для Windows больше одной для каждого языка программирования. И работает хоть по IPv4, хоть по IPv6, плюс service discavery. У mDNS главный недостаток -- UDP multicast может не всюду "добивать". И в таком случае, наверное нет альтернативы как-то сделанному динамическому DNS для всей сети.
Сравнение значений с плавающей точкой на равенство -- это побитовое сравнение, практически memcmp, т.е. реально низкоуровневая операция, происходящая либо на абстрактной машине, либо уровнем ниже на конкретном железе. Оптимизация тут может быть неуместной.
Если компилятор генерит код, сравнивающий объекты с разным двоичным представлением, то с моей точки зрения это все-таки баг компилятора. Я не знакток x87, в нем сравнения только регистр-регистр или есть и регистр-память?
Использование volatile для точечного подавления нежелательной оптимизации выглядит как элегантный трюк.
Пустой какой-то спор, оба правы. Строго говоря, и ссылки и указатели в C++ называют ссылочными типами, если верить Wikipedia. :)
На мой вкус, это не совсем верно и, когда-то давно, когда учился в 90-х, их вроде по-русски даже называли косвенными типами. Хотя и это неверно.
Подытоживая: думайте, что хотите, но и в C, и в C++ адрес памяти -- совершенно законный целочисленный тип данных. У указателя может быть свой адрес, не связанный с адресуемым объектом. Не все то, что можно вытворить с указателем, можно делать с ссылкой, хотя они могут быть равны побитово. А ссылка -- указатель с дополнительными ограничениями и сахаром. Можно называть ссылки ссылочными типами, можно иначе, но это не добавляет ничего нового и не несет никакой пользы. Поэтому остаюсь при своем мнении.
Сколько угодно, терминологические битвы неинтересны. Ссылочный тип -- устоявшийся термин, появившийся, если не ошибаюсь, в языках со сборкой мусора (вроде Java) для типов, экземпляры которых создаются исключительно в куче и доступных только через handle-ссылку.
В C++ ссылки -- это ограниченный в использовании указатель, не более, но и не менее. Называть какие-либо ссылки "ссылочными типами" -- вводить неискушенного читателя в заблуждение. Студпэр с двумя ссылками внутри -- это студпэр с двумя полями-указателями, просто язык затрудняет передачу в них nullptr. Но не запрещает. Как-то так, на скорую руку, не судите строго, могу напортачить, но идея должна быть ясна:
//...
std::pair<int&, int&> p;
{
int a = 15;
int b = 4;
p = std::pair<int&, int&>{a, b};
// а тут копируются инты? Думаю, адреса интов...
...
}
// что?!!!
Кстати, я, лично, полагаю, что в C++ нужны ссылочные типы: синтаксический сахар для создания "запимпленных" классов, экземпляр такого класса и будет служить handl'ом для неявного и доступного только в одной единице компиляции "внутреннего" типа.
Только мне кажется, что называть C++ ссылки во всех их ипостасях "ссылочными типами" -- по меньшей мере, преувеличение?
Ссылочный тип -- это тип доступный исключительно по ссылке, а не ограничение на использование обычного типа. Что-то похожее на ссылочные типы в плюсах -- это а)известные со времен C указатели на непрозрачные стуркутры и б)непрозрачные структуры/классы, завернутые в умные указатели и в)классы с PIMPL. Стрелочка вместо точки -- синтаксическая мелочь, которая ничего не меняет. В случае в) стрелочка и неособо нужна...
Кстати, toolchain файл можно смело инклюдить в CMakeList.txt, если до project. А другие переменные, чтобы не заморачиваться со скриптами и -D -- можно записать во вспомогательный скрипт .cmake в папку cmake -- и тоже заинклюдить в головной CMakeList.
Возможно, повторю чьи-то доводы.
Апории Зенона -- это про рассуждения и логику, к реальному миру и физике они имеют косвенное отношение.
Логические рассуждения основаны на цепочке логических следствий, т.е. после добавления утверждения вся цепочка остается тавтологией. Соответственно, надо с чего-то начинать и так появляются аксиомы.
И вот, мы наталкиваемся на момент, когда не можем пополнить рассуждение новым высказыванием. Это означает, что с нашими аксиомами что-то не так.
Добавляем в число аксиом возможность завершения некоторых бесконечных процессов. И не получаем противоречий! Да, как-то предельный переход царапает сложившуюся картину мира. Но главный критерий -- на его основе получается создать богатую и полезную теорию. Как-то так.
А что касается физики -- в ее основе лежат эмпирические факты. Ахиллес легко обгоняет черепаху, значит рассуждения Зенона (главное, система аксиом) неправильно описывают реальность. Точка.
Достаточно широко применяется в контролируемых клинических испытаниях, там, кстати, много фокусов придумано для случая "относительно долгого созревания эффекта".
Ага, и по моему опыту в Windows ответы WS-Discovery на сокет переставали приходить через пару минут после первого запуска. Как это отключить -- не знаю, хотя работающие программы от производителей камеры были и в Wireshark пакеты с ответами для них были.
А так -- только через dasHost, он как-то получает всю информацию.
Реализаций mDNS для Windows больше одной для каждого языка программирования. И работает хоть по IPv4, хоть по IPv6, плюс service discavery. У mDNS главный недостаток -- UDP multicast может не всюду "добивать". И в таком случае, наверное нет альтернативы как-то сделанному динамическому DNS для всей сети.
Смущает унарный минус с uintptr’ом, альтернативы страшнее, зато явно показывают, что тут bit trick.
Если более серьезно.
Сравнение значений с плавающей точкой на равенство -- это побитовое сравнение, практически memcmp, т.е. реально низкоуровневая операция, происходящая либо на абстрактной машине, либо уровнем ниже на конкретном железе. Оптимизация тут может быть неуместной.
Если компилятор генерит код, сравнивающий объекты с разным двоичным представлением, то с моей точки зрения это все-таки баг компилятора. Я не знакток x87, в нем сравнения только регистр-регистр или есть и регистр-память?
Использование volatile для точечного подавления нежелательной оптимизации выглядит как элегантный трюк.
Обычное дело в низкоуровневом коде, напрямую с железом и не такие чудеса случаются(
И так, и эдак выход за границу массива, нет?
Может быть сведено к двум принципам Цермело для выступающих:
Не бойтесь недооценить аудиторию, опасайтесь ее переоценить.
Не уделяйте много внимания важному, напирайте на очевидное...
Серьезно?
Пустой какой-то спор, оба правы. Строго говоря, и ссылки и указатели в C++ называют ссылочными типами, если верить Wikipedia. :)
На мой вкус, это не совсем верно и, когда-то давно, когда учился в 90-х, их вроде по-русски даже называли косвенными типами. Хотя и это неверно.
Подытоживая: думайте, что хотите, но и в C, и в C++ адрес памяти -- совершенно законный целочисленный тип данных. У указателя может быть свой адрес, не связанный с адресуемым объектом. Не все то, что можно вытворить с указателем, можно делать с ссылкой, хотя они могут быть равны побитово. А ссылка -- указатель с дополнительными ограничениями и сахаром. Можно называть ссылки ссылочными типами, можно иначе, но это не добавляет ничего нового и не несет никакой пользы. Поэтому остаюсь при своем мнении.
Сколько угодно, терминологические битвы неинтересны. Ссылочный тип -- устоявшийся термин, появившийся, если не ошибаюсь, в языках со сборкой мусора (вроде Java) для типов, экземпляры которых создаются исключительно в куче и доступных только через handle-ссылку.
В C++ ссылки -- это ограниченный в использовании указатель, не более, но и не менее. Называть какие-либо ссылки "ссылочными типами" -- вводить неискушенного читателя в заблуждение. Студпэр с двумя ссылками внутри -- это студпэр с двумя полями-указателями, просто язык затрудняет передачу в них nullptr. Но не запрещает. Как-то так, на скорую руку, не судите строго, могу напортачить, но идея должна быть ясна:
Кстати, я, лично, полагаю, что в C++ нужны ссылочные типы: синтаксический сахар для создания "запимпленных" классов, экземпляр такого класса и будет служить handl'ом для неявного и доступного только в одной единице компиляции "внутреннего" типа.
Только мне кажется, что называть C++ ссылки во всех их ипостасях "ссылочными типами" -- по меньшей мере, преувеличение?
Ссылочный тип -- это тип доступный исключительно по ссылке, а не ограничение на использование обычного типа. Что-то похожее на ссылочные типы в плюсах -- это а)известные со времен C указатели на непрозрачные стуркутры и б)непрозрачные структуры/классы, завернутые в умные указатели и в)классы с PIMPL. Стрелочка вместо точки -- синтаксическая мелочь, которая ничего не меняет. В случае в) стрелочка и неособо нужна...
Главная причина -- интерфейс к развесистым C/C++ библиотекам.
Ось така..?
Скорее уж пациенты...
Не знаток go. В коде везде знаковые целые и сдвиг на знаковое целое. В go с этим не бывает проблем? В C лучше для этого использовать беззнаковые типы.
Они разогнали команду модераторов-поборников CoC.
Хоть в Rust, похоже, адекватная Core Team...
Кстати, toolchain файл можно смело инклюдить в CMakeList.txt, если до project. А другие переменные, чтобы не заморачиваться со скриптами и -D -- можно записать во вспомогательный скрипт .cmake в папку cmake -- и тоже заинклюдить в головной CMakeList.