Любой код, который не полагается на undefined behaviour работает одинаково :)

А потеря при приведении типов (void * к int) относится к UB?

вброс улыбает своей дешевизной. ожидаемо, в твоем духе =)

жги еще!

ты действительно всегда под себя пишешь весь код с ноля?

вроде как везде, за такое, ручки-то обламывают.

Действительно - зачем, век без них жили и не тужили и всех всё устраивало и никто не жаловался

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

а тут вдруг мы должны от них зависеть, как пещерные люди

Не хочешь - не завись, кто заставляет.

Тем более как раз у пещерных людей «зависимостей» было меньше. А сейчас мы зависим и от электричества и от интернера и ещё от кучи удобств, но обратно в пещеры не хочется. Хотя кому как.

Все эти понятие, что были перечислены выше существуют только как условное определение каких либо действий в пределах самого языка, вернее набором ASCII символов, которые в дальнейшем компилятор отлинкует и превратит в машинный код, где все эти «rvalue references и семантика перемещения» превратятся в: «Поместить значения регистра А в регистр Б, сравнить значение регистра Y с регистром Z, вызвать то-то».

Что сказать-то хотел?

Хотел убедить товарища, что от всех этих нововведений, работа программ отнюдь не изменится в положительную сторону, выполнится ровно тот участок инструкций в библиотеке, который реализуют функцию в полной своей красе :)

Ну вообще-то может и меняться. Некоторые вещи из нового стандарта в старом эмулировать сложно или даже невозможно.

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

И при этом всём, они компилируют в уме? С трудом верится. Учитывая штрафы - сами разработчик захотят десять раз перестраховаться и собрать свой код и тесты прогнать.

Ну не верю я в «мега профессионалов», которые могут 100% времени выдавать идеальный готовый код без синтаксических и особенно логических ошибок. Особенно, если учесть, что по твоим словам, оно только и делают, что код колбасят.

Вполне. Для этого в стандарте предусмотрен тип intptr_t.

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

Я тут о формальной стороне дела, если скажем грепать стандарт по UB.

Кстати, чем сообществу BSD не угодила лицензия GPLv3, что она для них даже хуже v2, тивоизировать дистр с gcc version >4.2.1 хотят что ли?

тем что - если собрать любую программу с таким GCC, он прилинкует статически libgcc (ну неможет он по другому), а значит у любого получившего твой бинарник - появляется возможность требовать код под лицензией GNU GPL v3, и чхать он хотел на то что у тебя была выбрана другая лицензия. Вот такое наплевательство со стороны столмана (навязавщего GNU GPL v3 проекту gcc).

Нет лицензий кроме GNU GPL, а не нравится - мы все равно ваш код отберем.

