Не раз видел на форуме обсуждения типа "куда идти дальше" и т.п.
Отвечаю — в С/С++
Объясняю на примерах почему
Пример1
У нас куча сущностей, каждая из которых может поддерживать любой набор из множества функциональных методов. Что мы делаем в С++? Мы делаем как-то так:
#include <библиотека общей функциональности>
class Entity1 : public func1, func2 {};
class Entity2 : public func1, func3 {};
class Entity3 : public func1 {};
4 строчки
кто меньше?
C#? Java? А ну-ка, объясните нам, дуракам, почему множественное наследование плохо? Забываю постоянно
Пример2
Вы точно знаете тип откуда-то взятых данных. Но описания для компилятора нет.
В С мы конвертим void* во что хотим. За это нас ненавидят сериализаторы и объясняют почему это плохо
Пример3
Вы используете стороннюю библиотеку, которая багами побеждает GC. Ваши действия?
В С/С++ проблема не может возникнуть априори
С/С++ даёт вам свободу. Как её использовать — для багов или для уникальных фичей, зависит только от вас
T>Отвечаю — в С/С++ T>С/С++ даёт вам свободу. Как её использовать — для багов или для уникальных фичей, зависит только от вас
Тогда уж надо иметь пару: С++ + Go.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Тогда уж надо иметь пару: С++ + Go.
Это многоженство. В принципе я не против)
LVV>Без булдырабыз!!!
Казакша белесын ба?
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, gandjustas, Вы писали:
g>> T>С/С++ даёт вам свободу.
g>> Свободу стрелять себе в ноги
R>Да! Мои ноги, хочу стреляю, хочу не стреляю. Не вам, в памперс обутым, за меня решать!
Стрелять себе в ноги — это нормально.
Говорить другим что "стрелять себе в ноги — это нормально" — это НЕ нормально.
Здравствуйте, LaptevVV, Вы писали:
T>>Отвечаю — в С/С++ T>>С/С++ даёт вам свободу. Как её использовать — для багов или для уникальных фичей, зависит только от вас LVV>Тогда уж надо иметь пару: С++ + Go.
А на ютубе разные люди говорят, что лучше выбрать для изучения один язык программирования и учить только его. Пока не станешь профессионалом не переходить на другой, то есть никаких связок C и C++ или C++ и Go, только или C, или C++, или Go. Иначе не получится развить основу и человек будет плавать в теории. Я вот подумал, а ведь в этом действительно есть смысл.
Здравствуйте, gandjustas, Вы писали:
g> g>> Свободу стрелять себе в ноги
g> R>Да! Мои ноги, хочу стреляю, хочу не стреляю. Не вам, в памперс обутым, за меня решать!
g> Стрелять себе в ноги — это нормально. g> Говорить другим что "стрелять себе в ноги — это нормально" — это НЕ нормально.
Нормально. Естественный отбор это всегда нормально. Это закаляет характер и укрепляет тестикулы.
Здравствуйте, tapatoon, Вы писали:
T>Пример1 T>У нас куча сущностей, каждая из которых может поддерживать любой набор из множества функциональных методов. Что мы делаем в С++? Мы делаем как-то так: T>
T>#include <библиотека общей функциональности>
T>class Entity1 : public func1, func2 {};
T>class Entity2 : public func1, func3 {};
T>class Entity3 : public func1 {};
T>
T>4 строчки T>кто меньше?
Если это не директива препроцессора, то всё остальное можно поставить в одну строчку, да и лишние пробелы поубирать. Но я пошёл по противоположному пути Код должен быть удобочитаемым. Это опять же доказывает, что в C++ есть что-то для каждого. Даже вот этот синтаксис, в C++ шатание и разброд, не могли остановиться на 2003. А теперь ...
Здравствуйте, tapatoon, Вы писали:
T>C#? Java? А ну-ка, объясните нам, дуракам, почему множественное наследование плохо? Забываю постоянно
А какой смысл если ты все равно завтра забудешь?
Здравствуйте, gandjustas, Вы писали:
R>>Да! Мои ноги, хочу стреляю, хочу не стреляю. Не вам, в памперс обутым, за меня решать!
G>Стрелять себе в ноги — это нормально. G>Говорить другим что "стрелять себе в ноги — это нормально" — это НЕ нормально.
Простите, а выделенное жирным вы кому сказали? Неужели себе?
Надо было разрешить выбирать несколько вариантов, т.к. это еще и от проекта зависит. Например, в каких-то проектах все еще C++14, в каких-то все еще C++17.
LVV>>Тогда уж надо иметь пару: С++ + Go. T>Это многоженство. В принципе я не против) LVV>>Без булдырабыз!!! T>Казакша белесын ба?
Я долго жил в Узбекистане.
Поговорка мне понравилась — и на казахском, и на русском звучит хорошо.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>Тогда уж надо иметь пару: С++ + Go. V>А на ютубе разные люди говорят, что лучше выбрать для изучения один язык программирования и учить только его. Пока не станешь профессионалом не переходить на другой, то есть никаких связок C и C++ или C++ и Go, только или C, или C++, или Go. Иначе не получится развить основу и человек будет плавать в теории. Я вот подумал, а ведь в этом действительно есть смысл.
Для начинающих — это правильно. Начинать надо с одного.
Тогда почему не Go ?
А профи, естественно, должен быть способен переходить на любой родственный язык без особых проблем.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV> Тогда почему не Go ?
Пральна, школоту надо сразу плохому учить. Блин, да в этом чудо-языке даже перегрузки функций нет. Пристрелить его, чтоб не мучался, да и все. Учиться нужно на Паскале! И не только учиться.
Здравствуйте, rudzuk, Вы писали:
R>Пральна, школоту надо сразу плохому учить. Блин, да в этом чудо-языке даже перегрузки функций нет. Пристрелить его, чтоб не мучался, да и все. Учиться нужно на Паскале! И не только учиться.
LVV>> Я на Паскале писал еще в году 87 примерно... R>И причем тут Паскаль? Это намек на то, что у ГО ноги из Оберона растут? Так Оберон это не Паскаль, это убогий вырожденец.
Вообще-то желательно знать предков до 7 колена...
Оберон — плоть от плоти паскаля...
И Go многое позаимствовал.
Методы — так просто совершенно в лоб...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>> Тогда почему не Go ? R>Пральна, школоту надо сразу плохому учить. Блин, да в этом чудо-языке даже перегрузки функций нет. Пристрелить его, чтоб не мучался, да и все. Учиться нужно на Паскале! И не только учиться.
Вы в обучении начинающих ничегошеьки не понимаете...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV> R>И причем тут Паскаль? Это намек на то, что у ГО ноги из Оберона растут? Так Оберон это не Паскаль, это убогий вырожденец.
LVV> Вообще-то желательно знать предков до 7 колена... LVV> Оберон — плоть от плоти паскаля...
У них из общего — только бегин с ендом. Не удивительно, что среди паскальщиков это недоразумение популярностью не пользуется.
Здравствуйте, LaptevVV, Вы писали:
LVV> R>Пральна, школоту надо сразу плохому учить. Блин, да в этом чудо-языке даже перегрузки функций нет. Пристрелить его, чтоб не мучался, да и все. Учиться нужно на Паскале! И не только учиться.
LVV> Вы в обучении начинающих ничегошеьки не понимаете...
Опыт я таки имею, и прекрасно понимаю, что обучая убогому — убогому и научишь.
LVV>> Вы в обучении начинающих ничегошеьки не понимаете... R>Опыт я таки имею, и прекрасно понимаю, что обучая убогому — убогому и научишь.
Опыт разработки и изучения языков — это не тот опыт, который нужен в обучении.
Когда я стал преподавать — у меня был 18-летний опыт разработки.
А сейчас у меня 30-летний опыт преподавания.
И это два совершенно РАЗНЫХ опыта.
И ваша оценка убогости Go — это как раз отсутствие опыта преподавания.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV> R>Опыт я таки имею, и прекрасно понимаю, что обучая убогому — убогому и научишь.
LVV> Опыт разработки и изучения языков — это не тот опыт, который нужен в обучении. LVV> Когда я стал преподавать — у меня был 18-летний опыт разработки. LVV> А сейчас у меня 30-летний опыт преподавания. LVV> И это два совершенно РАЗНЫХ опыта. LVV> И ваша оценка убогости Go — это как раз отсутствие опыта преподавания.
Об опыте преподавания я и говорил. Он скромный, но есть.
LVV>> И ваша оценка убогости Go — это как раз отсутствие опыта преподавания. R>Об опыте преподавания я и говорил. Он скромный, но есть.
Тогда вы должны понимать, что обучение программированию — это не изучение конкретного языка.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, tapatoon, Вы писали:
T>С/С++ даёт вам свободу. Как её использовать — для багов или для уникальных фичей, зависит только от вас
С++ это как бээмвэшечка — нужны сотни тон денег на обслуживание, хотя можно брать нормальные инструменты и просто писать код. В Java, кстати, есть аналог множественного наследования — default-методы в интерфейсах. Но зачем это надо? Я не знаю. 99% статей о прикладном С++ о том, как "я тут написал библиотеку, и теперь вот одним вызовом мы делалем шаблон шаблонов с конструтором перемещения и шлюхами на этапе компиляции". Вот из последнего — доклад с CppCon о том, что нужно писать в функциональном стиле, потому что так меньше ошибок. Прикольный доклад, только он заканчивается словами "но С++ ещё не готов к такому, потому что функциональный код получается ущербнее императивного".
Мне нравится смотреть на С++ как на красивую, но недоступную девушку. Красивую, потому что метопрограммирование это мощно и элегантно. Недоступную, потому что из-за обратной совместимости не получится на нём писать безопасные программы — всё время будет вылезать какое-то правило, которое не просто ломает программу, а ещё и добавляет UB, что приводит к тому, что компилятор решает сгенерировать какой-то случайный код. По-хорошему, нужно выкинуть всё наследние, оставить только нормальные правила, и научить компилятор предупреждать, что такой-то кусок кода выглядит подозрительным. Добавить сверху завтипов и вот тогда получится инструмент, который точно стоит изучать. Но вот парадокс — если начать пилить такое сейчас, то у языка будет полтора фаната, потому что весь интерес и поддержка С++ произростают из компаний, у которых огромное наследние кода и желание хоть как-то оптимизировать этого монстра.
Здравствуйте, cppguard, Вы писали:
C>По-хорошему, нужно выкинуть всё наследние, оставить только нормальные правила, и научить компилятор предупреждать, что такой-то кусок кода выглядит подозрительным. Добавить сверху завтипов и вот тогда получится инструмент, который точно стоит изучать.
Ты сейчас rust описал. Он, правда, не про зависимые типы. Но там другие методы устранения ошибок.
А ЗТ сами по себе с практической точки зрения штука весьма убогая.
C>Но вот парадокс — если начать пилить такое сейчас, то у языка будет полтора фаната, потому что весь интерес и поддержка С++ произростают из компаний, у которых огромное наследние кода и желание хоть как-то оптимизировать этого монстра.
Rust взлетел.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>А ЗТ сами по себе с практической точки зрения штука весьма убогая.
Я всё хотел подступиться к формальной верификации программ, но не знал, с какой стороны. Начал с Idris. Мне пока нравится, хотя до прикладного использования я пока не дошёл.
WH>Rust взлетел.
Я бы сказал, что начал набирать высоту и пока её не теряет, но про успешный успех говорить рано.
LVV>> Тогда вы должны понимать, что обучение программированию — это не изучение конкретного языка. R>Так и есть. И очень хреново начинать с языка сделанного для тупых.
Учите на Кумире.
И прочитайте Дейкстру "Смиренный программист".
А пока эффект Даннинга — Крюгера во всей красе
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>> R>Так и есть. И очень хреново начинать с языка сделанного для тупых. LVV>> Учите на Кумире. R>Я этим уже, слава всевышнему, не занимаюсь. LVV>> И прочитайте Дейкстру "Смиренный программист". LVV>> А пока эффект Даннинга — Крюгера во всей красе R>Нет, про тупых не я сказал, а Роб Пайк, господин диагност.
Автор языка имеет право называть свой язык как угодно.
Это не значит, что за ним надо повторять...
Учите на APL...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>Учите на APL... P>Ты еще и APL знаешь? Я пару раз код в книжках видел. А как на нем программировать? У него с Фортраном ничего общего.
Да это я его троллю...
Мой оппонент жаждет язык для не тупых — вот как раз пусть посмотрит, какие они бывают.
В одной из книжек было написано, что один из гуру как-то разбирал программу из 4 строчек 4 часа...
Насколько я знаю, в СССР не было компом с APL.
Но книжка у меня была и я ее читал.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>В одной из книжек было написано, что один из гуру как-то разбирал программу из 4 строчек 4 часа...
Я ж говорил, с Фортраном ничего общего. В Фортране тоже не всегда всё просто, только нормальные люди не используют всякие странные конструкции типа RETURN с меткой или безымянные COMMON-блоки, да еще по-разному определенные в разных программных единицах.
LVV>Насколько я знаю, в СССР не было компом с APL.
Я и позже живого APL не встречал. Только статьи.
LVV>Но книжка у меня была и я ее читал.
А я в библиотеке брал. По содержанию какой-то ужастик.
Здравствуйте, LaptevVV, Вы писали:
LVV> R>Нет, про тупых не я сказал, а Роб Пайк, господин диагност.
LVV> Автор языка имеет право называть свой язык как угодно. LVV> Это не значит, что за ним надо повторять...
Он так охарактеризовал не язык, а его целевую аудиторию.
LVV> Учите на APL...
Я не из академической среды, мне такая хрень не подходит.
LVV>> Автор языка имеет право называть свой язык как угодно. LVV>> Это не значит, что за ним надо повторять... R>Он так охарактеризовал не язык, а его целевую аудиторию.
Ну, это каждый понимает в меру СВОЕЙ испорченности (с) LVV>> Учите на APL... R>Я не из академической среды, мне такая хрень не подходит.
Вот вы даже не знаете, что APL родился как язык описания архитектуры IBM/360
Ни о какой академической среде там и не пахло.
Потом фирма IBM сделала из него язык программирования и выпустила отдельную специальную миниЭВМ для работы с этим языком.
Но в СССР эти машины не попали.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV> R>Он так охарактеризовал не язык, а его целевую аудиторию.
LVV> Ну, это каждый понимает в меру СВОЕЙ испорченности (с)
Это его прямая речь! Хотя, да, не тупые, а альтернативно одаренные
LVV> R>Я не из академической среды, мне такая хрень не подходит.
LVV> Вот вы даже не знаете, что APL родился как язык описания архитектуры IBM/360 LVV> Ни о какой академической среде там и не пахло.
Я о том, что только академической среде эти копролиты и могут быть интересны.
S>Надо было разрешить выбирать несколько вариантов, т.к. это еще и от проекта зависит. Например, в каких-то проектах все еще C++14, в каких-то все еще C++17.
Цель выявить лишь одну версию стандарта на программиста.
При множественном выборе кто-то проголосует за одну версию стандарта, а кто-то за несколько. В результате что-то может показаться популярнее другого на основе незначительной популярности.
Вот если бы голос можно было разделять, для примера 43% одного голоса программиста за C++14, а 57% голоса этого же программиста за C++17, тогда ещё можно было бы подумать.
А так выбора нет, приходится ограничиваться наивысшим приоритетом. Но это тоже не так плохо, каждый программист определяет какая версия стандарта для него важнее, что я и хотел увидеть в опросе.
Здравствуйте, LaptevVV, Вы писали:
LVV>Вот вы даже не знаете, что APL родился как язык описания архитектуры IBM/360
А вот это я как-то пропустил. Я считал, что это про REXX. Я его немножечко видел в ПДО и в Полуоси. Говорят, он и сейчас жив. Внешне он ближе к Фортрану, чем APL.
LVV>>Вот вы даже не знаете, что APL родился как язык описания архитектуры IBM/360 P>А вот это я как-то пропустил. Я считал, что это про REXX. Я его немножечко видел в ПДО и в Полуоси. Говорят, он и сейчас жив. Внешне он ближе к Фортрану, чем APL.
В Википеди написано:
Язык APL был разработан Кеном Айверсоном, преподававшим тогда в Гарвардском университете, в качестве системы обозначений для описания вычислений.
В 1957 вышла его книга «A Program Language»[5], в которой эта нотация была описана.
В 1960 году Айверсон продолжал работу над APL в IBM. Здесь этот язык использовался для описания машинной архитектуры.
Про 1957 год я не знал, а вот про 1960 и далее я еще в Советском Союзе читал.
Нотация APL сродни стенографии...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Про 1957 год я не знал, а вот про 1960 и далее я еще в Советском Союзе читал.
Шо? APL старше Кобола? Который, конечно, не Фортран, но тоже ничего. Я про APL читал где-то в 80-е. Но в тех материалах о нем рассказывали как о суперкалькуляторе.
Позже, когда я работал в НИИ, дядьки-математики почему-то предпочли Фортран.
LVV>Нотация APL сродни стенографии...
Что-то вспомнилось. Однокурсник стенографировал лекции по общественным предметам, потом расшифровывал. Его записи выглядели чем-то инопланетным.
Даже не представляю, как быть с APL. Кто его расшифрует.
Здравствуйте, velkin, Вы писали:
V>>>каждый программист определяет какая версия стандарта для него важнее S>>Программист определяет?
V>Именно так, в опросе каждый указывает то, что хочет он сам, то что лично для него более приоритетно.
Опрос спрашивает о том, какой стандарт C++ используется программистом. Программисты работают над проектами. Проекты диктуют используемый в проекте стандарт. Далеко не каждый программист, участвующий в разработке проекта, может повлиять на выбор стандарта C++ для проекта. Но каждый может сказать, какой стандарт он использует.
Для того, чтобы узнать какой стандарт приоритетен для программистов в 2023-ем году, следовало бы по другому сформулировать основной вопрос в вашем опросе. Например, на "какой бы стандарт C++ вы бы выбрали в 2023-ом если бы у вас была возможность свободного выбора".
Здравствуйте, so5team, Вы писали:
S>Для того, чтобы узнать какой стандарт приоритетен для программистов в 2023-ем году, следовало бы по другому сформулировать основной вопрос в вашем опросе. Например, на "какой бы стандарт C++ вы бы выбрали в 2023-ом если бы у вас была возможность свободного выбора".
Вопрос сформулирован правильно, как его понял, так и отвечай. Если у тебя какое-то иное понимание, нежели у других, то просто голосуй согласно своему пониманию. Но обращу внимание, что вопрос не про если бы и ка бы.
Лично я использую C++03, то есть я понимаю, что прописываю инструкции согласно именно этой версии стандарта, а не просто что-то там умозрительно выбрал. И не важно, что программа может скомпилироваться на других версиях стандарта, я то понимаю, что именно я пишу.
Потому не нужно особо заморачиваться насчёт свободы выбора. Если кого-то заставили писать на какой-то версии стандарта, и он на ней действительно пишет, то можно проголосовать и так. Но если у него же есть домашний проект и в нём он применяет иную версию C++ потому, что склоняется к ней, то можно выбрать и её.
Ещё раз повторяю, это выбор программиста как голосовать, но слово используете там не просто так написано. Предполагается, что программист умеет использовать выбранную версию стандарта C++, а не просто хотел бы когда-нибудь её использовать.
Здравствуйте, velkin, Вы писали:
V>Вопрос сформулирован правильно, как его понял, так и отвечай.
Простите, я находился при мнении, что правильно сформулированный вопрос не допускает разночтений и противоречащих друг другу трактовок, но, вероятно, просто отстал о жизни.
Здравствуйте, so5team, Вы писали:
V>>Вопрос сформулирован правильно, как его понял, так и отвечай. S>Простите, я находился при мнении, что правильно сформулированный вопрос не допускает разночтений и противоречащих друг другу трактовок, но, вероятно, просто отстал о жизни.
Вопрос крайне простой.
Какой стандарт C++ вы используете в 2023 году?
Если тебе нужен контракт на десять страниц, то да, такого нет и не будет.
Это профессиональная деформация, если в голову лезут всякие посторонние мысли. Вроде, а где используете, а на работе или для себя, а если меня заставили, а если бы я сам лично хотел использовать, а то, а это, а точная формулировка вопроса вроде огромного многостраничного документа, и так далее.
Проголосовал и ладно. В итоге видим некие тренды, пусть и на малой выборке. Я бы лучше обсудил результаты голосования, нежели кто что думал, когда это делал. А вот они довольно интересны.
Здравствуйте, velkin, Вы писали:
V>Вопрос крайне простой.
Дополнения к нему вы делаете не такие уж и простые. В частности "каждый программист определяет какая версия стандарта для него важнее", поскольку "для него важнее" и "использует" далеко не всегда тождественны.
V>Если тебе нужен контракт на десять страниц, то да, такого нет и не будет.
У меня было подозрение, что вы можете намерять не то, что собирались. На что и попытался указать.
Но, видимо, вы что-то хотели измерить, и это что-то, в итоге и измерили. Понять что и зачем у меня не получается, но да это совершенно не важно.
Здравствуйте, so5team, Вы писали:
S>Например, на "какой бы стандарт C++ вы бы выбрали в 2023-ом если бы у вас была возможность свободного выбора".
В настройках компилятора я как правило ставлю самый последний доступный, чтоб потом два раза не бегать. Это ж не питон, который сам с собой не совместим.
А вот какие фичи будут реально из него использоваться — это уже как понадобится. Я не очень помню что в каком году появилось.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, velkin, Вы писали:
V>Предполагается, что программист умеет использовать выбранную версию стандарта C++, а не просто хотел бы когда-нибудь её использовать.
Они не настолько драматически отличаются чтоб надо было использовать именно конкретную версию, скорее это диктуется доступностью определённых фич языка.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, velkin, Вы писали:
V>Вопрос крайне простой. V>Какой стандарт C++ вы используете в 2023 году?
Ну вот допустим я включил в опциях C++20 стандарт, весь код написал вообще в С стиле, а потом взял и добавил в одном месте range for.
Это какой стандарт получается по твоей логике?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, rudzuk, Вы писали:
R>Так и есть. И очень хреново начинать с языка сделанного для тупых.
Это какой язык создан для тупых? Go чтоль ?
Вообще, язык для самых умных я знаю. Brainfuck называется. Все остальные — для тупых однозначно!!!! Хотя, есть еще язык whitespace — тоже вполне для умных.
А если брать Паскаль. То практика показывает, что его осилить на минимальном уровне сильно сложнее, чем тот же Питон. По крайней мере что то простое на Питоне в состоянии написать крайне многие школьники. Во времена актуальности паскаля программы перемножения матриц сдавались в качестве курсового на всяческих факультетах машиностроения, и процентов 95 студентов это были написать не в состоянии и такой сложный курсовой покупали и тех, кто хоть как то умел программировать. В то время даже набрать программу готовую было неимоверно сложно, многие обладатели диплома программиста это были сделать не в состоянии . Даже hello world многие программисты получали диплом, а так и не в состоянии были написать ни на одном из языков программирования. А сейчас на современных языках как то уже получается осилить. А вот если брать досовский паскаль — снова у начинающих с ним неимоверные сложности. Так что паскаль совсем не для тупых.
Здравствуйте, CreatorCray, Вы писали:
V>>Вопрос крайне простой. V>>Какой стандарт C++ вы используете в 2023 году? CC>Ну вот допустим я включил в опциях C++20 стандарт, весь код написал вообще в С стиле, а потом взял и добавил в одном месте range for. CC>Это какой стандарт получается по твоей логике?
А что тут непонятного, когда пишешь код ориентируешься на определённую версию стандарта. Она разрешает или запрещает определённые инструкции (+stl), а так же понимает под ними именно то, что предусмотрено в этой версии стандарта. Конечно, не стоит забывать и о зависимости от реализации компилятора.
Лучше сразу определиться, что конкретно используешь в проекте, как для себя, так и для других, если они есть. Если не определишься для себя, то будет мешанина непонятно чего. А если будут ещё и другие люди, то там может оказаться ещё трешовее, когда каждый начнёт добавлять всё, что ему вздумается в контексте самовольно выбранной версии стандарта C++.
Разброд и шатания не нужны. А Си стиль в C++ это элемент архитектуры программы. Тем более ты ведь понимаешь, что Си и Си стиль в C++ это не одно и тоже. То есть вопрос у тебя по частичной совместимости между разными версиями Си и разными версиями C++.
И тут я могу сказать только, что если хочешь такую совместимость, то о части возможностей разных языков программирования или их версий придётся забыть. Плюс придётся проверять на такую совместимость разные версии стандарта или стандартов, а так же компиляторов, если у тебя они есть.
Но представим, что программист определился с версией стандарта и использует её на полную катушку. Вот и выходит, что лично ты можешь писать суперсовместимые хеллоу ворлды, которые работают и там и здесь. Однако с таким посылом часть возможностей остаётся не задействованной.
LVV>>Нотация APL сродни стенографии... P>Что-то вспомнилось. Однокурсник стенографировал лекции по общественным предметам, потом расшифровывал. Его записи выглядели чем-то инопланетным. P>Даже не представляю, как быть с APL. Кто его расшифрует.
Я ж говорю: в какой-то книжке было написано, что один гуру расшифровывал прогу из 4 строк более 4 часов...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, tapatoon, Вы писали:
T>Пример1 T>У нас куча сущностей, каждая из которых может поддерживать любой набор из множества функциональных методов. Что мы делаем в С++? Мы делаем как-то так: T>
T>#include <библиотека общей функциональности>
T>class Entity1 : public func1, func2 {};
T>class Entity2 : public func1, func3 {};
T>class Entity3 : public func1 {};
T>
Зачем столько писанины?
#include"../.../../../../../../../shared/my-lib.h"#define MyFeature func1, func2
#define CompleteFeature MyFeature, UselessGC
#define CompleteFeatureIMeanIt CompleteFeature, EXXtras
class MegaFeature : public CompleteFeatureIMeanIt {};
.
e> А если брать Паскаль. То практика показывает, что его осилить на минимальном уровне сильно сложнее, чем тот же Питон.
Про змеюку можно вообще не говорить. Язык в котором логика зависит от форматирования — не нужен! Ну, т.е. школота может играться, конечно, но в целом — не нужен.
e> Во времена актуальности паскаля программы перемножения матриц сдавались в качестве курсового на всяческих факультетах машиностроения, и процентов 95 студентов это были написать не в состоянии и такой сложный курсовой покупали и тех, кто хоть как то умел программировать.
Отличное подтверждение известного тезиса. Хотя, скорее всего, просто не видели смысла изучать информатику/программирование, как непрофильное. Я знаю ВУЗ, где лингвистам (кажется) сишечку преподавали Я офигел, когда мне девочка об этом рассказывала.
e> В то время даже набрать программу готовую было неимоверно сложно, многие обладатели диплома программиста это были сделать не в состоянии . Даже hello world многие программисты получали диплом, а так и не в состоянии были написать ни на одном из языков программирования.
Какие-то странные программисты... Без рук что ли?
e> А вот если брать досовский паскаль — снова у начинающих с ним неимоверные сложности.
Проблемы именно с досовским паскалем? Или с теми, кто в 2023 году использует досовский паскаль? Впрочем, я все равно не помню каких-либо проблем с досовским паскалем. Отличные были инструменты своего времени — лучшие!
e> Так что паскаль совсем не для тупых.
Конечно не для тупых! Язык обучения и не должен быть языком для тупых. Язык обучения должен быть простым и поняным, должен заложить основы, дать понимание базовых вещей. Но он не должен быть языком для тупых. Паскаль именно такой язык.
Здравствуйте, velkin, Вы писали:
CC>>Ну вот допустим я включил в опциях C++20 стандарт, весь код написал вообще в С стиле, а потом взял и добавил в одном месте range for. CC>>Это какой стандарт получается по твоей логике? V>Си и Си стиль в C++ это не одно и тоже.
Ты на вопрос так и не ответил.
V>А что тут непонятного, когда пишешь код ориентируешься на определённую версию стандарта.
Да не то чтобы.
V> Она разрешает или запрещает определённые инструкции
И какие же "инструкции" были запрещены ну к примеру в С++14 по сравнению с С++11?
V>а так же понимает под ними именно то, что предусмотрено в этой версии стандарта.
Опять таки, смысл чего поменялся между теми же 11 и 14 версиями?
V>Конечно, не стоит забывать и о зависимости от реализации компилятора.
Вот это уже теплее.
V> То есть вопрос у тебя по частичной совместимости между разными версиями Си и разными версиями C++.
Это надо очень специфичные и версии и код искать чтоб вылезло что то реально существенное.
V>И тут я могу сказать только, что если хочешь такую совместимость, то о части возможностей разных языков программирования или их версий придётся забыть. Плюс придётся проверять на такую совместимость разные версии стандарта или стандартов, а так же компиляторов, если у тебя они есть. V>Но представим, что программист определился с версией стандарта и использует её на полную катушку. Вот и выходит, что лично ты можешь писать суперсовместимые хеллоу ворлды, которые работают и там и здесь. Однако с таким посылом часть возможностей остаётся не задействованной.
Эта болтология не интересна.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
S>Это может больно укусить если приходится пользоваться разными компиляторами на разных платформах.
Компилятор задаётся под проект. Никто в здравом уме не станет метаться туда-сюда.
S>Местами и в C++ бывают грабли
Это больше на баг компилятора похоже.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
V>> Она разрешает или запрещает определённые инструкции CC>И какие же "инструкции" были запрещены ну к примеру в С++14 по сравнению с С++11?
V>>а так же понимает под ними именно то, что предусмотрено в этой версии стандарта. CC>Опять таки, смысл чего поменялся между теми же 11 и 14 версиями?
Справедливости ради — загугли "until C++11" site:cppreference.com, а то слабые аргументы получаются.
Здравствуйте, cppguard, Вы писали:
K>>А что такое метапрограммирование — макросы?
C>Шаблоны.
Не просто шаблоны, а шаблоны, фаршированные шаблонами, фаршированные шаблонами, ...
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
S>>Это может больно укусить если приходится пользоваться разными компиляторами на разных платформах. CC>Компилятор задаётся под проект. Никто в здравом уме не станет метаться туда-сюда.
Какая категоричность, аж дух захватывает. Вообще-то мир очень разный и проекты бывают очень разные.
S>>Местами и в C++ бывают грабли CC>Это больше на баг компилятора похоже.
Это больше на баг (точнее на белое пятно) в стандарте C++17 похоже, а clang до недавнего времени строго следовал стандарту. Это белое пятно исправили в C++20 (P1091R3, раздел 10).
Здравствуйте, CreatorCray, Вы писали:
V>>а так же понимает под ними именно то, что предусмотрено в этой версии стандарта. CC>Опять таки, смысл чего поменялся между теми же 11 и 14 версиями?
auto стало можно использовать в качестве параметров в лямбдах. Т.е. в C++14 стало можно так:
auto fn = [](auto a, auto b) {...};
Что вывело удобство написания лямбда-функций просто на совсем другой уровень. Особенно в шаблонном коде.
В C++11 для подобного приходилось вспомогательные типы-функторы с operator() определять.
Еще в C++14 сделали полноценный вывод типов возвращаемых значений для функций/методов.
В C++11 нельзя было просто написать auto в качестве возвращаемого значения, нужно было выводить тип после списка параметров, т.е.:
auto func() -> some_type {...}
Тогда как в C++14 компилятор уже сам мог выводить этот самый some_type:
auto func() {...}
Что, опять же, сильно повысило удобство использования шаблонов.
Там еще несколько полезных вещей было сделано (вроде init-выражения в lambda capture list). Но эти две сходу вспоминаются, т.к. после них с C++14 обратно на C++11 переключаться было очень больно.
T>С/С++ даёт вам свободу. Как её использовать — для багов или для уникальных фичей, зависит только от вас Ocaml is slower than C but faster than C++.
Уже одно это говорит что ЯП не очень.
Сильно не углублялся в плюсы, но издалека они очень похожи на жаваскрипт.
Это как дисплозия соединительной ткани. Гибкость есть, а вот ходить нормально не получается.
Здравствуйте, tapatoon, Вы писали:
T>Отвечаю — в С/С++
T>Объясняю на примерах почему
Примеры нерелевантны ситуации на рынке труда. Что востребовано- туда и нужно идти. Сиплюсы давно стали узко специализированной сектой, причём предложение опытных синьёрных "кому за 40" помидоров намного превышает спрос.
Сейчас набежит полтора плюсника- железячник Крейтор и суппортер легаси пластов еао86 ака состим, опять повторят очевидные вещи. Все всплакнут, что веб отжал 90% разработки, и остагутся при своих.
Аё>Все всплакнут, что веб отжал 90% разработки, и остагутся при своих.
Ну, "матерый С++ник кому за 40" без особых проблем может перейти в веб.
А вот обратный переход практически невозможен...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Ну, "матерый С++ник кому за 40" без особых проблем может перейти в веб. LVV>А вот обратный переход практически невозможен...
Всегда интересовала логика подобных высказываний. Типа С++-сники дофига такие умные, а веб — мартышкин труд? Мой опыт говорит, что программисты, которые имеют дело исключительно с С++, имеют самый зашоренный взгляд и, как в старой шутке, на любом языке будут писать как на С++.
LVV>>Ну, "матерый С++ник кому за 40" без особых проблем может перейти в веб. LVV>>А вот обратный переход практически невозможен... C>Всегда интересовала логика подобных высказываний. Типа С++-сники дофига такие умные, а веб — мартышкин труд? Мой опыт говорит, что программисты, которые имеют дело исключительно с С++, имеют самый зашоренный взгляд и, как в старой шутке, на любом языке будут писать как на С++.
Не так.
Вот я имел дело с начинающими программерами.
И за 2.5 десятка лет неоднократно наблюдал, что школьники, освоившие языки веб даже на хорошем уровне, испытывают БОЛЬШИЕ проблемы с освоением указателей.
Большинство — не осваивает.
О том же писал когда-то Джоэл Спольски.
У них в МИТ при освоении программирования было несколько порогов, два из которых я тоже отмечал у студентов: рекурсия и указатели.
Про указатели он, помнится, писал, что одни — налево (в системные программеры), а другие — направо (в прикладные).
Про обратный переход (от С++) могу сказать, что основная сложность — в освоении инструментария веб-разработки.
Я просто это попробовал.
И где-то за 3 недели от полного нуля в вебе дошел до способности (в моем-то возрасте) написать фронтендную игрушку на JS...
И понимал про node.js
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, so5team, Вы писали:
CC>>Опять таки, смысл чего поменялся между теми же 11 и 14 версиями? S>auto стало можно использовать в качестве параметров в лямбдах. Т.е. в C++14 стало можно так:
Это ж добавилась удобняшка а не поменялся смысл старого.
S>Еще в C++14 сделали полноценный вывод типов возвращаемых значений для функций/методов.
Это тоже добавленое а не изменённое.
Ну т.е. получается таки если включить в настрйках проекта сразу максимальную поддерживаемую компилером версию стандарта то писать код можно в стиле почти любой версии до него без особых запарок.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
S>Вообще-то мир очень разный и проекты бывают очень разные.
Никто такой фигнёй не станет заниматься без крайней на то нужды. И если приходится так страдать то у проекта и без того будет куча проблем
S>Это больше на баг (точнее на белое пятно) в стандарте C++17 похоже, а clang до недавнего времени строго следовал стандарту.
Мб, мне на сам стандарт давно до лампочки, я смотрю исключительно на то, что генерит компилятор. Ибо теория ну очень отличается от практики.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, LaptevVV, Вы писали:
LVV>Ну, "матерый С++ник кому за 40" без особых проблем может перейти в веб.
Может, при должной подготовке, штудировании книжек и т.п.- причём, без потери в деньгах.
LVV>А вот обратный переход практически невозможен...
Обратный переход выглядит примерно так:
-хммм ну вот вы ответили на все вопросы, да, неожидали мы такие умные плюсники от жабиста убогонького хихи... а сколько лет говорите, отрыв от плюсного станка? 5 лет? Так так, нехорошо это"
Сколько же вы хотите?
--Ну я сейчас получаю скромно, XXX, меньше никак не может быть.
"у обоих интервьюверов глаза округляются, грохот падающей на пол челюсти"- мы вам перезвоним (C).
Здравствуйте, CreatorCray, Вы писали:
Аё>>железячник Крейтор CC>Как много порой узнаёшь о своей специализации на кывте CC>Нет, Артёмка, я не железячник.
Ты не проектировщик IC конечно же, но на низком уровне с железом толи дрова толи фильтры в близко к ядру пишешь. Короче, железячник.
LVV>>А вот обратный переход практически невозможен... Аё>Обратный переход выглядит примерно так: Аё>-хммм ну вот вы ответили на все вопросы, да, неожидали мы такие умные плюсники от жабиста убогонького хихи... а сколько лет говорите, отрыв от плюсного станка? 5 лет? Так так, нехорошо это" Аё>Сколько же вы хотите? Аё>--Ну я сейчас получаю скромно, XXX, меньше никак не может быть. Аё>"у обоих интервьюверов глаза округляются, грохот падающей на пол челюсти"- мы вам перезвоним (C).
Ну, у меня тогда вопрос: а чего это из веба в С++ подался-то, если там так хорошо было.
А во-вторых почитай мой ответ про молодых программеров.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, CreatorCray, Вы писали:
CC>Это ж добавилась удобняшка а не поменялся смысл старого. CC>Это тоже добавленое а не изменённое.
Так исходная формулировка -- "А что тут непонятного, когда пишешь код ориентируешься на определённую версию стандарта. Она разрешает или запрещает определённые инструкции" -- говорит не только о запретах, но и новых возможностях. Вот в C++14 появилось несколько фич, которых не было в C++11, т.е. С++14 разрешил определенные инструкции.
Причем пара из упомянутых мной вещей (реальный auto для вывода типа возвращаемого значения и init-выражения в capture list) сделала доступным то, что в рамках C++11 делалось э... через одно место и с кучей ненужных усилий.
Собственно, само по себе высказывание "пишешь под определенный стандарт C++" означает не что иное, как использование фич из стандарта, которых не было в предыдущих стандартах. Из-за чего откат на предыдущий стандарт либо невозможен, либо слишком дорог.
И это как бы не совсем то, что "включаешь определенный стандарт в опциях компилятора", т.к. в большинстве случаев нормально написанный код на C++14 будет компилироваться и в режиме C++17, и C++20 (а в скором времени и в C++23).
Здравствуйте, CreatorCray, Вы писали:
S>>Вообще-то мир очень разный и проекты бывают очень разные. CC>Никто такой фигнёй не станет заниматься без крайней на то нужды.
"Отучаемся говорить за всех" (с)
CC>И если приходится так страдать то у проекта и без того будет куча проблем
Не думаю, что разработчики Qt или какого-нибудь Connext DDS (или OpenDDS) так уж страдают и имеют кучу проблем.
Здравствуйте, so5team, Вы писали:
S> говорит не только о запретах, но и новых возможностях.
Поскольку в С++ всё ещё стараются заботиться об обратной совместимости то за новые возможности переживать не стоит — в максимально поддерживаемом стандарте они все должны наличествовать.
Так что переживать стоит только за то, что было запрещено после какой то версии.
Об этом и была речь — что ж там такого было запрещено?
S>сделала доступным то, что в рамках C++11 делалось э... через одно место и с кучей ненужных усилий.
Это скомпилируется в С++20?
S>Собственно, само по себе высказывание "пишешь под определенный стандарт C++" означает не что иное, как использование фич из стандарта, которых не было в предыдущих стандартах.
Это означает именно что ограничивание себя именно этой версией стандарта, тогда как обычно пишут так, как лучше выходит.
Предлагаешь потом лазить по коду и выяснять какой же итоговый набор фич был использован и какому стандарту он соответствует?
Нафига?
S> Из-за чего откат на предыдущий стандарт либо невозможен, либо слишком дорог.
А зачем вообще этот откат?
S>И это как бы не совсем то, что "включаешь определенный стандарт в опциях компилятора", т.к. в большинстве случаев нормально написанный код на C++14 будет компилироваться и в режиме C++17, и C++20 (а в скором времени и в C++23).
Верно. Потому нет никакой нужды ставить для нового проекта что либо ниже чем текущий стандарт, чтоб просто писать и не париться что в какой то момент придётся лезть и поднимать версию стандарта просто потому что понадобилась более новая фича
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
CC>>Никто такой фигнёй не станет заниматься без крайней на то нужды. S>"Отучаемся говорить за всех" (с)
Ты правда сейчас хочешь сказать что ты станешь заниматься такой фигнёй без крайней на то нужды?
CC>>И если приходится так страдать то у проекта и без того будет куча проблем S>Не думаю, что разработчики Qt или какого-нибудь Connext DDS (или OpenDDS) так уж страдают и имеют кучу проблем.
Таки страдают и таки имеют. Поддержка зоопарка версий это тот ещё геморрой.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
S>> говорит не только о запретах, но и новых возможностях. CC>Поскольку в С++ всё ещё стараются заботиться об обратной совместимости то за новые возможности переживать не стоит — в максимально поддерживаемом стандарте они все должны наличествовать.
Не обязательно. Сходу вспоминается std::aligned_storage, введенный в C++11 и помеченный к удалению в C++23. Или uncaught_exception, который был до C++11, видоизменился в C++11 (помечен как noexcept вместо throw), помеченный к удалению в C++17 и удаленный в C++20.
CC>Об этом и была речь — что ж там такого было запрещено?
Между C++11 и C++14, емнип, ничего не запрещалось.
S>>сделала доступным то, что в рамках C++11 делалось э... через одно место и с кучей ненужных усилий. CC>Это скомпилируется в С++20?
Должно.
S>>Собственно, само по себе высказывание "пишешь под определенный стандарт C++" означает не что иное, как использование фич из стандарта, которых не было в предыдущих стандартах. CC>Это означает именно что ограничивание себя именно этой версией стандарта
Да.
CC>тогда как обычно пишут так, как лучше выходит.
В первый раз с таким сталкиваюсь. Везде были ограничения на максимальную версию стандарта (или версию компилятора, если стандарт еще не полностью реализован, как это было с долгостроями C++98, C++11 и нынешним C++20). Но это мой опыт, он сильно ограничен.
CC>Предлагаешь потом лазить по коду и выяснять какой же итоговый набор фич был использован и какому стандарту он соответствует?
Не нужно лазить. Обычно у компиляторов есть ключики -std.
CC>Нафига?
Что бы не иметь проблем с переносом софта на другой компилятор/платформу.
S>> Из-за чего откат на предыдущий стандарт либо невозможен, либо слишком дорог. CC>А зачем вообще этот откат?
Именно откат -- это форс-мажор, означающий что кто-то где-то сильно облажался.
А вот чтобы такого форс-мажора не было, в определенном классе ПО ограничивают версию стандарта для того, чтобы иметь возможность собирать софт разными компиляторами на разных платформах.
S>>И это как бы не совсем то, что "включаешь определенный стандарт в опциях компилятора", т.к. в большинстве случаев нормально написанный код на C++14 будет компилироваться и в режиме C++17, и C++20 (а в скором времени и в C++23). CC>Верно. Потому нет никакой нужды ставить для нового проекта что либо ниже чем текущий стандарт
Это от типа проекта зависит. Ну и от желания побегать по граблям самых свежих версий компиляторов, в которых поддержка новых фич из новых стандартов еще только-только появилась.
Здравствуйте, CreatorCray, Вы писали:
CC>>>Никто такой фигнёй не станет заниматься без крайней на то нужды. S>>"Отучаемся говорить за всех" (с) CC>Ты правда сейчас хочешь сказать что ты станешь заниматься такой фигнёй без крайней на то нужды?
Хорошо бы определить понятие "крайней нужды". Ибо для проектов, вроде Qt, Connext DDS или nginx переносимость на разные платформы и разные компиляторы -- это повседневная обыденность.
CC>>>И если приходится так страдать то у проекта и без того будет куча проблем S>>Не думаю, что разработчики Qt или какого-нибудь Connext DDS (или OpenDDS) так уж страдают и имеют кучу проблем. CC>Таки страдают и таки имеют. Поддержка зоопарка версий это тот ещё геморрой.
Да? Ну ладно, геморрой так геморрой, хоть буду знать как это называется.
Здравствуйте, so5team, Вы писали:
S>Не обязательно. Сходу вспоминается std::aligned_storage
Это ж не часть самого языка
S>Или uncaught_exception, который был до C++11, видоизменился в C++11 (помечен как noexcept вместо throw), помеченный к удалению в C++17 и удаленный в C++20.
Опять таки не часть именно что самого языка.
S>Между C++11 и C++14, емнип, ничего не запрещалось.
Так и дальше не припоминается чтоб именно в языке что то кардинально менялось.
Вот в сравнении с до-С++11 то же ключевое слово auto изменило смысл. Это ломающее изменение именно языка, пусть даже оно уже сто лет как не использовалось.
S>>>Собственно, само по себе высказывание "пишешь под определенный стандарт C++" означает не что иное, как использование фич из стандарта, которых не было в предыдущих стандартах. CC>>Это означает именно что ограничивание себя именно этой версией стандарта S>Да.
А зачем?
S>В первый раз с таким сталкиваюсь. Везде были ограничения на максимальную версию стандарта
А смысл?
S> или версию компилятора
Вот это уже смысл имеет. Но ограничение не сверху а снизу. Т.е. минимальная версия компилятора.
CC>>Предлагаешь потом лазить по коду и выяснять какой же итоговый набор фич был использован и какому стандарту он соответствует? S>Не нужно лазить. Обычно у компиляторов есть ключики -std.
Не, наоборот. Я сомневаюсь что все помнят в какой версии какие фичи добавились, потому код пишу с использованием тех фич, которые для него подходят лучше всего. И мне пофигу из какой они версии. Потому и не вижу никакой логики в ограничивании сверху.
S>Что бы не иметь проблем с переносом софта на другой компилятор/платформу.
Проблемы будут полюбас, но другие.
Компиляторы развиваются вверх а не вниз, и чота мне кажется что вероятность что надо будет внезапно (т.е. не запланированно) переносить на более древний компилятор для нового проекта крайне мала, и более того практически бессмысленна.
S>>> Из-за чего откат на предыдущий стандарт либо невозможен, либо слишком дорог. CC>>А зачем вообще этот откат? S>Именно откат -- это форс-мажор, означающий что кто-то где-то сильно облажался.
Облажался как именно? И кто?
S>в определенном классе ПО
Ну вот начинаем подбираться к тому, что подобные навороты могут пригодиться в очень узком зоопарке.
Я пишу системный код под линейку довольно таки разных девайсов и то давно уже есть поддержка С++20 на них всех.
S> ограничивают версию стандарта для того, чтобы иметь возможность собирать софт разными компиляторами на разных платформах.
Возможность или таки необходимость. Потому как если это надо "чтоб было" то это добровольное ломание себе ног на случай возможного участия в параолимпиаде.
CC>>Верно. Потому нет никакой нужды ставить для нового проекта что либо ниже чем текущий стандарт S>Это от типа проекта зависит. Ну и от желания побегать по граблям самых свежих версий компиляторов
Никто не берёт под проект альфу наиновейшего компилятора, все пользуют тот, который уже проверен. И там нет никакого смысла занижать версию стандарта.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
CC>>Ты правда сейчас хочешь сказать что ты станешь заниматься такой фигнёй без крайней на то нужды? S>Хорошо бы определить понятие "крайней нужды".
Ты ж сам его и дал: когда есть реальная, а не гипотетическая, необходимость обеспечить собираемость на всяком хламе.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, so5team, Вы писали:
S>>Не обязательно. Сходу вспоминается std::aligned_storage CC>Это ж не часть самого языка
Так-то стандартная библиотека -- это часть языка. Например, std::forward и std::move -- реализованы в виде библиотечных функций, но это часть языка, без которой программировать, наверное, можно, но зачем. Точно так же, std::less, будучи библиотечным классом, позволяет безопасно делать то, что на "голом" языке делать не следует (сравнивать указатели между собой). Ну или std::launder -- это часть языка, хотя и представляет из себя библиотечный вызов.
S>>Между C++11 и C++14, емнип, ничего не запрещалось. CC>Так и дальше не припоминается чтоб именно в языке что то кардинально менялось.
В C++17 окончательно выпилили std::auto_ptr и триграфы. И если с триграфами ладно, вряд ли они у кого-то были, но вот без std::auto_ptr старый код новыми компиляторами в 17-ом стандарте уже не собирается.
S>>>>Собственно, само по себе высказывание "пишешь под определенный стандарт C++" означает не что иное, как использование фич из стандарта, которых не было в предыдущих стандартах. CC>>>Это означает именно что ограничивание себя именно этой версией стандарта S>>Да. CC>А зачем?
Например: не париться, если приходит заказчик с пожеланием видеть софт на своей платформе, а там у него только C++14. И более свежий не предвидится в перспективе нескольких нет. Причины тому могут быть разными, начиная от наличия сертификатов от каких-либо проверяющих органов, до банального нежелания покупать новую версию VisualStudio.
S>>В первый раз с таким сталкиваюсь. Везде были ограничения на максимальную версию стандарта CC>А смысл?
Если делается библиотека, то чем ниже стандарт, тем больше народу сможет ее использовать. Это как один из примеров.
CC>Не, наоборот. Я сомневаюсь что все помнят в какой версии какие фичи добавились, потому код пишу с использованием тех фич, которые для него подходят лучше всего. И мне пофигу из какой они версии. Потому и не вижу никакой логики в ограничивании сверху.
Ну вот такой подход и бьет потом по рукам, когда выясняется, что задействовали концепты из C++20, а нужно оставаться в рамках C++17, потому что на платформе заказчика C++20 нет.
S>>>> Из-за чего откат на предыдущий стандарт либо невозможен, либо слишком дорог. CC>>>А зачем вообще этот откат? S>>Именно откат -- это форс-мажор, означающий что кто-то где-то сильно облажался. CC>Облажался как именно? И кто?
Тот, кто принимал решение о выборе стандарта. Техлид или архитектор, тут от организации работ зависит. Если речь о библиотеках типа Qt или Connext DDS, то здесь еще и вина маркетологов могла быть.
S>>в определенном классе ПО CC>Ну вот начинаем подбираться к тому, что подобные навороты могут пригодиться в очень узком зоопарке.
Поэтому я сразу и сказал "отучаемся говорить за всех". Сей зоопарк имеет место быть.
CC>Я пишу системный код под линейку довольно таки разных девайсов и то давно уже есть поддержка С++20 на них всех.
Повезло.
CC>Никто не берёт под проект альфу наиновейшего компилятора, все пользуют тот, который уже проверен. И там нет никакого смысла занижать версию стандарта.
Здравствуйте, night beast, Вы писали:
S>>Не обязательно. Сходу вспоминается std::aligned_storage, введенный в C++11 и помеченный к удалению в C++23.
NB>не совсем понял, что предлагается вместо него?
Здравствуйте, so5team, Вы писали:
NB>>не совсем понял, что предлагается вместо него?
S>Сам пропозал: https://wg21.link/p1413 S>В кратком виде описано здесь: https://stackoverflow.com/a/71828512 (тут же и краткие примеры как следует делать).
да, читал. просто удивился что они реально предлагают заменить тип, скрывающий детали, на:
Здравствуйте, night beast, Вы писали:
S>>Сам пропозал: https://wg21.link/p1413 S>>В кратком виде описано здесь: https://stackoverflow.com/a/71828512 (тут же и краткие примеры как следует делать).
NB>да, читал. просто удивился что они реально предлагают заменить тип, скрывающий детали, на: NB>
NB>alignas(T) std::byte t_buff[sizeof(T)];
NB>
Видимо, слишком уж часто народ ошибался при использовании std::aligned_storage. Иначе мне самому логику принятия такого решения сложно найти.
Здравствуйте, so5team, Вы писали:
S>Так-то стандартная библиотека -- это часть языка.
Всё, что можно написать на этом же языке — не часть языка.
S> Например, std::forward и std::move -- реализованы в виде библиотечных функций, но это часть языка
Прикинь, я std не пользуюсь вообще и при этом move semantics использую очень активно. Как же так?
S>Точно так же, std::less, будучи библиотечным классом, позволяет безопасно делать то, что на "голом" языке делать не следует (сравнивать указатели между собой).
А то, что делает std::less можно делать только через std либу или как то ещё можно? Вопрос с подвохом.
S>В C++17 окончательно выпилили std::auto_ptr
Это библиотечная хрень, впрочем совершенно ничего не мешает тебе продолжать использовать тот же самый код std::auto_ptr даже в С++20.
S> и триграфы.
Это скорее препроцессор чем компилятор.
S>вот без std::auto_ptr старый код новыми компиляторами в 17-ом стандарте уже не собирается.
А если подумать? Это всего то небольшой темплейтный класс, неужто ну никак нельзя?
S>потому что на платформе заказчика C++20 нет.
И стало это известно только на этапе сдачи проекта? Как уже говорилось — тогда у этого проекта проблемы посерьёзнее.
S>Тот, кто принимал решение о выборе стандарта. Техлид или архитектор, тут от организации работ зависит.
Как уже говорилось — тогда у этого проекта проблемы посерьёзнее.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
S>> Например, std::forward и std::move -- реализованы в виде библиотечных функций, но это часть языка CC>Прикинь, я std не пользуюсь вообще и при этом move semantics использую очень активно. Как же так?
Может закатываете Солнце вручную?
CC>А то, что делает std::less можно делать только через std либу или как то ещё можно? Вопрос с подвохом.
У вас и C++20 уже полностью доступен, может вы уверены и в том, что uintptr_t вам всегда доступен.
S>>В C++17 окончательно выпилили std::auto_ptr CC>Это библиотечная хрень, впрочем совершенно ничего не мешает тебе продолжать использовать тот же самый код std::auto_ptr даже в С++20.
Ничего кроме компилятора и его стандартной либы.
S>>вот без std::auto_ptr старый код новыми компиляторами в 17-ом стандарте уже не собирается. CC>А если подумать?
Сами-то пробовали. Ну подумать-то?
А то я редко сталкиваюсь с людьми, которые и думают, и настолько уверены в своей правоте.
CC>Это всего то небольшой темплейтный класс, неужто ну никак нельзя?
Без переписывания?
S>>потому что на платформе заказчика C++20 нет. CC>И стало это известно только на этапе сдачи проекта?
Нет. Обычно это бывает так: у компании есть полукоробочный продукт, который кастомизируется под заказчика. Приходит новый заказчик, продукт нужно подгонять под него.
Здравствуйте, so5team, Вы писали:
S>Может закатываете Солнце вручную?
В смысле писать каст руками каждый раз? Нет есессна.
Но подобные примитивы совершенно не обязательно пользовать реализацию именно из std.
S>У вас и C++20 уже полностью доступен
Не знаю полностью ли, не проверял. Мне не то чтобы сильно много новых фич на практике нужны из последних стандартов.
S>может вы уверены и в том, что uintptr_t вам всегда доступен.
Мне ВСЕГДА доступно то, что имеется в используемом под проект платформенном framework. Так что мне совершенно всё равно что там во вспомогательных либах поменялось, я не использую из std совершенно ничего, но всё равно имею всё что мне там было нужно. Что забавно — оно ещё и работает быстрее std реализаций.
Если комитет решит что нить ещё задепрекейтить или поменять поведение существующего, то на мне это не отразится совершенно никак. Сюрпризов не будет.
CC>>Это библиотечная хрень, впрочем совершенно ничего не мешает тебе продолжать использовать тот же самый код std::auto_ptr даже в С++20. S>Ничего кроме компилятора и его стандартной либы.
Ты хочешь сказать что более новый компилятор не соберёт имплементацию std::auto_ptr?
Стандартная либа же пофигу, она не обязательна к использованию, более того никакой магии в ней самой нет да и сама часто бывает написана местами очень не очень, не по криворукости (впрочем и такое бывало) а просто потому что задача стояла сделать всемогутер на все случаи жизни, что неминуемо ведёт к компромиссам и работает оно в итоге везде одинаково плохо.
S>А то я редко сталкиваюсь с людьми, которые и думают, и настолько уверены в своей правоте.
Да потому что на практике делаю то, про что рассказываю.
CC>>Это всего то небольшой темплейтный класс, неужто ну никак нельзя? S>Без переписывания?
Переписывания чего?
S>Нет. Обычно это бывает так: у компании есть полукоробочный продукт, который кастомизируется под заказчика. Приходит новый заказчик, продукт нужно подгонять под него.
И поэтому надо заранее пессимизировать ВЕСЬ код под ну очень уж гипотетический случай прихода волосатого caveman из пещеры, который к тому же принесёт с собой ну столько бабла, что ну никак нельзя будет сказать ему что его компилятор давно устарел.
Соболезную работающим в таком грустном месте.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
S>>Может закатываете Солнце вручную? CC>В смысле писать каст руками каждый раз? Нет есессна. CC>Но подобные примитивы совершенно не обязательно пользовать реализацию именно из std.
Если вы вынуждены повторять руками то, что уже сделано в std, то это и есть закат вручную.
S>>может вы уверены и в том, что uintptr_t вам всегда доступен. CC>Мне ВСЕГДА доступно то, что имеется в используемом под проект платформенном framework.
Это прекрасно. Но это не значит, что это во всех проектах так.
CC>>>Это библиотечная хрень, впрочем совершенно ничего не мешает тебе продолжать использовать тот же самый код std::auto_ptr даже в С++20. S>>Ничего кроме компилятора и его стандартной либы. CC>Ты хочешь сказать что более новый компилятор не соберёт имплементацию std::auto_ptr?
Именно std::auto_ptr? Именно внутри std::?
Собрать-то он может и соберет, но это будет такое жирное UB, собственноручно вставленное в код, что жирнее некуда.
S>>А то я редко сталкиваюсь с людьми, которые и думают, и настолько уверены в своей правоте. CC>Да потому что на практике делаю то, про что рассказываю.
Т.е. эту фразу: "Потому нет никакой нужды ставить для нового проекта что либо ниже чем текущий стандарт" следует относить только к тем проектам, над которыми вы лично работаете?
CC>>>Это всего то небольшой темплейтный класс, неужто ну никак нельзя? S>>Без переписывания? CC>Переписывания чего?
Кода, в котором std::auto_ptr используется. Грубо говоря, 20 лет назад был написан код, который до сих пор нормально работал в рамках C++98/03 стандартов. В 2023-ем захотели обновиться до C++17 или C++20.
S>>Нет. Обычно это бывает так: у компании есть полукоробочный продукт, который кастомизируется под заказчика. Приходит новый заказчик, продукт нужно подгонять под него. CC>И поэтому надо заранее пессимизировать ВЕСЬ код под ну очень уж гипотетический случай прихода волосатого caveman из пещеры, который к тому же принесёт с собой ну столько бабла, что ну никак нельзя будет сказать ему что его компилятор давно устарел.
Например, компании готовы платить за Red Hat Enterprise Linux с 10 летней поддержкой и считают, что это оправдано. У таких компаний есть деньги и не вижу смысла от этих денег отказываться из-за желания всегда использовать только самый свежий стандар.
Здравствуйте, so5team, Вы писали:
S>Если вы вынуждены повторять руками то, что уже сделано в std, то это и есть закат вручную.
А ничо что каждый компилятор по сути повторяет это точно так же? С разным результатом, но как правило хуже.
И да, это ж всё уже давно и написано и оттестировано.
S>Это прекрасно. Но это не значит, что это во всех проектах так.
На хреновых есессна не так.
S>Именно std::auto_ptr? Именно внутри std::?
Что мещает его скопировать из предыдущей версии?
S>Собрать-то он может и соберет, но это будет такое жирное UB, собственноручно вставленное в код, что жирнее некуда.
В чём именно UB? Его ж убрали не потому что был сломан а потому что придумали лучший вариант а этот решили просто убрать.
S>Например, компании готовы платить за Red Hat Enterprise Linux с 10 летней поддержкой и считают, что это оправдано.
И каким боком там стандарт С++?
Платят там совсем не за это.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
S>>Это прекрасно. Но это не значит, что это во всех проектах так. CC>На хреновых есессна не так.
Понятно. Но мне бы хотелось увидеть ответ вот на этот вопрос:
> Т.е. эту фразу: "Потому нет никакой нужды ставить для нового проекта что либо ниже чем текущий стандарт" следует относить только к тем проектам, над которыми вы лично работаете?
S>>Именно std::auto_ptr? Именно внутри std::? CC>Что мещает его скопировать из предыдущей версии? CC>В чём именно UB? Его ж убрали не потому что был сломан а потому что придумали лучший вариант а этот решили просто убрать.
ЕМНИП, в пространство имен std можно добавлять только специализации std-шных классов для типов пользователей. Т.е., специализацию условного std::less для vasiya::pupkin::long_integer в std поместить можно. Какой-то новый класс/функцию/оператор/перегрузку -- нет.
S>>Например, компании готовы платить за Red Hat Enterprise Linux с 10 летней поддержкой и считают, что это оправдано. CC>И каким боком там стандарт С++?
Там будет конкретная версия gcc с каким-то стандартом C++, далеко не самым свежим.
И да, поставить на этот Linux более свежий gcc (clang, intel или еще что-то) может быть невозможно по организационным/политическим причинам.
Здравствуйте, so5team, Вы писали:
S>Понятно. Но мне бы хотелось увидеть ответ вот на этот вопрос: >> Т.е. эту фразу: "Потому нет никакой нужды ставить для нового проекта что либо ниже чем текущий стандарт" следует относить только к тем проектам, над которыми вы лично работаете?
Вопрос довольно размытый. Если надо краткий да/нет ответ то нет, не только.
Разжёвывать это всё ещё раз мне лень.
S>ЕМНИП, в пространство имен std можно добавлять только специализации std-шных классов для типов пользователей. S> Т.е., специализацию условного std::less для vasiya::pupkin::long_integer в std поместить можно. Какой-то новый класс/функцию/оператор/перегрузку -- нет.
Это не запрет, это скорее соглашение, примерно как резервация "__" префикса для платформенных нужд.
В реальности же ничего не мешает да хоть всё там своим заменить.
S>И да, поставить на этот Linux более свежий gcc (clang, intel или еще что-то) может быть невозможно по организационным/политическим причинам.
Это аналог "а вдруг надо будет чтоб работало на WinXP 32bit"
За допиливание чтоб работало на древнем хламе принято брать весьма серьёзные деньги.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Разжёвывать это всё ещё раз мне лень.
Вы так говорите как будто уже объясняли один раз (на самом деле нет).
S>>И да, поставить на этот Linux более свежий gcc (clang, intel или еще что-то) может быть невозможно по организационным/политическим причинам. CC>Это аналог "а вдруг надо будет чтоб работало на WinXP 32bit"
Здравствуйте, CreatorCray, Вы писали:
CC>Мне ВСЕГДА доступно то, что имеется в используемом под проект платформенном framework. Так что мне совершенно всё равно что там во вспомогательных либах поменялось,
Т.е. твой опыт внутрикорпоративных велосипедов за переделами компании нерелевантен. Все равно как MFC -й CString, только хуже.
Здравствуйте, Артём, Вы писали:
Аё>Т.е. твой опыт внутрикорпоративных велосипедов за переделами компании нерелевантен. Все равно как MFC -й CString, только хуже.
Видел я как то похожий проект, где не то что std, даже rtl свой был. Проталкивали это не в силу каких то супертребований, а под тем же соусом что и СС.
Начальство, однако, что то стало подозревать. Сперва когда новые люди в проекте не могли более полугода начать приносить пользу. Потом когда мелкие фичи стали реализовываться долго и больно. Последней каплей было когда какую то фичу временно заказали аутсорсерам на какой то богомерзкой платформе типа Java, и они ее выкатили месяца за три, а плюсовые гении свой вариант пилили полтора года, а результат оказался не просто хуже аутсорсеного по качеству, но даже не достиг приемлемого по требованиям уровня распознавания.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Сперва когда новые люди в проекте не могли более полугода начать приносить пользу.
А пробовали нанимать таки инженеров а не студней с курсом жаба за три дня?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
НС>>Сперва когда новые люди в проекте не могли более полугода начать приносить пользу. CC>А пробовали нанимать таки инженеров а не студней с курсом жаба за три дня?
В той команде джунов и миддлов не было совсем. Просто код за десятилетия эволюции и переписывания всего что можно в силу NIH-синдрома превратился в нечто. Домножаем все это на крайне сложную предметную область и получаем что получаем.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Просто код за десятилетия эволюции и переписывания всего что можно в силу NIH-синдрома превратился в нечто.
А там даже попыток не делалось как-то переиспользовать готовые вещи из внешнего мира (хоть из C++ной stdlib, хоть из Boost, хоть из ACE/POCO и т.д.)?
Здравствуйте, so5team, Вы писали:
S>А там даже попыток не делалось как-то переиспользовать готовые вещи из внешнего мира (хоть из C++ной stdlib, хоть из Boost, хоть из ACE/POCO и т.д.)?
Нет. Проект начался в 90-х, и на тот момент им в основном продолжали рулить те люди, которые его начинали. А когда ты 15-20 лет только один проект делаешь, то у тебя восприятие технологий становится несколько biased, изначальные установки превращаются в идеологемы (мол если проект успешный, то строго все принятые решения были на 100% правильными). И надо очень большое мужество чтобы в этот момент отбросить все накопленное и непредвзято посмотреть вокруг.
Собственно, и тут на форуме постоянно это все наблюдается, пусть и не в такой запущенной форме.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Видел я как то похожий проект, где не то что std, даже rtl свой был НС>>>Сперва когда новые люди в проекте не могли более полугода начать приносить пользу. НС>Просто код за десятилетия эволюции и переписывания всего что можно в силу NIH-синдрома превратился в нечто.
Но считаешь ты что это всё только потому, что они вместо std::map пишут ourfw::map?
Когда сам проект превращается в копролит совсем не важно какой std/rtl был использован — там совсем не в консерватории проблемы.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
S>А там даже попыток не делалось как-то переиспользовать готовые вещи из внешнего мира (хоть из C++ной stdlib, хоть из Boost, хоть из ACE/POCO и т.д.)?
В одной из компаний где я работал буст и вовсе попал под запрет, после того как их очередное обновление сломало нам столько, что оказалось что проще написать своё, проще и менее универсальное, чем починить тот пц что они наворотили.
В результате мало того что стало работать как надо так ещё и неслабый прирост скорости что работы что компиляции получили.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>И надо очень большое мужество чтобы в этот момент отбросить все накопленное и непредвзято посмотреть вокруг.
А также очень много свободного времени, чтоб чинить ещё и чужой код.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
НС>>И надо очень большое мужество чтобы в этот момент отбросить все накопленное и непредвзято посмотреть вокруг. CC>А также очень много свободного времени, чтоб чинить ещё и чужой код.
Здравствуйте, CreatorCray, Вы писали:
CC>Когда сам проект превращается в копролит совсем не важно какой std/rtl был использован
Или важно.
CC> — там совсем не в консерватории проблемы.
А в чем? Ели захочешь мне рассказать, что там тупые программисты были — не стоит, там в определенном аспекте очень крутая команда, я бы сказал уникальная и лучшая в мире. Но вот недоверие к вообще любому стороннему коду все испортило.
Здравствуйте, CreatorCray, Вы писали:
S>>А там даже попыток не делалось как-то переиспользовать готовые вещи из внешнего мира (хоть из C++ной stdlib, хоть из Boost, хоть из ACE/POCO и т.д.)?
CC>В одной из компаний где я работал буст и вовсе попал под запрет, после того как их очередное обновление сломало нам столько, что оказалось что проще написать своё, проще и менее универсальное, чем починить тот пц что они наворотили. CC>В результате мало того что стало работать как надо так ещё и неслабый прирост скорости что работы что компиляции получили.
Boost -- это вообще отдельная тема для разговора, т.к. он и слишком большой (хотя через vcpkg его можно использовать и помодульно, но vcpkg не так уж и давно получился), и какие-то вещи там были порождены ну совсем уж сумрачным гением.
Однако, если в старом проекте в 90-х было написано вообще чуть ли не все свое, то со временем какие-то части можно было заменить на что-то стороннее. Скажем, в 90-е чуть ли не каждый второй был вынужден писать свои смарт-поинтеры. С появлением в начале нулевых Boost-а эти самые смарт-поинтеры можно был из Boost-а скомуниздить.
Собственно, если люди не занимаются совсем уж узкой темой (хард рил-тайм, к примеру, или замороченный HPC), то больше 20 лет все делать только и исключительно на собственных велосипедах... Ну для этого нужны очень уж веские основания.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это время более чем окупается, не переживай.
Не, не окупается. Плавали, знаем.
Куда быстрее и безбажнее получается написать аналог, в котором будет только то, что надо. Даже не обязательно с нуля, можно тупо форкнуть и выпилить оттуда весь мусор.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ночной Смотрящий, Вы писали:
CC>>Когда сам проект превращается в копролит совсем не важно какой std/rtl был использован НС>Или важно.
На фоне уже гигантского копролита — не важно.
НС>там в определенном аспекте очень крутая команда
Очень даже может быть что этот определённый аспект у них получался хорошо, но всё что они сделали руками...
НС>Но вот недоверие к вообще любому стороннему коду все испортило.
А с чего ты взял что причиной было именно недоверие к стороннему коду а не то, что проект тупо перерос свой изначальный дизайн и стал обваливаться под собственным весом, как очень часто бывает со старыми проектами.
Когда у тебя небоскрёб построен так же как привыкли строить сарай и потому вот вот обвалится — не сильно важно какого цвета были гвозди.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
S>Boost -- это вообще отдельная тема для разговора, т.к. он и слишком большой (хотя через vcpkg его можно использовать и помодульно, но vcpkg не так уж и давно получился), и какие-то вещи там были порождены ну совсем уж сумрачным гением.
Там суровая жесть местами.
S>Однако, если в старом проекте в 90-х было написано вообще чуть ли не все свое, то со временем какие-то части можно было заменить на что-то стороннее.
Или переписать на те же мотивы.
S>С появлением в начале нулевых Boost-а эти самые смарт-поинтеры можно был из Boost-а скомуниздить.
Мы тогда ещё поначалу скомуниздили, поплевались, выкинули, написали свои похожие, только поудобнее.
S> Ну для этого нужны очень уж веские основания.
Они работают, этого достаточно.
Скорее надо веские основания менять на что то стороннее, что хз как поддерживать и обслуживать.
Буст нам несколько раз сломал всю посевную из за багов, которые в их темплейтном маразме хрен поймаешь и починишь. А в обновлении они починили одно и наглухо сломали другое.
После чего буст и был отправлен на помоечку и написаны свои аналоги. На порядки проще и куда менее темплейтно.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
НС>>там в определенном аспекте очень крутая команда CC>Очень даже может быть что этот определённый аспект у них получался хорошо, но всё что они сделали руками...
Ну понятно. Лишь у тебя код идеальный, я верно понял?
НС>>Но вот недоверие к вообще любому стороннему коду все испортило. CC>А с чего ты взял что причиной было именно недоверие к стороннему коду
Наверное потому что они сами мне об этом сказали?
CC> а не то, что проект тупо перерос свой изначальный дизайн и стал обваливаться под собственным весом, как очень часто бывает со старыми проектами.
Есть такое понятие как рефакторинг. Он помогает в такой ситуации.
Но вот тут то мы и попадаем в засаду (даже если оставить за скобками крайнюю недружелюбность к сему действию плюсов) — чем больше ты переписываешь стандартного кода, тем больше кода в проекте , и тем дороже и болезненнее рефакторинг.
Здравствуйте, CreatorCray, Вы писали:
S>>С появлением в начале нулевых Boost-а эти самые смарт-поинтеры можно был из Boost-а скомуниздить. CC>Мы тогда ещё поначалу скомуниздили, поплевались, выкинули, написали свои похожие, только поудобнее.
Да, тоже вариант. В любом случае, можно подсмотреть как сделано у других.
S>> Ну для этого нужны очень уж веские основания. CC>Они работают, этого достаточно.
Разве что если коллектив не расширяется и остается стабильным. Но вот когда в проект заходят новые люди, то им нужно как-то осваивать местные велосипеды. И, как мне представляется, самодельные лисапеды в подавляющем большинстве случаев задокументированы чуть-чуть лучше, чем никак.
Для того же Boost-а (ACE, POCO и т.д.) хоть какая-то документация есть, вопросы-ответы в интернете и т.д.
По своим же велосипедам только код этих самых велосипедов, хорошо если с комментариями. Хотя и встречаются редкие исключения.
Здравствуйте, Patalog, Вы писали:
P>Здравствуйте, vaa, Вы писали:
P>[]
vaa>>Ocaml is slower than C but faster than C++. P>Всегда удивляли долб.диб.странные люди, пишущие что С++ медленнее С,
У него с Фортраном ничего общего. 
Без рук что ли?
