Здравствуйте, so5team, Вы писали:
S>В данной теме вы общаетесь с Евгением Охотниковым, компания "СтифСтрим". Мы развиваем такие продукты, как SObjectizer, RESTinio и json_dto, оказываем техподдержку пользователям этих продуктов, даем консультации и выполняем разработку под заказ.
Для меня все это пустой звук.
S>Как и для чего наши клиенты используют результаты нашей работы не ваше дело.
Здравствуйте, Denis Ivlev, Вы писали:
S>>В данной теме вы общаетесь с Евгением Охотниковым, компания "СтифСтрим". Мы развиваем такие продукты, как SObjectizer, RESTinio и json_dto, оказываем техподдержку пользователям этих продуктов, даем консультации и выполняем разработку под заказ.
DI>Для меня все это пустой звук.
Во-первых, врать нехорошо. Как минимум, вы читаете мой блог. А так же анонсы наших релизов на RSDN.
Во-вторых, суть не в громкости имен и известности разработок. Полагаю, что для большинства здесь присутствующих "Александр Сибиряков", "Scrapinghub" и "Frontera" не менее пустые звуки.
Суть в том, что мне не страшно назвать ни свое реальное имя, ни место работы.
В отличии от.
S>>Как и для чего наши клиенты используют результаты нашей работы не ваше дело.
DI>Да вы просто ссыкло. (С)
Да, нарушать NDA более чем ссыкотно. И не столько из-за боязни юридических последствий, сколько из-за далеко не иллюзорной возможности угробить деловую репутацию.
Вот вы о рисках, связанных с деловой репутацией, вряд ли задумываетесь, поскольку своим унылым троллингом и трусливым поведением уже создали Scrapinghub-у отрицательную карму.
Здравствуйте, Pzz, Вы писали:
_>>Повторюсь ещё раз: я вполне понимаю такую аргументацию скажем от программиста на Java и Python. Да, они потеряют на этом в эффективности кода, но это может быть вполне допустимо условиями задачи. Но от программистов на C и ему подобных языков, подобная аргументация не может работать. Потому что программисту на C точно так же требуется продумывать время жизни каждого объекта. Pzz>Это, на самом деле, отзвук прозвучавшей здесь в другой нитке обсуждения мысли, что C++ — язык, пригодный для работы со сложными абстрактными данными. Не пригодный, как и C не пригодный.
Нуу если C++ не пригодный, то мне тогда весьма интересно услышать какой пригодный и почему (желательно с конкретными примерами).
_>>Вообще не понял о чём ты тут. Pzz>О том, что абстракции C++ подтекают. Слишком большая разница между тем высокоуровневым интерфейсом, которые народ обычно пытается выразить, и низкоуровневыми кишками под капотом.
Можно какой-нибудь конкретный пример подобного? Естественно это должна быть часть стандарта языка, а не какая-нибудь левая библиотечка, написанная студентом...
_>>Ну вообще то я как раз написал, что я не понимаю, по какой причине (кроме незнания естественно), можно выбирать вариант с ручным управлением памятью. Может ты подскажешь? Т.е. ты конечно же уже написал, что типа "простота — это хорошо", но дело в том, что это самую простоту ты так и не продемонстрировал ни на одном примере конкретного кода. По моему опыту, код на C++ внешне обычно выглядит даже проще аналогов на C. Pzz>Я не выбираю ручное управление памятью, это ложная дилема. Я выбираю язык, который я способен понять, и при этом в голове останется достаточно места для той задачи, которую я решаю. Если за такой выбор языка приходится платить какими-то удобствами, ОК, я обойдусь без этих удобств.
Ну с этим то я естественно согласен. У меня вот только один вопрос остался: о дикой сложности программирования на C++ ты узнал из собственного опыта или по чужим рассказам? )
Здравствуйте, Marty, Вы писали:
M>>>ADC/DAC/I2C/SPI/UART/CAN/TIM/DMA etc _>>Я в курсе что такое периферия. Мне не понятен термин "работы" с ней, в контексте IDE. M>Смотреть в отладке на регистры
Так регистры же все отображены в память, и соответственно банальный gdb без проблем подтягивает их значения (можно хоть в командной строке смотреть), и далее любая IDE показывает их в стандартном интерфейсе отладчика (отслеживания переменных). Что там ещё может быть нужно? )
Здравствуйте, nekocoder, Вы писали:
N>Хорошо вам там в альтернативной вселенной, где проекты сразу после завершения выбрасываются и переписываются с нуля.
Да хеллоуворлдщики они тут все, эти местные C++-ные гуру. Они просто не осознают, по недостатку опыта, того, что все новомодные C++-ные примочки в коде, размеры которого превышают несколько лямов локов, превращается в полностью нечитабельный набор заклинаний. На маленьких проектах, которые, например, местный so5team пилит, С++ удобен. Но, основываясь именно на таком опыте, местные C++-ные гуру рассказывают как надо делать в проектах такого размера, как СУБД оракел.
Здравствуйте, smeeld, Вы писали:
S>Они просто не осознают
Откуда знаете?
S>все новомодные C++-ные примочки в коде, размеры которого превышают несколько лямов локов, превращается в полностью нечитабельный набор заклинаний
Я вам даже на пальцах объясню, почему так происходит. Потому, что вокруг проектов в несколько MLOC слишком много матерых экспертов с десятилетиями опыта за плечами, вроде вас и Pzz. Которые отстали от прогресса настолько, что вот здесь:
template<class T, T Left, T right>
class constrained_value {
T v_;
public:
explicit constrained_value(T v) : v_(v) {
if( !(v_ >= Left && v_ <= Right) )
throw ...; // Или вызов abort.
}
operator T() const { return v_; }
};
им видится и полэкрана кода, который ничего не делает, и, что еще важнее, проверки на каждом присваивании.
Конечно, заставь таких использовать основанные на шаблонах strong_typedef-ы, чтобы в программе в принципе нельзя было сложить метры с килограммами, и поднимится вой до небес о том, что программа превратилась в нечитаемое шаблонное месиво. И все это с громким битиём себя пяткой в грудь и обещаниями все-все ручками проверить.
Отсюда потом и байки про божественный "Си с классами" и россказни Pzz про C++, которого он толком и не видел, как оказалось.
Ну а на счет того, как пишется СУБД Oracle погулите нашумевший недавно инсайд о том, насколько там все гладко и замечательно.
Здравствуйте, Marty, Вы писали:
M>к гражданам сишечникам
M>Оченно прошу — расскажите, где вы работаете. И нет, не то, что вы подумали — давайте обойдемся без говна с оскорблениями и пр. — я к вам резуме посылать не буду, как раз и хочу избежать этого шага — нет смысла — и вам тоже проще
Всё просто-не пытайтесь устроиться работать в компании, с оборотом больше $100M и собственным фондом софта размеры которого больше гигабайта исходников (суммарный размер последних релизных веток). И тогда избежите встречи с кодом, который по-Вашему, несомненно компетентному мнению эксперта, считается говнокодом. Пилите и дальше свои хеллоуворлды кучкой единомышлеников-говноэкспертов.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Т.е. уже лет двадцать назад ему прочили "полное исчезновение, вот-вот".
Полное исчезновение никто ему и не пророчил. А вот уход во все более маргинальные ниши — вполне. И топики в работе говорят о том, что процесс этот идет полным ходом.
Здравствуйте, smeeld, Вы писали:
S>Всё просто-не пытайтесь устроиться работать в компании, с оборотом больше $100M и собственным фондом софта размеры которого больше гигабайта исходников (суммарный размер последних релизных веток). И тогда избежите встречи с кодом, который по-Вашему, несомненно компетентному мнению эксперта, считается говнокодом. Пилите и дальше свои хеллоуворлды кучкой единомышлеников-говноэкспертов.
Эти тонны старого кода тоже были когда-то молодыми и современными. Проблема там не в том, что они так хороши, что их не хотят переписывать, а в том, что уже и не могут из-за объёма.
Аналогично и с другими аспектами. Работая в АМД приходилось использовать Perforce, который жутко не удобен. Поэтому многие разработчики для себя или команды организовывали мини репозитории на git/mercurial для повседневной работы и отдельную вентку для мержа в Perforce. На днях я узнал, что в Nvidia такие же проблемы — там тоже Perforce. При этом кодовая база драйверов превысила кодовую базу той же Windows довольно давно, проекты большие с поддержкой кучи компиляторов и разных версий Ос. Именно последний пункт ограничивает внедрение новых стандартов С++, а не мифические сложности или подводные камни.
Здравствуйте, Mamut, Вы писали:
L>>Тупой единственный тест обеспечит 100% покрытие кода... но все ли сценарии покрыты? M>И на таком рано или поздно валятся все: забыли, недосмотрели, жесткие дедлайны, программист устал, человек ушел в отпуск и кусок кода выкатывает другой человек... M>B0FEE664, правда, свято верит, что где-то есть сферовакуумные программисты, которых проверяют специальные сторонние организации, которые пишут 100% тестов по 100% сценариев.
Да, проверяют. Я не верю, я знаю. И проверяют, кстати, 100% покрытие кода, а не 100% сценариев.
Здравствуйте, Nikе, Вы писали:
BFE>>В частности, если у вас есть вызов new, то надо предоставить тест, который обрабатывает исключение бросаемое new при нехватке памяти. И так для каждого встречающегося в коде new, а не в одном каком-то месте. Представляете себе объём работы по написанию тестов? N>Попытался распарсить написанное — не получилось. Если у нас есть вызов new, то его нужно проверить, ок. Но в С коде в этом месте будет malloc. Претензия к необходимости проверить new, намекает на то, что malloc проверять не надо? Так нет же, точно так же надо, т.е. к чему это было писать? Или намёк на то, что магический С не потребует маллока? Но тогда зачем new в С++ коде? Что за укурка вообще?
Я это написал к тому, что нет никакой динамически выделяемой памяти, а тогда вместо С++ получается С с классами.
Здравствуйте, alex_public, Вы писали:
_>Глупости какие. Я например периодически пишу код для МК и использую там на полную удобства C++17 (скоро уже на 20 буду переползать). При этом там естественно нет динамического выделения памяти в принципе.
Ну раз нет динамического выделения памяти, значит нет виртуальных функций, смарт указателей, контейнеров...
Что именно от C++17 вы используете?
Здравствуйте, B0FEE664, Вы писали:
BFE>Ну раз нет динамического выделения памяти, значит нет виртуальных функций,
Каким боком динамическая память к виртуальным функциям?
BFE>контейнеров...
STL-ных не будет. А вот какие-нибудь small_vector/small_set/small_map которые используют буфер фиксированного размера или тот же std::array вполне себе.
Опять же, где именно шаблоны, лямбды или structured binding с if constexpr взаимоувязаны с динамической памятью?
Здравствуйте, CreatorCray, Вы писали:
BFE>>В частности, если у вас есть вызов new, то надо предоставить тест, который обрабатывает исключение бросаемое new при нехватке памяти. CC>Ващета исключения отключаемы, и new будет неотличим от malloc.
malloc тоже нельзя. Ну или с тестами по исчерпанию памяти при каждом использовании.
BFE>>Исходя из этого для многих проектов просто запрещается динамическая аллокация памяти. CC>С чего бы вдруг?
А вы доверили свою жизнь автопилоту с динамической аллокацией памяти?
BFE>> Соответственно выбрасывается всё, что аллоцирует память, начиная с std::vector ... CC>И хрен с ней, с STL библой CC>С++ то тут при чём?
Так получается C с классами, а не C++.
CC>Это всё решается на уровне библиотек и требований к стилистике кода. Функционал языка же остаётся.
Часть функционала оказывается неиспользуемой. Зачем, например, виртуальные функции, если нет динамически создаваемых объектов?
Здравствуйте, alex_public, Вы писали:
Pzz>>Это, на самом деле, отзвук прозвучавшей здесь в другой нитке обсуждения мысли, что C++ — язык, пригодный для работы со сложными абстрактными данными. Не пригодный, как и C не пригодный.
_>Нуу если C++ не пригодный, то мне тогда весьма интересно услышать какой пригодный и почему (желательно с конкретными примерами).
Ну, первая версия компилятора rust была написана на ocaml'е, и неспроста...
На самом деле, с этим беда. Нет мейнстримового языка, пригодного для таких задач. Возможно потому, что такие задачи относительно нечасто встречаются.
_>Можно какой-нибудь конкретный пример подобного? Естественно это должна быть часть стандарта языка, а не какая-нибудь левая библиотечка, написанная студентом...
Даже в статье есть примеры.
На самом деле, то, что ты сказал, это еще один камень в огород C++. Ты неявно говоришь, что прикладной код могут и простые смертные писать, а стандартные контейнеры — это задача для небожителей. Почти любая часть стандартной библиотеки C или Go может быть написана обычным рядовым программистом, там нет никакой магии.
_>Ну с этим то я естественно согласен. У меня вот только один вопрос остался: о дикой сложности программирования на C++ ты узнал из собственного опыта или по чужим рассказам? )