Так. Молодой человек. Вы все- таки, мягко говоря, не в теме. Отделите пожалуйста Ваши фантазии (http://lurkmore.to/Синдром_утёнка) и вычитанные частные случаи (https://www.usenix.org/conference/hotdep12/tbd) от реального состояния вещей.

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

Мудрость быстрее приходит через попоболь. Главное не переборщить.

https://www.usenix.org/conference/hotdep12/tbd

Не вижу там ничего насчет «программисты не компилируют код». И да, стиль разработки, принятый в JPL, уникален и очень дорог. Если ты там не работаешь, вряд ли ты с ним столкнешься на деле.

если кратко:

...то там не говорится о том, о чем ты рассказал.

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

Мы реальные кодеры, да, как и они. А ты фантазер.

тем что - если собрать любую программу с таким GCC, он прилинкует статически libgcc (ну неможет он по другому), а значит у любого получившего твой бинарник - появляется возможность требовать код под лицензией GNU GPL v3 [бред поскипан]

libgcc - под lgpl, за исключением части которая при динамической линковки линкуется статически.

http://www.gnu.org/licenses/gcc-exception-faq.html

Вложенных функций в стандартном С++ не бывает

зато бывают локальные классы

libgcc - под lgpl, за исключением части которая при динамической линковки линкуется статически.

Да да, мы помним что пришлось больше года уламывать столмана что бы он добавил эти самые исключения. А для себя откроейте историю - в каком виде был GCC 4.3 сразу после перехода на GNU GPL v3.

Вы уверены что столману не прийдет в голову отозвать эти самые исключения, как _УЖЕ_ делал ? Подчеркну - он уже один раз так делал, какая гарантия что это не повторится?

Ах да, и откройте для себя историю принуждения всех работающих над GCC к принятию GNU GPL v3. Но координационный совет решил подлизать Столману - не смотря на критику внутри сообщества. Вот подлизнул.. и получили то что есть.

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

т.е в ригоризме того же Компсона/Страустропа использующих acme/sam с намереным отсутствием колоризации и автодополнением есть осмысленность.

т.е всякий инструмент влияет на оптимальность траектории.

зато бывают локальные классы

поэтому я и предложил деление по границам функций

что при злоупотреблении ухудшает читабельность.

Лучше длинные и осмысленные, чем короткие. В целом читабельность от такого «злоупотребления» все же улучшается, за исключением паталогических случаев (например, когда код минимальной логической единицы растягивается за пределы доступной взгляду страницы).

Лучше длинные и осмысленные, чем короткие.

даже это излишне категорично , ибо в случае когда алго обозрим на странице для локальных идентификаторов необходима различимость ( т.е имена a, b могут быть удобней чем различные сущьности по случайности занимающие соседнии слоты x[0] и x[1]) - т.е семантика должна быть понятна из счислимого числа контекстов в котором обьект фигурирует , имя(с его намереными асоциациями) же лиш увеличивает текст и более того может вводит в заблуждение .

«Пусть x - это .... , нет x это слишком много , пусть ε - это ....»

«в военое время sin(x) может достигать и 5 »

цимес в том что наличия инструмента на обоих сторонах ( у писателя и у кодо пользователя) нивилирует тот бурст который был бы будь этот инструмент только у кодопользователя.

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

А вот для тех задач, которые решают НАСТОЯЩИЕ программисты, для бизнес-задач, более всего подходят длинные, самодокументированные имена. Опять же, потому как они соответствуют культуре, принятой в среде экспертов-предметников.

т.е вы за возможность вкачестве имён использовать фотографии(например завода ) если входной язык позволяет?

как настоящий эксперт-предметник.

Вообще-то да, это было бы неплохо. Некоторые хорошие языки, такие, как Mathematica, это позволяют.

абстрактное мышление вообще зло.

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

тык давать самодокументированые имена и есть такая протечка.

ибо само употребление обозначеного обьекта и некотором счётном числе мест и определяет свойства обьекта. - т.е в этом случае имя необходимо и достаточно быть отличимым ( ну и возможно некоторая арифметика на именах для организации косвенности)

Вы уверены что столману не прийдет в голову отозвать эти самые исключения, как _УЖЕ_ делал ? Подчеркну - он уже один раз так делал, какая гарантия что это не повторится?

gcc вроде же даже для компиляции коммерческих программ используется. Но не знал про его игры с отзывом исключений. Может недоразумение? В конце-концов, кроме GPL есть софт под APL и многими другими свободными лицензиями, которые однако прямо не конвертируемы в GPL, но компилируются и распространяются под своими лицензиями.

Вы уверены что столману не прийдет в голову отозвать эти самые исключения, как _УЖЕ_ делал ? Подчеркну - он уже один раз так делал, какая гарантия что это не повторится?

То есть,то что дорабатывали применение GPLv3 к gcc вы считаете уламыванием. С такими как вы разговаривать бесполезно. Вы видете то что хотите, а не то что есть реально.

тык давать самодокументированые имена и есть такая протечка.

Нет. Это как раз уровень абстракции предметной области. Уши из нижних уровней там не торчат.

т.е в этом случае имя необходимо и достаточно быть отличимым ( ну и возможно некоторая арифметика на именах для организации косвенности)

А вот name binding как раз будет лишней сущностью.

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

т.е в предметной области 2(назовём их anony и mous) свойства могут быть синхроны .

в методе важно наличие у обьекта anony предметник называет таковые обьекты mous , ибо в этом контексте это эквивалентно(, в более широком нет)

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

Ты опять заблуждаешься. Если алгоритм вообще в принципе может быть абстрагирован от предметной области, он должен быть реализован на другом уровне, иначе это опять та же самая протечка абстракции.

мне не понятно явление которые ты описываеш.

Поясню: алгоритм, допустим, сортировки - универсален. Не важно, сортируем мы тугрики или апельсины. Описываться он должен на таком уровне абстракции, на котором нет ни тугриков, ни апельсинов. А вот описание бизнес-процессов фирмы, упаковывающей апельсины и продающей их за тугрики должно идти на другом языке и другом уровне абстракции, где алгоритм сортировки - черный ящик, а апельсины и тугрики являются first class объектами, со своими именами, понятными специалисту предметной области.

спасибо , что ты понимаеш так же как я , однако не считаеш меня понимающим так же.

различение апельсины/тугрики это по сути учёт размерностей.

если метод не учитывает специфических особенностей то да - достаточно общих интерфейсов.

Это не только размерности. Это СУЩНОСТИ. Семиотика, то есть. Мы же люди, для нас символы и имена важнее всего прочего. Так что язык обязан отражать семиотику корректно.

да. да. да .

различение Сущьностей и есть метод использования контроля размерностей при контрролле верности решения.

именно потому, что мы люди которым имена важны, в методе имена должны быть анонимны ,

Школьный курс кстати очень хороший пример даёт когда существенная доля не различает существенное и произвольное , как следствие в решениях задач на одно неизвестное вступление «Пусть х это » допустимое , а «Пусть တ это » ересь и ошибочное решение.

язык есть инструмент кооперации и одновременно введения в заблуждение

Да оно и видно, что тебя человеческие языки вводят в заблуждение. Ты ими пользоваться не умеешь (и, похоже, не умеешь их и понимать). Интересно, а есть хоть один язык, на котором ты в состоянии внятно изъясняться?

язык исполнения тобою моих указаний.

Имеется в виду автономный бинарь? Можно создать бинарь интерпретатора с привязанными к ниму библиотеками байткода (а-ля древний FoxPro), но, наверное, это не то, что тебе надо. Про разделяемую библиотеку не понял - ты хочешь сделать ее на чистом Python? AFAIK, это невозможно. Обертку написать можно, но трудоемко. Известные мне интеграции Python-программ делаются через CLI или сетевой протокол (или что-то такое: http://mercurial.selenic.com/wiki/CommandServer).

Есть ещё вариант: имея встроенный интерпретатор, можно просто использовать Python’овский API от того же Mercurial (забив на то, что его не рекомендуется использовать — моя интеграция Mercurial ↔ Vim работает на Mercurial с версии 1.3 (когда никаким Command Server ещё не пахло) по 2.4.2 (Gentoo stable (amd64))). Встраивание интерпретатора не такая уж большая проблема, если IDE написана на C/C++. И, очевидно, не требуется, если она написана на Python. Про лёгкость исполнения этого в Java не знаю, но всюду, куда можно загнать C/C++, можно встроить и Python, возможно, с определённой долей геморроя.