Встречалась ли вам концепция — "C++ как C с классами". Т.е. когда правила кодирования устанавливают запрет на множество фич, которые есть в языке, но которые часто запутывают код и делают сложным для восприятия — сводят фактически к C, но с удобным синтаксисом для RAII. Однако же указатели и пр. — используются все как в C.
Причем на C успешно пишут все что угодно — то какие проблемы делать то же самое, добавив в C — удобный RAII в мин. варианте?
B здесь главное не поддаться греху гордыни — когда тебе хочется доказать другим что ты способен, что SFINAE и 4-х этажные шаблоны тебе по плечу. А нужно не поддаваться греху гордыни а наоборот проявить смирение и кротость — аскетизм. Ограничить себя в излишествах и довольствоваться простым минимализмом.
В принципе — я всецело поддерживаю и уважаю эту концепцию C++. Чем проще код — тем лучше. Кто хочешь поддаться греху гордыни — есть вам Haskell — пожалуйста.
Но! С появлением умных указателей стала возможна другая концепция — C++ может быть аналогом ЯВУ типа C#|Java. В чем суть? Суть в том, чтобы в угоду простоте кодирования и отладки — отказаться от ряда фич языка, запретить их использование. А именно:
1. Отказ от сырых указателей, буквальный запрет их в коде. Замена — умные указатели, ссылки, std::optional, std::optional<std::reference_wrapper<>>.
2. Отказ от сложных шаблонов, вариадических, SFINAE, запрет концептов. Т.е. свести к уровню шаблонов в Java/C#.
3. Отказ от макросов.
4. Запрет множественного наследования реализаций.
5. И т.д. (это примерный список, на самом деле гораздо больше).
Вы скажите — в чем тогда смысл, не лучше ли писать сразу на Java? А смысл чисто практический — по факту С++ наиболее кросс-платформенный и наименее гемморный на сегодня. Дошло до того, что C# компиллят в C++. Здесь не вопрос холивара — просто по факту так оно и есть.
Встречали ли вы такую концепция кодирования? Одобряете?
C++ разный. Пишешь библиотеку — тут можно и десятиэтажные шаблоны делать, главное — максимально всё предусмотреть, документировать , и чтобы она была максимально проста в использовании.
Пишешь прикладной код — тут можно и по простому.
S>Вопрос такой. S>Встречали ли вы такую концепция кодирования? Одобряете?
Какую? Я из твоей портянки так и не понял, что за концепция. Я пишу максимально кондово и понятно для всех
Здравствуйте, Marty, Вы писали:
M>C++ разный. Пишешь библиотеку — тут можно и десятиэтажные шаблоны делать, главное — максимально всё предусмотреть, документировать , и чтобы она была максимально проста в использовании.
Это если библиотеку гарантированно никто другой не будет править.
M>Пишешь прикладной код — тут можно и по простому.
А обоснование какое?
M>Какую? Я из твоей портянки так и не понял, что за концепция. Я пишу максимально кондово и понятно для всех
Учись пока я жив. Берешь простыню текста и вводишь в GPT, потом задаешь свой вопрос. Учись, я сделал это для тебя:
Автор описывает две концепции упрощённого C++:
1. «C++ как C с классами» — минимализм, RAII, отказ от сложностей языка.
2. «C++ как Java/C#» — управление через умные указатели, без сырых указателей и сложных шаблонов.
С появлением GPT теперь мы юридически точно можем сказать кто дурак — пишущий или читающий. Так что теперь как раньше не прокатывает, уже нельзя обвинить оппонента без оснований — ранее можно было, т.к. критерия точного не было, теперь есть.
Здравствуйте, Shmj, Вы писали:
S>В принципе — я всецело поддерживаю и уважаю эту концепцию C++. Чем проще код — тем лучше. Кто хочешь поддаться греху гордыни — есть вам Haskell — пожалуйста.
Haskell основан на трёх с половиной идеях, которые там повсеместно используются единообразным образом. А C++ — это такая сборная солянка из всех идей, которые когда-либо отсветились на протяжении всей истории computer science.
Haskell проще, чем C++, на два порядка.
S>Вы скажите — в чем тогда смысл, не лучше ли писать сразу на Java? А смысл чисто практический — по факту С++ наиболее кросс-платформенный и наименее гемморный на сегодня. Дошло до того, что C# компиллят в C++. Здесь не вопрос холивара — просто по факту так оно и есть.
Нихрена он не кросс-платформенный. Даже в разные дистрибутивы линуха целиться с помощью C++ проблематично: непонятно, на какие библиотеки можно рассчитывать. А таскать это с собой — кросс-платформенность немедленно превращается в лютый геморрой, когда даже сборку программы отстроить становится весьма непростой проблемой.
Вот Go, да, он кросс-платформенный. Rust подозреваю, что тоже.
Здравствуйте, Pzz, Вы писали:
Pzz>Haskell основан на трёх с половиной идеях, которые там повсеместно используются единообразным образом.
Зато каких идеях...
Pzz>Нихрена он не кросс-платформенный. Даже в разные дистрибутивы линуха целиться с помощью C++ проблематично: непонятно, на какие библиотеки можно рассчитывать.
А причем тут библиотеки? Библиотеки и системные функции — это отдельный вопрос — главное что ваши программы будут 100% компилировать под все платформы.
Pzz>А таскать это с собой — кросс-платформенность немедленно превращается в лютый геморрой, когда даже сборку программы отстроить становится весьма непростой проблемой.
Кросс-платформа — всегда не просто и не дешево, но на практике на C++ это проще всего получается.
На C++ есть уже готовые кросс-платформенные либы, которые реально работают.
Pzz>Вот Go, да, он кросс-платформенный. Rust подозреваю, что тоже.
Go — это сборщик мусора, тащить за собой всю среду не оно. Как и .Net.
Rust не имеет полноценного ООП — это скорее замена голого C и то спорная.
Здравствуйте, Shmj, Вы писали:
M>>Какую? Я из твоей портянки так и не понял, что за концепция. Я пишу максимально кондово и понятно для всех
S>Учись пока я жив. Берешь простыню текста и вводишь в GPT, потом задаешь свой вопрос. Учись, я сделал это для тебя:
говорят, люди иногда читают, а иногда пишут. Вот бредописатель из тебя — отличный, умеющий сформулировать без всяких gpt мысль — тут все плохо.
Здравствуйте, Shmj, Вы писали:
S>Встречали ли вы такую концепция кодирования? Одобряете?
У С++ другие немного приоритеты, как будто схожие с тем, что ты описываешь, но в другую степь, называются профили.
Это связано не с удобством пользователей, а с безопасностью.
Здравствуйте, Shmj, Вы писали:
S>1. Отказ от сырых указателей, буквальный запрет их в коде. Замена — умные указатели, ссылки, std::optional, std::optional<std::reference_wrapper<>>. S>2. Отказ от сложных шаблонов, вариадических, SFINAE, запрет концептов. Т.е. свести к уровню шаблонов в Java/C#.
Ну да, ну да...
S>3. Отказ от макросов.
макросы это фишка C, а не C++, отказываться от фишек C в пользу C++ это какой-то неумный C
S>4. Запрет множественного наследования реализаций.
Ещё большее урезание. Тогда лучше использовать умный C#
Здравствуйте, Shmj, Вы писали:
S>B здесь главное не поддаться греху гордыни — когда тебе хочется доказать другим что ты способен, что SFINAE и 4-х этажные шаблоны тебе по плечу. А нужно не поддаваться греху гордыни а наоборот проявить смирение и кротость — аскетизм. Ограничить себя в излишествах и довольствоваться простым минимализмом. S>
Ну вот я всегда пишу аскетичный код. И вообще стараюсь не использовать ничего кроме циклов, условий и подпрограмм.
И только когда этого не хватает, применяю что-нибудь другое.
Начинаю с макросов. Потом функции высшего порядка (как qsort), и только потом всё остальное.
Здравствуйте, Maniacal, Вы писали:
S>>3. Отказ от макросов. M>макросы это фишка C, а не C++, отказываться от фишек C в пользу C++ это какой-то неумный C
Ох ё... Это вторая концепция же — в первой, где С с классами — макросы разрешены.
S>>4. Запрет множественного наследования реализаций. M>Ещё большее урезание. Тогда лучше использовать умный C#
C# просто тупо физически не позволяет писать кросс-платформенные библиотеки (под все 6 платформ человечества), пригодные для реального использования из других языков через FFI. Покажите мне хотя бы одну такую библиотеку.
Здравствуйте, Shmj, Вы писали:
Pzz>>Нихрена он не кросс-платформенный. Даже в разные дистрибутивы линуха целиться с помощью C++ проблематично: непонятно, на какие библиотеки можно рассчитывать.
S>А причем тут библиотеки? Библиотеки и системные функции — это отдельный вопрос — главное что ваши программы будут 100% компилировать под все платформы.
Потому, что возможность программировать кросс-платформенно, но без библиотек, имеет исключительно акедемическую ценность.
Pzz>>А таскать это с собой — кросс-платформенность немедленно превращается в лютый геморрой, когда даже сборку программы отстроить становится весьма непростой проблемой.
S>Кросс-платформа — всегда не просто и не дешево, но на практике на C++ это проще всего получается.
Я в курсе.
S>На C++ есть уже готовые кросс-платформенные либы, которые реально работают.
Pzz>>Вот Go, да, он кросс-платформенный. Rust подозреваю, что тоже.
S>Go — это сборщик мусора, тащить за собой всю среду не оно. Как и .Net.
.Net ташит за собой рантайм в виде кучи файлов. Go просто линкует программу статически.
S>Rust не имеет полноценного ООП — это скорее замена голого C и то спорная.
Здравствуйте, Pzz, Вы писали:
Pzz>Потому, что возможность программировать кросс-платформенно, но без библиотек, имеет исключительно акедемическую ценность.
Уже есть ряд библиотек, которые так же придерживаются концепции кросс-платформы.
Pzz>.Net ташит за собой рантайм в виде кучи файлов. Go просто линкует программу статически.
Вроде для WASM — пустое приложение уже получается слишком большим.
На iOS — плохая поддержка.
На C++ QT можно писать полноценное приложение для iOS — на Go не возможно даже за миллиард долларов.
S>>Rust не имеет полноценного ООП — это скорее замена голого C и то спорная. Pzz>И что?
ООП не смотря на популярные статьи крикунов — это основа разработки ПО.
Здравствуйте, Shmj, Вы писали:
S>B здесь главное не поддаться греху гордыни — когда тебе хочется доказать другим что ты способен, что SFINAE и 4-х этажные шаблоны тебе по плечу. А нужно не поддаваться греху гордыни а наоборот проявить смирение и кротость — аскетизм. Ограничить себя в излишествах и довольствоваться простым минимализмом. S>
, но ты, как обычно, предпочёл "не заметить" неудобную информацию.
Что ж, повторюсь. Нормальные программисты используют шаблоны и SFINAE совсем не для того, чтобы кому-то что-то доказать, а для того, чтобы решать какие-то задачи. Отказ от использования перечисленного — это просто отказ от решения задач. А сложный и запутанный код, как правило, получается у новичков, которые только начинают осваивать этот подход. У опытных программистов даже со SFINAE код получается понятным и читабельным, вот тебе свежий пример:
const char* rawConstCharPtrFromIterator(Pointer auto p)
{
return reinterpret_cast<const char*>(p);
}
const char* rawConstCharPtrFromIterator(Dereferenceable auto it)
{
return reinterpret_cast<const char*>(&*it);
}
Но главное, чего ты не соображаешь — это то, что некоторая сложность при реализации шаблонных сущностей — это всего лишь скромная плата за то упрощение, которое они дают в точках использования, число которых несоизмеримо больше, чем код самих шаблонов:
Такие как ты предпочитают размазать говно по всему коду, вместо того, чтобы в одном месте написать пару несложных шаблончиков. И это вовсе не по каким-то "концептуальным" соображениям, а просто потому, что вам это недоступно, вот и всё.
А конкретно ты — просто неуч и лентяй. Вместо того, чтобы учиться и осваивать язык, ты ищешь способы, как программировать, не приходя в сознание.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, Shmj, Вы писали:
M>>C++ разный. Пишешь библиотеку — тут можно и десятиэтажные шаблоны делать, главное — максимально всё предусмотреть, документировать , и чтобы она была максимально проста в использовании.
S>Это если библиотеку гарантированно никто другой не будет править.
Уровень библиотеко-писателей должен быть примерно одинаков, школоту конечно нельзя подпускать
M>>Пишешь прикладной код — тут можно и по простому.
S>А обоснование какое?
Прикладной код может и школота потом править
M>>Какую? Я из твоей портянки так и не понял, что за концепция. Я пишу максимально кондово и понятно для всех
S>Учись пока я жив. Берешь простыню текста и вводишь в GPT, потом задаешь свой вопрос. Учись, я сделал это для тебя:
S>
S>Автор описывает две концепции упрощённого C++:
S>1. «C++ как C с классами» — минимализм, RAII, отказ от сложностей языка.
S>2. «C++ как Java/C#» — управление через умные указатели, без сырых указателей и сложных шаблонов.
Правда, обеспечение RAII уже требует сложностей языка.
Правда, умные указатели (у это не разве не тоже RAII?) требуют сложностей языка.
S>С появлением GPT теперь мы юридически точно можем сказать кто дурак — пишущий или читающий. Так что теперь как раньше не прокатывает, уже нельзя обвинить оппонента без оснований — ранее можно было, т.к. критерия точного не было, теперь есть.
Не можем. безусловно, никакая AI-гопота не может быть арбитром
Здравствуйте, Marty, Вы писали:
M>Пишешь библиотеку — тут можно и десятиэтажные шаблоны делать, главное — максимально всё предусмотреть, документировать , и чтобы она была максимально проста в использовании.
Если использование библиотеки предполагает включение заголовка с этими "десятиэтажными шаблонами" в клиентский код, она никак не может быть "максимально проста в использовании". Чисто технически.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Если использование библиотеки предполагает включение заголовка с этими "десятиэтажными шаблонами" в клиентский код, она никак не может быть "максимально проста в использовании". Чисто технически.
Угу. А Земля имеет форму чемодана. Потому что тебе так хочется.
Подключать-то по-разному можно. Если подключаешь только то, что нужно и только туда, где это нужно, то и проблем никаких у тебя не будет. Если же ты бездумно пхнешь все инклюды подряд в заголовки верхнего уровня, то, скорее всего, у тебя что-то с головой.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Пишешь библиотеку — тут можно и десятиэтажные шаблоны делать, главное — максимально всё предусмотреть, документировать , и чтобы она была максимально проста в использовании.
ЕМ>Если использование библиотеки предполагает включение заголовка с этими "десятиэтажными шаблонами" в клиентский код, она никак не может быть "максимально проста в использовании". Чисто технически.
std библиотеку ты же как-то используешь? А внутрь заглядывать пробовал?
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Драйвер на Java? Ты совсем дурачек чтоли?
ЕМ>Те, кто регулярно спрашивает в сообществах, как им написать драйвер на питоне, не считают себя дурачками.
Здравствуйте, Shmj, Вы писали:
S>C# просто тупо физически не позволяет писать кросс-платформенные библиотеки (под все 6 платформ человечества), пригодные для реального использования из других языков через FFI. Покажите мне хотя бы одну такую библиотеку.
Не понял, а где в списке шести платформ человечества хотя бы STM32?
Здравствуйте, alpha21264, Вы писали:
A>Ну вот я всегда пишу аскетичный код. И вообще стараюсь не использовать ничего кроме циклов, условий и подпрограмм. A>И только когда этого не хватает, применяю что-нибудь другое. A>Начинаю с макросов. Потом функции высшего порядка (как qsort), и только потом всё остальное.
И если ты это делаешь, не используя плюсовые возможности (а судя по слову макросы — это так и есть) — поздравляю тебя, Шарик, ты пишешь лютейшее говно
Здравствуйте, Евгений Музыченко, Вы писали:
S>>3. Отказ от макросов.
ЕМ>C++ слишком убог, чтобы это было возможно без серьезного урезания удобства работы с ним.
Здравствуйте, Shmj, Вы писали:
Pzz>>Потому, что возможность программировать кросс-платформенно, но без библиотек, имеет исключительно акедемическую ценность.
S>Уже есть ряд библиотек, которые так же придерживаются концепции кросс-платформы.
В экосистеме C++ нет ничего для работы с внешними библиотеками. Если ты их активно используешь, билд становится очень нетривиальной штукой.
Pzz>>.Net ташит за собой рантайм в виде кучи файлов. Go просто линкует программу статически.
S>Вроде для WASM — пустое приложение уже получается слишком большим.
Ну ОК. Поддержка этой уродской платформы обладает определенными недостатками.
S>На iOS — плохая поддержка.
Я слышал, на iOS трудно собрать кроссом — нужен нативный компилятор Си, а он работает только на маке. Заметим, это — искусственно созданные трудности, эпл хочет заставить всех разработчиков под эпл использовать их собственную платформу.
А что еще?
S>На C++ QT можно писать полноценное приложение для iOS — на Go не возможно даже за миллиард долларов.
Чего именно не хватает в Go?
S>>>Rust не имеет полноценного ООП — это скорее замена голого C и то спорная. Pzz>>И что?
S>ООП не смотря на популярные статьи крикунов — это основа разработки ПО.
Здравствуйте, Marty, Вы писали:
S>>C# просто тупо физически не позволяет писать кросс-платформенные библиотеки (под все 6 платформ человечества), пригодные для реального использования из других языков через FFI. Покажите мне хотя бы одну такую библиотеку.
M>Не понял, а где в списке шести платформ человечества хотя бы STM32?
Человечество в лице Шмыжи дочитало книжку про платформы только до первых 6-и, а дальше не осилило.
P.S. А разве STM32 — это не ARM такой, куда хочешь Ubuntu ставь, а не хочешь — Федору?
Здравствуйте, Pzz, Вы писали:
Pzz>Человечество в лице Шмыжи дочитало книжку про платформы только до первых 6-и, а дальше не осилило.
Pzz>P.S. А разве STM32 — это не ARM такой, куда хочешь Ubuntu ставь, а не хочешь — Федору?
Это арм, но не взрослый. Там нет memory management unit'а, например, вся память общая и только физическая. Не слышал, чтобы были сборки линупса под STM32. ПОд STM32 я слышал про FreeRTOS, ну это такая себе ОС — даёт многопоточность и примитивы синхронизации, что-то типа базового POSIX, и всё.
Здравствуйте, Shmj, Вы писали:
S>С появлением GPT теперь мы юридически точно можем сказать кто дурак — пишущий или читающий. Так что теперь как раньше не прокатывает, уже нельзя обвинить оппонента без оснований — ранее можно было, т.к. критерия точного не было, теперь есть.
Ну да. С появлением GPT занятие пустой графоманией сильно автоматизированно.
Здравствуйте, Marty, Вы писали:
Pzz>>P.S. А разве STM32 — это не ARM такой, куда хочешь Ubuntu ставь, а не хочешь — Федору?
M>Это арм, но не взрослый. Там нет memory management unit'а, например, вся память общая и только физическая. Не слышал, чтобы были сборки линупса под STM32. ПОд STM32 я слышал про FreeRTOS, ну это такая себе ОС — даёт многопоточность и примитивы синхронизации, что-то типа базового POSIX, и всё.
Есть линух для процессоров без MMU. Там, конечно, теряешь автоматическую изоляцию процессов друг от друга и всякие удобства, типа быстрого fork(). Но всё еще сохраняешь удобства в виде первокласного сетевого стека и файловых систем.
Здравствуйте, Pzz, Вы писали:
Pzz>Есть линух для процессоров без MMU. Там, конечно, теряешь автоматическую изоляцию процессов друг от друга и всякие удобства, типа быстрого fork(). Но всё еще сохраняешь удобства в виде первокласного сетевого стека и файловых систем.
Не понял, в 90% устройств на STM32 нет никакого Ethernet и диска. А где есть Ethernet, то у этого линупса скорее всего нет реализации дров для STM. Да и с диском (флешки SD) напрямую по SPI он наверняка не умеет работать.
Твой линупс без MMU влезет в мегабайт флеша, запустится на 128К оперативки?
Здравствуйте, Pzz, Вы писали:
M>>Твой линупс без MMU влезет в мегабайт флеша, запустится на 128К оперативки?
Pzz>В мегабайт вряд ли. В 8 я запихивал, да еще и с запасом.
Максимальная флешка на STM32 это вроде 2 метра, но это очень жирная STMка, средние в LQFP48/LQFP64 — это порядка пары сотен кил флеша и 32 кб оперативы, в младших вообще всего очень мало
Pzz>Но если нет ни сети ни файлов, то полноценная ОСь действительно не очень нужна.
Там ещё и частоты — у старших F4 максималка 180МГц, младшие на 48МГц и меньше работают.
Появилось ещё семейство H7 вроде, там чуть ли не до полугигагерца или даже выше, но я не уверен, что это ещё микроконтроллеры, и этих зверей в руках не держал
Здравствуйте, Евгений Музыченко, Вы писали:
_NN>>А что используется ?
ЕМ>Свою библиотеку базовых средств. У меня потребности скромные, я даже динамические строки лишь недавно добавил.
Покажи же нам эту прекрасную библиотеку, хоть кусочек, чтобы мы восхитились и поняли, что std — говно
Здравствуйте, Shmj, Вы писали:
S> Встречалась ли вам концепция — "C++ как C с классами". Т.е. когда правила кодирования устанавливают запрет на множество фич, которые есть в языке, но которые часто запутывают код и делают сложным для восприятия — сводят фактически к C, но с удобным синтаксисом для RAII. Однако же указатели и пр. — используются все как в C.
S> B здесь главное не поддаться греху гордыни — когда тебе хочется доказать другим что ты способен, что SFINAE и 4-х этажные шаблоны тебе по плечу. А нужно не поддаваться греху гордыни а наоборот проявить смирение и кротость — аскетизм. Ограничить себя в излишествах и довольствоваться простым минимализмом. S>
Здравствуйте, rg45, Вы писали:
R>У меня вопрос другой: ты нахрена опять профильный форум загаживаешь своей трепологией? Тебе КСВ мало?
Он будет делать это столько, сколько ему будут отвечать, даже если его говном поливать будут. Иногда складывается впечатление, что *особенно* если говном поливать будут.
Здравствуйте, serg_joker, Вы писали:
_>Он будет делать это столько, сколько ему будут отвечать, даже если его говном поливать будут. Иногда складывается впечатление, что *особенно* если говном поливать будут.
Да, я полностью с тобой согласен. Но не вестись на эти провокации у меня не получается почему-то.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, rg45, Вы писали:
_>>Он будет делать это столько, сколько ему будут отвечать, даже если его говном поливать будут. Иногда складывается впечатление, что *особенно* если говном поливать будут.
R>Да, я полностью с тобой согласен. Но не вестись на эти провокации у меня не получается почему-то.
Здравствуйте, Marty, Вы писали:
M>Что именно уродливого в реализации?
Те самые шаблонные трюки, о которых мы много говорили.
M>какая тебе, как пользователю, разница, что там под капотом?
Мне не нравится, когда при моих непреднамеренных ошибках все это говно вспучивает из-под капота, и мне приходится разглядывать многострочные, но маловразумительные тексты, чтобы догадаться, что же именно пошло не так.
Да, то же самое происходит и с моими шаблонами, но с ними я хоть могу увидеть в исходниках свои комментарии, вроде "сюда нельзя числовой литерал без квалификатора типа".
Когда (точнее — если) это чудо научится нормально диагностировать ошибки, рассмотрю вопрос о пользовании им.
Здравствуйте, Marty, Вы писали:
M>Покажи же нам эту прекрасную библиотеку
Она далеко не прекрасная. Во многих местах она даже весьма кривая, ибо начиналась еще в конце 90-х, и с тех пор многократно дорабатывалась и переделывалась без стремления сохранить единство стиля. Ее достоинство в том, что она не стремится покрыть все мыслимые варианты применения, а ограничивается наиболее простыми и удобными. Ну и в том, что может использоваться как в пользовательском, так и в ядерном коде — для чего, собственно, и создавалась.
M>чтобы мы восхитились и поняли, что std — говно
Не понимаю, зачем нужно чем-то восхищаться (и вообще, с чем-то сравнивать), чтобы это понять? Если сам подход построения программ на трюках общепризнанно считается моветоном (и только для шаблонов C++ старательно обосновывается его исключительность), то говном автоматически становится все, что сделано на основе такого подхода.
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Что именно уродливого в реализации?
ЕМ>Те самые шаблонные трюки, о которых мы много говорили.
Они под капотом, и пользователь с ними не сталкивается
M>>какая тебе, как пользователю, разница, что там под капотом?
ЕМ>Мне не нравится, когда при моих непреднамеренных ошибках все это говно вспучивает из-под капота, и мне приходится разглядывать многострочные, но маловразумительные тексты, чтобы догадаться, что же именно пошло не так.
Это проблема не языка, а отдельных компиляторов. Слышал, кстати, что Clang умеет более менее внятно сообщать об ошибках.
ЕМ>Да, то же самое происходит и с моими шаблонами, но с ними я хоть могу увидеть в исходниках свои комментарии, вроде "сюда нельзя числовой литерал без квалификатора типа".
ЕМ>Когда (точнее — если) это чудо научится нормально диагностировать ошибки, рассмотрю вопрос о пользовании им.
Проблема не в диагностике, а во внятных сообщениях об ошибках. Почему-то мейнстрим компиляторы не парятся внятно о них сообщать, это да.
Кстати, пользуясь случаем (c) хочу передать привет своим родным прорекламировать свою тулзу, которая из портянки сообщения MSVC делает более менее внятное сообщение:
umba-cl-msg — разбирает портянку от MSVC и делает сокращения, превращая сообщение во вполне вменяемое.
По ссылке, сорян, док никаких нет, только один пример разбора. Может, потом как-то руки дойдут дописать.
Вкрации, принимает ввод из STDIN, печатает в STDOUT. Я её обычно использую с файлами, используя в батниках перенаправление.
Релиза тоже нет, но если умеешь в CMake, то либо VSCode'ом, либо вижуалкой соберёшь.
Тулза заточена под MSVC, но с GCC тоже немного помогает
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Покажи же нам эту прекрасную библиотеку
ЕМ>Она далеко не прекрасная. Во многих местах она даже весьма кривая, ибо начиналась еще в конце 90-х, и с тех пор многократно дорабатывалась и переделывалась без стремления сохранить единство стиля. Ее достоинство в том, что она не стремится покрыть все мыслимые варианты применения, а ограничивается наиболее простыми и удобными. Ну и в том, что может использоваться как в пользовательском, так и в ядерном коде — для чего, собственно, и создавалась.
То есть, даже твой велосипед не является прекрасным, у него одно единственное достоинство — писал его лично ты, и поэтому знаешь его вдоль и поперёк. Но это достоинство только для тебя, а std и кучи других плюсовых библиотек являются универсальными для 99% случаев применения, и ими пользуется большинство разработчиков.
M>>чтобы мы восхитились и поняли, что std — говно
ЕМ>Не понимаю, зачем нужно чем-то восхищаться (и вообще, с чем-то сравнивать), чтобы это понять? Если сам подход построения программ на трюках общепризнанно считается моветоном (и только для шаблонов C++ старательно обосновывается его исключительность), то говном автоматически становится все, что сделано на основе такого подхода.
Сам процесс создания софта основан на всевозможных "трюках". Просто одни ты осилил, другие — не смог.
Здравствуйте, Marty, Вы писали:
M>Они под капотом, и пользователь с ними не сталкивается
Пока не допустит где-то ошибки.
M>Это проблема не языка, а отдельных компиляторов.
Корень проблемы находится в языке. Компиляторы лишь в разной степени пытаются ее смягчать.
M>Слышал, кстати, что Clang умеет более менее внятно сообщать об ошибках.
Возможно. Но подбирать компилятор, лучше других умеющий заметать мусор под ковер — так себе идея.
M>Проблема не в диагностике, а во внятных сообщениях об ошибках.
Главная проблема в том, что в языке до сих пор нет внятных средств для построения сложных и одновременно понятных и надежных метаконструкций. Все остальное — лишь следствия.
M>Почему-то мейнстрим компиляторы не парятся внятно о них сообщать, это да.
Прежде всего потому, что компилятор не обладает сведениями об идеях автора, использующего трюки, поэтому сообщает лишь о том, что непосредственно видит. Чтобы компилятор мог сообщать более внятно, ему необходимо исследовать текст сверх того, что необходимо для его компиляции. Неудивительно, что мало кому это интересно.
Попробуйте добиться от дизассемблера внятного отображения программы, активно использующей самомодификацию, переходы внутрь кода команды и подобные трюки, если он специально этому не обучен. Попробуйте добиться от спеллчекера внятной диагностики нарушения логических связей высших порядков, не добавляя в него ИИ. И так далее.
M>прорекламировать свою тулзу, которая из портянки сообщения MSVC делает более менее внятное сообщение:
Спасибо, но сообщения MSVC об "обычных" ошибках меня вполне устраивают, а связываться с шаблонными библиотеками я остерегаюсь.
Здравствуйте, Marty, Вы писали:
M>даже твой велосипед не является прекрасным
У меня не было цели делать его прекрасным. Это просто рабочий инструмент. У меня и молоток не сверкает, и шуруповерт несколько потерт, а преобразователи напряжения и вовсе без корпусов.
M>у него одно единственное достоинство — писал его лично ты, и поэтому знаешь его вдоль и поперёк.
Я бы взял готовую библиотеку, универсальную для user/kernel, но в 90-х таких тупо не было, а потом их стали делать так же, как STL/Boost — на все случаи жизни, мне такое не надо.
M>кучи других плюсовых библиотек являются универсальными для 99% случаев применения, и ими пользуется большинство разработчиков.
Да и на здоровье, я ж не призываю от них отказываться. Многие вот кока-колу каждый день пьют, и им даже нравится.
M>Сам процесс создания софта основан на всевозможных "трюках".
Глупости. Трюки нужны или для реализации редких, сильно нестандартных вещей, для которых не удосужились сделать штатных средств, или для преодоления имманентных недостатков инструмента.
Здравствуйте, rg45, Вы писали:
R>Я как-то затрудняюсь представить, какую нужно допустить ошибку, чтобы возникли затруднения с использованием std::string, или std::vector.
У этих с ошибками проще, но они не живут без поддержки плюсовых исключений.
Здравствуйте, Евгений Музыченко, Вы писали:
R>>Я как-то затрудняюсь представить, какую нужно допустить ошибку, чтобы возникли затруднения с использованием std::string, или std::vector.
ЕМ>У этих с ошибками проще, но они не живут без поддержки плюсовых исключений.
Тебе же задали вопрос конкретно про std::string, или std::vector. Пришли к тому, что
Мне не нравится, когда при моих непреднамеренных ошибках все это говно вспучивает из-под капота, и мне приходится разглядывать многострочные, но маловразумительные тексты, чтобы догадаться, что же именно пошло не так.
Так что в итоге, с твоей точки зрения, пригодны std::string, или std::vector для или нет?
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Они под капотом, и пользователь с ними не сталкивается
ЕМ>Пока не допустит где-то ошибки.
Обычно это бывает только тогда, когда пользователь сам начинает неумело шаблонить. В других случаях ошибок нет, или они весьма понятны.
M>>Это проблема не языка, а отдельных компиляторов.
ЕМ>Корень проблемы находится в языке. Компиляторы лишь в разной степени пытаются ее смягчать.
Нет, компиляторы нихрена не пытаются смягчать. Они просто вываливают портянку сообщения со своей диагностикой, как есть.
Я свою тулзу не просто так написал, и она мне помогает в сложных случаях. Но она просто парсит выхлоп MSVC, а компилятор мог бы делать такую же или, что гораздо вероятнее, гораздо более лучшую работу.
M>>Слышал, кстати, что Clang умеет более менее внятно сообщать об ошибках.
ЕМ>Возможно. Но подбирать компилятор, лучше других умеющий заметать мусор под ковер — так себе идея.
Это как раз не про мусор под ковёр, а про качественную диагностику.
Ещё я, при проблемах с компиляцией, смотрю, выхлоп GCC на том же проекте, часто помогает. Ну и моя тулза тоже помогает, когда портянка слишком большая что в MSVC, что в GCC
M>>Проблема не в диагностике, а во внятных сообщениях об ошибках.
ЕМ>Главная проблема в том, что в языке до сих пор нет внятных средств для построения сложных и одновременно понятных и надежных метаконструкций. Все остальное — лишь следствия.
Да есть, просто ты не осилил.
M>>Почему-то мейнстрим компиляторы не парятся внятно о них сообщать, это да.
ЕМ>Прежде всего потому, что компилятор не обладает сведениями об идеях автора, использующего трюки, поэтому сообщает лишь о том, что непосредственно видит. Чтобы компилятор мог сообщать более внятно, ему необходимо исследовать текст сверх того, что необходимо для его компиляции. Неудивительно, что мало кому это интересно.
Нет конечно. Посмотри мой парсер/упрощатель сообщений MSVC, он замечательно сворачивает простыни от MSVC во вполне внятные сообщения
ЕМ>Попробуйте добиться от дизассемблера внятного отображения программы, активно использующей самомодификацию, переходы внутрь кода команды и подобные трюки, если он специально этому не обучен. Попробуйте добиться от спеллчекера внятной диагностики нарушения логических связей высших порядков, не добавляя в него ИИ. И так далее.
А это ты вообще о чем?
M>>прорекламировать свою тулзу, которая из портянки сообщения MSVC делает более менее внятное сообщение:
ЕМ>Спасибо, но сообщения MSVC об "обычных" ошибках меня вполне устраивают, а связываться с шаблонными библиотеками я остерегаюсь.
Да не за что, не тебе, так может кому-то другому поможет
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я бы взял готовую библиотеку, универсальную для user/kernel, но в 90-х таких тупо не было, а потом их стали делать так же, как STL/Boost — на все случаи жизни, мне такое не надо.
std+boost вполне годна даже для кернель, только надо было осилить кастомные аллокаторы (это если про контейнеры, но std это не только они). На предыдущей работе один деятель написал свои замены векторов/строк и тп для использования на STM32, и оно даже в целом работает, только он там столько граблей разложил, что я себе ладошкой лоб разбил. Он, с одной стороны, неплохо прошарился в шаблоны и в компайл-тайм, с другой стороны лютую хрень творил, не зная кучи всего из базовых вещей. Но у него работа с перифкой контроллера более менее работала, я её использовал, а остальное брал из std или boost'а, и жил шоколадно.
M>>кучи других плюсовых библиотек являются универсальными для 99% случаев применения, и ими пользуется большинство разработчиков.
ЕМ>Да и на здоровье, я ж не призываю от них отказываться. Многие вот кока-колу каждый день пьют, и им даже нравится.
Ммм, а Гитлер ел огурцы. Узнаю неумелого демагога
M>>Сам процесс создания софта основан на всевозможных "трюках".
ЕМ>Глупости. Трюки нужны или для реализации редких, сильно нестандартных вещей, для которых не удосужились сделать штатных средств, или для преодоления имманентных недостатков инструмента.
Сортировка пузырьком — тоже трюк, для продавщицы из Пятёрочки. Она только на кассе кнопки жамкать умеет
Здравствуйте, Евгений Музыченко, Вы писали:
M>>даже твой велосипед не является прекрасным
ЕМ>У меня не было цели делать его прекрасным. Это просто рабочий инструмент. У меня и молоток не сверкает, и шуруповерт несколько потерт, а преобразователи напряжения и вовсе без корпусов.
То, что я уже много раз объяснял — реализация библиотеки, невозможная без использования трюков, уродлива по определению (как и языковые средства, предполагающие, и даже поощряющие использование этих трюков).
R>Тебе же задали вопрос конкретно про std::string, или std::vector.
Ну хорошо, эти простейшие классы можно считать относительно изолированными, и более-менее адекватными в плане структуры своих шаблонов. Но это лишь мелкий фрагмент std, который нет смысла обсуждать изолированно. И их реализация тоже уродлива, ибо не допускает использования без поддержки исключений, которых им по логике вовсе не требуется.
R>с твоей точки зрения, пригодны std::string, или std::vector для или нет?
С моей точки зрения, для написания программ, синтаксически и семантически удовлетворяющих стандартам C++, пригодна вся std. А дальше уже начинаются нюансы.
Здравствуйте, Marty, Вы писали:
M>Обычно это бывает только тогда, когда пользователь сам начинает неумело шаблонить.
"У порядочных людей" такого не должно быть никогда, независимо от умелости пользователя.
M>компиляторы нихрена не пытаются смягчать. Они просто вываливают портянку сообщения со своей диагностикой, как есть.
Сравните эти портянки у компиляторов начала 90-х, когда только были реализованы шаблоны с возможностью SFINAE, где-нибудь начала-середины 2000-х, когда они активно пошли в массы, и сейчас.
M>компилятор мог бы делать такую же или, что гораздо вероятнее, гораздо более лучшую работу.
Я бы предпочел, чтобы компилятор делал более адекватную работу, обрабатывая более вменяемый синтаксис (который возможен, но вряд ли будет реализован), нежели борется с последствиями использования невменяемого.
M>Это как раз не про мусор под ковёр, а про качественную диагностику.
Качественная диагностика возможна тогда, когда программисту предоставлены адекватные возможности для выражения своего замысла. Когда у него есть возможность использовать, грубо говоря, лишь иносказания и намеки, качественная диагностика возможна лишь с помощью эвристических методов, алгоритмические не работают.
M>Ещё я, при проблемах с компиляцией, смотрю, выхлоп GCC на том же проекте, часто помогает.
Ну а я просто не использую инструментов, в выхлопе от которых приходится регулярно разбираться особыми методами. Если вдруг попадется инструмент, использовать который будет значительно проще и эффективнее, чем обойтись без него или написать самому — буду использовать его.
ЕМ>>Главная проблема в том, что в языке до сих пор нет внятных средств для построения сложных и одновременно понятных и надежных метаконструкций.
M>Да есть, просто ты не осилил.
И не собираюсь. Не вижу смысла осиливать хождение по канату исключительно потому, что нынче это модно.
M>А это ты вообще о чем?
Все о том же — что C++ в нынешнем виде не столько "умен", сколько "заумен".
Здравствуйте, Marty, Вы писали:
M>std+boost вполне годна даже для кернель
Она туда "годна" исключительно в том смысле, что технически ее можно было бы туда запилить. И даже использовать, если не смотреть в генерируемый код. Только нет в том ни малейшего смысла.
M>только надо было осилить кастомные аллокаторы
У Вас понятие "осиливания" ассоциируется исключительно с позитивным, желательным, героическим смыслом, к чему стоит стремиться и чем стоит гордиться. Если же немного подумать, то далеко не все, что поддается "осиливанию", оказывается позитивным и желательным.
M>На предыдущей работе один деятель написал свои замены векторов/строк и тп для использования на STM32, и оно даже в целом работает, только он там столько граблей разложил, что я себе ладошкой лоб разбил.
Верно, а почему? Именно потому, что он возомнил, будто это достойный путь крутого программера. Не он первый, не он последний.
Здравствуйте, Marty, Вы писали:
M>Кстати, std — тоже просто рабочий инструмент
Это скорее микроскоп, которым настойчиво предлагается заодно забивать гвозди, выравнивать поверхности, использовать в качестве утяжелителя и т.п., лишь для того, чтобы обойтись одним "универсальным инструментом".
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>С моей точки зрения, для написания программ, синтаксически и семантически удовлетворяющих стандартам C++, пригодна вся std. А дальше уже начинаются нюансы.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ну хорошо, эти простейшие классы можно считать относительно изолированными, и более-менее адекватными в плане структуры своих шаблонов. Но это лишь мелкий фрагмент std, который нет смысла обсуждать изолированно. И их реализация тоже уродлива, ибо не допускает использования без поддержки исключений, которых им по логике вовсе не требуется.
Исключения — ты их хейтишь, потому что пишешь ядрёный код, в котором, как я понимаю, исключения нельзя использовать. Но это нужно 0.001%-у разработчиков. Исключения нужны, чтобы можно было в RAII
Расскажи, как быть, если конструируемая строка не может выделить буфер?
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Кстати, std — тоже просто рабочий инструмент
ЕМ>Это скорее микроскоп, которым настойчиво предлагается заодно забивать гвозди, выравнивать поверхности, использовать в качестве утяжелителя и т.п., лишь для того, чтобы обойтись одним "универсальным инструментом".
Нет, это лаборатория, совмещенная с мастерской, где есть и молоток и микроскоп, уровень и правило, утяжелители, и даже гири со штангами.
Нет, std я не использую прежде всего потому, что она навязывает чрезмерные для меня требования.
R>тебе точно нужен C++?
Ну, до сих пор я не нашел языка, на котором мог бы более эффективно и комфортно делать то, что делаю.
R>А может тогда и в форуме C++ нужно вести себя как-то поскромнее — не делать заявлений космического масшаба
Каким образом возможности C++, которые я (и не только я) считаю убогими, могли бы стать менее убогими от того, что я ими не пользуюсь (или стараюсь не пользоваться)?
Здравствуйте, Marty, Вы писали:
M>Исключения — ты их хейтишь, потому что пишешь ядрёный код
Нет — прежде всего потому, что их концепция в C++ нарушает его собственный принцип "не платить за то, чего не используешь". Используй они в минимальном варианте только коды и указатели, и лишь в расширенном — произвольные типы, я б их так не хейтил.
M>в котором, как я понимаю, исключения нельзя использовать.
Это не проблема. Если б я любил исключения, то давно бы сколхозил для них собственную поддержку.
M>Исключения нужны, чтобы можно было в RAII
Они для этого не "нужны", а "могут использоваться'. Я вполне себе активно использую RAII без исключений.
M>Расскажи, как быть, если конструируемая строка не может выделить буфер?
Известно, как. Можно вызвать заранее заданную функцию-обработчик, можно сконструировать "невалидную" строку, которая вернет этот признак при опросе, а при попытке что-то с нею делать вызовет уже обработчик более высокого уровня, или системное исключение.
Исключения в C++ — одно из нескольких мест, где при переходе от C перескочили сразу через несколько промежуточных этапов, поставив простоту и универсальность выше масштабируемости.
Здравствуйте, Marty, Вы писали:
M>это лаборатория, совмещенная с мастерской, где есть и молоток и микроскоп, уровень и правило, утяжелители, и даже гири со штангами.
Здравствуйте, Shmj, Вы писали:
S>Встречали ли вы такую концепция кодирования? Одобряете?
Встречал. От языка это мало зависит и присутствует в той или иной мере во всех языках.
Обычные ограничения:
запрет на goto или его разновидности
запрет на переиспользование переменных
запрет на использование чисел с плавающей точкой
запрет на использование самоизменяющегося кода.
Редкие ограничения:
запрет на алокацию памяти
запрет на использование макросов
запрет на использование голых указателей
запрет на использование информации о типе
запрет на использование циклов для прохода по массиву
запрет на множественное наследование данных
Некоторые языки разрабатываются только для того, чтобы внести свои новые ограничения, но как по мне — это тупиковый путь.
К сожалению зараза запретов проникла и в С++. Мешает, понимаешь, свобода оптимизации.
Здравствуйте, Shmj, Вы писали:
S>Вопрос такой.
S>Встречалась ли вам концепция — "C++ как C с классами". Т.е. когда правила кодирования устанавливают запрет на множество фич, которые есть в языке, но которые часто запутывают код и делают сложным для восприятия — сводят фактически к C, но с удобным синтаксисом для RAII. Однако же указатели и пр. — используются все как в C.
Да, встречалась. Но RAII уже позволяет создать умный указатель, а значит позволяет минимально автомативировать управление памятью.
S>Причем на C успешно пишут все что угодно — то какие проблемы делать то же самое, добавив в C — удобный RAII в мин. варианте?
Вместе с удобным RAII в нагрузку добавится десяток граблей, это уже будет не С. Главным особенностью С является относительная низкоуровневость языка и отсутствие каких либо скрытых параметров, код будет делать только то, что ты явно написал. Если добавить RAII то появится какие-то правила, автоматический вызов каких-то функций, простота и низкоуровневость пропадут.
S>B здесь главное не поддаться греху гордыни — когда тебе хочется доказать другим что ты способен, что SFINAE и 4-х этажные шаблоны тебе по плечу. А нужно не поддаваться греху гордыни а наоборот проявить смирение и кротость — аскетизм. Ограничить себя в излишествах и довольствоваться простым минимализмом. S>
S>В принципе — я всецело поддерживаю и уважаю эту концепцию C++. Чем проще код — тем лучше. Кто хочешь поддаться греху гордыни — есть вам Haskell — пожалуйста.
Поддерживаю, но лишь отчасти. Если код уже написан на С с классами, то закидывать туда трехэтажный шаблон как-то нехорошо. И да, надо пытаться писать простой и ясный код. Но стоит ли реально отказываться от полезных возможностей? Помню, на чистом С, я задолбался, когда мне надо было сделать не совсем тривиальный разбор аргументов коммандной строки. При этом используя С++ строки std::map я бы сделел это за 10 минут. А ведь стандартые контейнеры это довольно непростые шаблоны. Надо ли от них отказываться?
S>Но! С появлением умных указателей стала возможна другая концепция — C++ может быть аналогом ЯВУ типа C#|Java. В чем суть? Суть в том, чтобы в угоду простоте кодирования и отладки — отказаться от ряда фич языка, запретить их использование. А именно:
Во первых концепция умных указателей в С++ очень старая, и относится к 90-м годам. Книга Джеффа Элджера, где он детально расписывает множество видов умных указателей вышла в 99 году. И он там описывает то, что тогда уже активно использовалось ведущими специалистами.
Во вторых не стоит сравнивать умные указатели со сборщиком мусора, это совершенно разные концепции, и они вообще друг на друга не похожи. То есть это совсем не Java и не C#.
S>1. Отказ от сырых указателей, буквальный запрет их в коде. Замена — умные указатели, ссылки, std::optional, std::optional<std::reference_wrapper<>>.
Я поддерживаю отказ от ручного управления памятью. Нельзя вручную вызывать new и delete. Но полный отказ от указателей не поддерживаю. Указатель простой способ передать объект не передавая владение. Да, надо быть осторожным, и лучше не передавать сырой указатель, если он там куда-то далеко пробрасывается.
S>2. Отказ от сложных шаблонов, вариадических, SFINAE, запрет концептов. Т.е. свести к уровню шаблонов в Java/C#.
Поддерживаю частично. Главное не писать сложные шаблоны просто потому, что можешь. Надо всегда понимать, зачем это тебе, и бить себя по рукам, если просто хочется еще обобщить и добавить еще один уровень абстракции. В 99% случаев сложные шаблоны не нужны, но в 1% это может реально помочь, не стоит полностью отказываться.
Даже простые шаблоны в С++ очень сильно отличаются от java/C#. Это внутри совершенно разные вещи.
S>3. Отказ от макросов.
Тут полностью поддерживаю. Ну макросы можно например использовать для отладочного логирования, чтобы добавить в описание ошибки имя функции или для условной компиляции. Активно использовать макросы для абстракции и кодогенерации — это зло и делает код вообще не читаемым. Если уж так хочется погенерировать код, лучше использовать какой нибудь внешний скриптовый язык.
S>4. Запрет множественного наследования реализаций.
Тоже полностью поддерживаю. Не знаю ни одного случая, где бы это реально было нужно. Более того, считаю, что наследование реализвации даже не множественное тоже не особо нужно, его всегда можно заменить агрегированием, а наследовать только интерфейсы. Наследование реализации размазывает функиональность по иерархии классов и ухудшает читаемость кода. Хрен поймешь какой там реально класс, где и когда метод был переопределен, и что именно там вообще вызывается, когда видишь вызов метода.
S>5. И т.д. (это примерный список, на самом деле гораздо больше).
S>Вы скажите — в чем тогда смысл, не лучше ли писать сразу на Java? А смысл чисто практический — по факту С++ наиболее кросс-платформенный и наименее гемморный на сегодня. Дошло до того, что C# компиллят в C++. Здесь не вопрос холивара — просто по факту так оно и есть.
Подход java очень сильно отличается и при всем желании на C++ не получится писать как на java. Под капотом там все совсем подругому работает.
И вообще я скажу да, если вы не можете точно сказать, зачем вам С++, то лучше пишите на java или еще на чем-нибудь, сейчас есть новые молодежные языки.
S>Встречали ли вы такую концепция кодирования? Одобряете?
То что ты написал, это не java, по болшей части одобряю.
Здравствуйте, Евгений Музыченко, Вы писали:
S>>3. Отказ от макросов.
ЕМ>C++ слишком убог, чтобы это было возможно без серьезного урезания удобства работы с ним.
Ну, убогость С++ вообще это вопрос довольно спорный. Но вот препроцессор С, перекочевавший в С++ действительно убог. Причем настолько убог, что от макросов в С++ действительно надо по возможности максимально стараться отказаться (полностью отказаться конечно не возможно).
Здравствуйте, rg45, Вы писали:
R>Здравствуйте, Shmj, Вы писали:
S>>Вопрос такой. S>>Встречалась ли вам концепция — "C++ как C с классами"...
R>У меня вопрос другой: ты нахрена опять профильный форум загаживаешь своей трепологией? Тебе КСВ мало?
Там вроде кнопочка есть для модерации. Не знаю наверняка, как она устроена, увы в ветке С++ у меня нет полномочий, но весь его флуд из Qt я, как правило, напрямую перекидываю в "священные войны".
Здравствуйте, ksandro, Вы писали:
K>от макросов в С++ действительно надо по возможности максимально стараться отказаться
А на что их менять-то? Только самые кондовые макросы можно без потери функциональности, общности и удобства заменить на инлайн-функции или шаблоны.
K>(полностью отказаться конечно не возможно)
Это одно из следствий убожества C++ — если C был простым, кондовым, и внутренне достаточно согласованным, то C++ уже через несколько лет после начала своего шествия в массы стал превращаться в нечто бесформенное, что одни старательно пытались втиснуть в некие рамки (порой весьма странные), а другие, столь же старательно — превратить в нечто совершенно чудовищное.
Здравствуйте, SaZ, Вы писали:
SaZ>Там вроде кнопочка есть для модерации. Не знаю наверняка, как она устроена, увы в ветке С++ у меня нет полномочий, но весь его флуд из Qt я, как правило, напрямую перекидываю в "священные войны".
Ну у него же был период, когда он проявлял сознательность и, по крайней мере, стался не флудить в форуме С++. Но сейчас вот снова у него гайки сорвало. Видимо, на почве неудовлетворённого интереса по поводу его примера
Здравствуйте, rg45, Вы писали:
R>Здравствуйте, SaZ, Вы писали:
SaZ>>Там вроде кнопочка есть для модерации. Не знаю наверняка, как она устроена, увы в ветке С++ у меня нет полномочий, но весь его флуд из Qt я, как правило, напрямую перекидываю в "священные войны".
R>Ну у него же был период, когда он проявлял сознательность и, по крайней мере, стался не флудить в форуме С++. Но сейчас вот снова у него гайки сорвало. Видимо, на почве неудовлетворённого интереса по поводу его примера
Ну он либо очень толстый тролль, либо человек у которого проблемы с социализацией и эмпатией. И он осторожно пытается это дело компенсировать форумом, совершенно не понимая какой дискомфорт он доставляет.
Тут ещё есть другая категория похожих людей (не только на рсдн) — это которые упорно долбят старьё и при этом категорически отказываются от новых технологий, думая что старое == хорошее. И сидят такие на Qt4, MFC, WTL и прочих. При этом пытаются доказывать и аргументировать свою позицию фразами типа "для моих задач этого достаточно", а потом начинают бороться с тем, что умные люди уже давно решили в современных фреймворках.
Здравствуйте, SaZ, Вы писали:
SaZ>И сидят такие на Qt4, MFC, WTL и прочих. При этом пытаются доказывать и аргументировать свою позицию фразами типа "для моих задач этого достаточно", а потом начинают бороться с тем, что умные люди уже давно решили в современных фреймворках.
Ну вот я охотно и с удовольствием применяю свежайшие микросхемы, транзисторы, датчики и прочие радиодетали в электронных устройствах, ибо они одновременно меньше по размерам, массе, универсальнее, неприхотливее, надежнее, проще (как правило) в применении и т.п. То есть, от их применения получаешь чистое удовольствие, и [почти] не получаешь неприятных эмоций.
А вот как только я касаюсь даже относительно новых программных решений, так почти всегда оказывается, что они непропорционально велики по размеру, требуют неадекватных своей функциональности ресурсов, достаточно свежих версий ОС, библиотек и компонент, накладывают искусственные ограничения, тормозят в работе и т.п. А те, кто хоть давно, хоть недавно решился с ними связаться, регулярно жалуются на очередные ограничения в использовании, отказ от поддержки не самых старых систем, повышение требований к ресурсам и т.п. Поэтому я каждый раз печально вздыхаю, и делаю все нужное сам.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А вот как только я касаюсь даже относительно новых программных решений, так почти всегда оказывается, что они непропорционально велики по размеру, требуют неадекватных своей функциональности ресурсов, достаточно свежих версий ОС, библиотек и компонент, накладывают искусственные ограничения, тормозят в работе и т.п. А те, кто хоть давно, хоть недавно решился с ними связаться, регулярно жалуются на очередные ограничения в использовании, отказ от поддержки не самых старых систем, повышение требований к ресурсам и т.п. Поэтому я каждый раз печально вздыхаю, и делаю все нужное сам.
Вот у меня с консервированными огурцами такая же фигня. То голова в банку не пролазит, то рука застревает.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, Marty, Вы писали:
M>Чего уродливого в std::string или std::vector?
Они хранят данные одним куском. Уже жирный минус. std::string это std::basic_string<char>, но почему никто не использует std::basic_string<unsigned char> знаете? Это ли не уродство?
M>Или в сортировке, например: std::stable_sort(v.begin(), v.end())?
Почему аргументы должны быть одинакового типа?
Здравствуйте, rg45, Вы писали:
R>Я как-то затрудняюсь представить, какую нужно допустить ошибку, чтобы возникли затруднения с использованием std::string, или std::vector.
std::string — засунуть '\0' в середину и удивляться выводу...
например, так:
char asdf[20];
.... //получение данных в asdf от устройства
std::string str(std::begin(asdf), std::end(asdf));
std::vector — ну, классика — это конструктор с двумя аргументами.
Вот из недавнего:
std::vector<char> factorList{0x20, 0x80};
— компиляция пройдёт или нет, в зависимости от того , какой нынче char у компилятора, но если исправить на
Здравствуйте, B0FEE664, Вы писали:
R>>Я как-то затрудняюсь представить, какую нужно допустить ошибку, чтобы возникли затруднения с использованием std::string, или std::vector. BFE> BFE>std::string — засунуть '\0' в середину и удивляться выводу... BFE>например, так:
А если бы std::string не был шаблоном, это как-то помогло бы? Так-то ноль можно и в середину строкового литерала засунуть и точно так же удивляться.
Я думал, мы говорим о такких ошибках, которые приводят к ошибкам компиляции:
Мне не нравится, когда при моих непреднамеренных ошибках все это говно вспучивает из-под капота, и мне приходится разглядывать многострочные, но маловразумительные тексты, чтобы догадаться, что же именно пошло не так.
BFE>std::vector — ну, классика — это конструктор с двумя аргументами. BFE>Вот из недавнего: BFE>
Если использование библиотеки предполагает включение заголовка с этими "десятиэтажными шаблонами" в клиентский код, она никак не может быть "максимально проста в использовании". Чисто технически.
У него главная и единственная претензия к стандартной библиотеке — это то, что она шаблонная. Все твои нюансы ему до фонаря.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, B0FEE664, Вы писали:
M>>Чего уродливого в std::string или std::vector? BFE>Они хранят данные одним куском. Уже жирный минус.
И в чем же минус? Более того, это поведение заложено в спеке. Есть куча других контейнеров, которые по разному хранят данные. Это самая универсальная базовая структура, и максимально быстрая структура с произвольным доступом к элементам. Мне было бы очень странно выдеть вектор и строку, реализованные как-то иначе.
BFE>std::string это std::basic_string<char>, но почему никто не использует std::basic_string<unsigned char> знаете? Это ли не уродство?
Во-первых — не знаю, во-вторых я частенько использую. В-третьих таки в чем уродство?
M>>Или в сортировке, например: std::stable_sort(v.begin(), v.end())? BFE>Почему аргументы должны быть одинакового типа?
Самый универсальный способ задания последовательности — начальным и конечным итераторами, полуоткрытый интервал. Любое другое — будет кривизна
Здравствуйте, B0FEE664, Вы писали:
R>>Я как-то затрудняюсь представить, какую нужно допустить ошибку, чтобы возникли затруднения с использованием std::string, или std::vector. BFE> BFE>std::string — засунуть '\0' в середину и удивляться выводу...
BFE>например, так:
BFE>
BFE>char asdf[20];
BFE>.... //получение данных в asdf от устройства
BFE>std::string str(std::begin(asdf), std::end(asdf));
BFE>
Если данные, полученные из неизвестных недостоверных источников, не глядя запихивать хоть куда, то удивление выводом — это одно из самых минимальных удивлений, которые тебя ожидают.
А так — я вполне себе при нужде храню в строках нули.
BFE>std::vector — ну, классика — это конструктор с двумя аргументами. BFE>Вот из недавнего: BFE>
Да, с инитиализер лист и универсальной инициализацией не всегда очевидно, появилось много новых способов ининциализации. Но можно таки выбрать менее неоднозначные, ну и да, надо ориентироваться в этих правилах. Для тебя сюрприз, что язык надо знать?
Но это не проблема конкретно вектора. Это дизайн языка. Наверное, можеткак-то и можно было сделать лучше, но чтобы понимать, почему сделали именно так, надо читать PR по всем этим дополнениям, и их обсуждения. Тогда, наверное, будет понятно, почему сделали так, а не иначе.
Здравствуйте, SaZ, Вы писали:
SaZ>Тут ещё есть другая категория похожих людей (не только на рсдн) — это которые упорно долбят старьё и при этом категорически отказываются от новых технологий, думая что старое == хорошее. И сидят такие на Qt4, MFC, WTL и прочих. При этом пытаются доказывать и аргументировать свою позицию фразами типа "для моих задач этого достаточно", а потом начинают бороться с тем, что умные люди уже давно решили в современных фреймворках.
Ну, я не то чтобы упорно долблю старьё, но по плюсам — отстаю обычно на один или два стандарта — не хочу вновь раскладываемым граблям ходить, жду, когда устаканится.
Qt — пока на пятом, ничего нового не делаю, а старые тулзы, которые по мелочам допиливаются, переносить на шестой — а зачем мне этот гемор на ровном месте?
WTL — когда надо что-то легковесное сделать, чисто под винду, обычно это какие-то диалоги — и сейчас использую без проблем.
Здравствуйте, rg45, Вы писали:
R>Я думал, мы говорим о такких ошибках, которые приводят к ошибкам компиляции:
То, что ему чего-то не нравится — это его личные предпочтения. Пока нет конкретики, говорить не о чем.
R>У него главная и единственная претензия к стандартной библиотеке — это то, что она шаблонная.
Нет. Позиция Евгения Музыченко хорошо известна, он её много раз излагал. Суть сводится к тому, что он попытка связать std и C++ в единый и неразрывный монолит — это стратегически плохая идея и что эти две части всегда надо рассматривать отдельно друг от друга. Ещё ему не нравится std из-за стиля, из-за хрупкости шаблонов и скрытых требований к ресурсам. Других разумных аргументов он не излагал.
R>Все твои нюансы ему до фонаря.
Так я не ему отвечал. Не по теме? Как скажите.
Здравствуйте, Marty, Вы писали:
M>Если данные, полученные из неизвестных недостоверных источников, не глядя запихивать хоть куда, то удивление выводом — это одно из самых минимальных удивлений, которые тебя ожидают. M>А так — я вполне себе при нужде храню в строках нули.
Удивление не в данных, а в том, что с одной стороны std::string всегда хранит завершающий ноль, а с другой может ещё и в середине ноль хранить.
BFE>>std::vector — ну, классика — это конструктор с двумя аргументами. BFE>>Вот из недавнего: BFE>>
BFE>>то можно получить цвет детской неожиданности.
M>Да, с инитиализер лист и универсальной инициализацией не всегда очевидно, появилось много новых способов ининциализации. Но можно таки выбрать менее неоднозначные, ну и да, надо ориентироваться в этих правилах. Для тебя сюрприз, что язык надо знать?
Помнить все 20 способов инициализации, притом, что некоторые зависят от используемого стандарта — это просто и удобно.
Ну и ещё надо всегда держать в памяти, что авторы стандарта пишут не то, что хотят сказать.
M>Но это не проблема конкретно вектора. Это дизайн языка. Наверное, можеткак-то и можно было сделать лучше, но чтобы понимать, почему сделали именно так, надо читать PR по всем этим дополнениям, и их обсуждения. Тогда, наверное, будет понятно, почему сделали так, а не иначе.
Нет, это, конкретно, проблема вектора, причём она существовала с самого начала. Эта проблема легко распознаётся ещё на стадии написания реализации конструктора с двумя (тремя, на самом деле) параметрами, так как его реализация весьма и весьма сложна.
Здравствуйте, B0FEE664, Вы писали:
M>>Если данные, полученные из неизвестных недостоверных источников, не глядя запихивать хоть куда, то удивление выводом — это одно из самых минимальных удивлений, которые тебя ожидают. M>>А так — я вполне себе при нужде храню в строках нули. BFE>Удивление не в данных, а в том, что с одной стороны std::string всегда хранит завершающий ноль, а с другой может ещё и в середине ноль хранить.
А в чем проблема? Завершающий ноль — для совместимости с сишными АПИ. Не было бы его — ты бы кричал — какая кривая std::string, нельзя сишные АПИ использовать с ней.
Ноль в середине? А что надо делать, если программист сам его по недомыслию кладёт?
M>>Но это не проблема конкретно вектора. Это дизайн языка. Наверное, можеткак-то и можно было сделать лучше, но чтобы понимать, почему сделали именно так, надо читать PR по всем этим дополнениям, и их обсуждения. Тогда, наверное, будет понятно, почему сделали так, а не иначе. BFE>Нет, это, конкретно, проблема вектора, причём она существовала с самого начала. Эта проблема легко распознаётся ещё на стадии написания реализации конструктора с двумя (тремя, на самом деле) параметрами, так как его реализация весьма и весьма сложна.
Не понял, когда это эта проблема с самого начала существовала? У вектора, у строк, у деки, у других контейнеров всегда была версия конструктора, принимающего count и значение элемента, которым надо заполнить. Никогда с этим не было никаких проблем.
Здравствуйте, Marty, Вы писали:
M>>>Если данные, полученные из неизвестных недостоверных источников, не глядя запихивать хоть куда, то удивление выводом — это одно из самых минимальных удивлений, которые тебя ожидают. M>>>А так — я вполне себе при нужде храню в строках нули. BFE>>Удивление не в данных, а в том, что с одной стороны std::string всегда хранит завершающий ноль, а с другой может ещё и в середине ноль хранить. M>А в чем проблема?
Это отход от принципа "не платим за то, что не используем." M>Завершающий ноль — для совместимости с сишными АПИ.
Для совместимости было бы логично завести отдельный класс. M>Не было бы его — ты бы кричал — какая кривая std::string, нельзя сишные АПИ использовать с ней.
И был бы прав: С++ строка, С строка и, скажем, BSTR строка — это три разные вида строк. Для каждой из них следует сделать отдельный класс: в С строке не хранится длина, в C++ нет завершающего нуля и единого куска, а BSTR лежит в памяти в определённом порядке. Они должны свободно конвертироваться одна в другую и поддерживать операции с общими названиями.
M>Ноль в середине? А что надо делать, если программист сам его по недомыслию кладёт?
А что будет в С если '\0' засунуть в середину строки?
M>Не понял, когда это эта проблема с самого начала существовала? У вектора, у строк, у деки, у других контейнеров всегда была версия конструктора, принимающего count и значение элемента, которым надо заполнить. Никогда с этим не было никаких проблем.
Да, был не прав, конечно, у других контейнеров std конструкторы с двумя параметрами имеют ту же проблему: по виду x(a, b) который из двух конструкторов вызовется сказать нельзя — надо знать типы a и b. Разрешали и разрешают эту ситуацию с помощью метапрограммирования.
Здравствуйте, B0FEE664, Вы писали:
M>>А в чем проблема? BFE>Это отход от принципа "не платим за то, что не используем."
Так постоянно используется. Да и завершающий 0 — смешная плата
M>>Завершающий ноль — для совместимости с сишными АПИ. BFE>Для совместимости было бы логично завести отдельный класс.
И туда-сюда конвертить?
А такая строка, без завершающего нуля — уже есть. Называется std::vector<char>
M>>Не было бы его — ты бы кричал — какая кривая std::string, нельзя сишные АПИ использовать с ней. BFE>И был бы прав: С++ строка, С строка и, скажем, BSTR строка — это три разные вида строк. Для каждой из них следует сделать отдельный класс: в С строке не хранится длина, в C++ нет завершающего нуля и единого куска, а BSTR лежит в памяти в определённом порядке. Они должны свободно конвертироваться одна в другую и поддерживать операции с общими названиями.
BSTR — это вообще частный случай строк в одной из технологий на одной из платформ. Можешь сделать сам класс для BSTR. Хотя стоп, такие классы вроде уже есть в MFC/ATL. Не помню, правда, есть ли там конвертация в/из std::string. Можешь дописать
А зачем тебе отдельно С++ строка и С строка? Чтобы при вызове сишного АПИ было дополнительное преобразование?
M>>Не понял, когда это эта проблема с самого начала существовала? У вектора, у строк, у деки, у других контейнеров всегда была версия конструктора, принимающего count и значение элемента, которым надо заполнить. Никогда с этим не было никаких проблем.
BFE>Да, был не прав, конечно, у других контейнеров std конструкторы с двумя параметрами имеют ту же проблему: по виду x(a, b) который из двух конструкторов вызовется сказать нельзя — надо знать типы a и b. Разрешали и разрешают эту ситуацию с помощью метапрограммирования.
Надо просто запомнить, что первым аргументом идёт count, вторым — значение элемента. Так как у всех контейнеров это сделано единообразно, запомнить не так уж сложно. Также есть метод assign с такой же сигнатурой.
Ни разу не приходилось использовать метапрограммирование для использования таких конструкторов. Зачем? Для чего?
Здравствуйте, Marty, Вы писали:
M>... M>Qt — пока на пятом, ничего нового не делаю, а старые тулзы, которые по мелочам допиливаются, переносить на шестой — а зачем мне этот гемор на ровном месте? M>...
Ну тут вопрос в том, что именно делать. Если нужен современный гуй, рисуемый на gpu, с поддержкой анимаций и т.п., то в qt5 qml безнадёжно устарел. А шестой уже очень хорошо умеет даже в вебассембли. Я вот сча стартапчик начал делать на нём. Бэкэнд: userver, фронт: в основном qml, шаред код: cpp, boost, sqlite_orm. На выходе получается сервер под линух (или мак для отладки), мобильные приложения под iOS/Android (с мобильным сайтом решил не упарываться), а под десктоп/планшеты — wasm через веб, ну или тоже нативное приложение (впрочем, сомневаюсь что оно пригодится).
Вообще меня впечатлила на это дело демка: try.qt.io. Я понимаю, что в qml хватает косяков, я за ним слежу лет 8, но сейчас считаю что технология вполне себе созрела для продакшена. В ембеддед я не умею, там уже давно и много где qml.
Здравствуйте, SaZ, Вы писали:
SaZ>Ну тут вопрос в том, что именно делать. Если нужен современный гуй, рисуемый на gpu, с поддержкой анимаций и т.п., то в qt5 qml безнадёжно устарел. А шестой уже очень хорошо умеет даже в вебассембли. Я вот сча стартапчик начал делать на нём. Бэкэнд: userver, фронт: в основном qml, шаред код: cpp, boost, sqlite_orm. На выходе получается сервер под линух (или мак для отладки), мобильные приложения под iOS/Android (с мобильным сайтом решил не упарываться), а под десктоп/планшеты — wasm через веб, ну или тоже нативное приложение (впрочем, сомневаюсь что оно пригодится).
Здравствуйте, B0FEE664, Вы писали:
BFE>Позиция Евгения Музыченко хорошо известна, он её много раз излагал. Суть сводится к тому, что он попытка связать std и C++ в единый и неразрывный монолит — это стратегически плохая идея и что эти две части всегда надо рассматривать отдельно друг от друга.
Это, по большому счету, меньшее зло. В конце концов, пока в ядре языка практически нет скрытых завязок на std (тот же for по коллекции не заставляет ее импортировать), это не мешает жить на практике, больше добавляет непоняток в обсуждениях.
BFE>Ещё ему не нравится std из-за стиля, из-за хрупкости шаблонов и скрытых требований к ресурсам.
Вот это — основная претензия. "Хрупкость шаблонов" ведь не на пустом месте возникла — это прямое следствие того, что механизм шаблонов до сих пор не имеет адекватных средств управления ими, и все, что выходит за пределы простого обобщения, по-прежнему реализуется исключительно на побочных эффектах (трюках), которые технически невозможно полностью запихать "под капот", чтоб они оттуда никак не вылезали.
Мне это все напоминает электрощит со множеством торчащих из него проводов, которые то коряво скручены, то соединены самодельными переходниками, где соединены провода разного сечения и цвета, одножильные и многожильные, медные и алюминиевые, одни соединения коряво обмотаны изолентой, другие столь же коряво облиты термоклеем, и так далее. Часть защитных автоматов закорочена, еще часть не соответствует по номиналам, и т.п.
Но апологеты всей этой кухни напирают прежде всего на то, что щит снаружи закрыт красивой крышкой, на которой аккуратным шрифтом сделаны пометки. А то, что из-под крышки регулярно идет дым и летят искры, и ее приходится снимать, они предпочитают лишний раз не вспоминать.
Здравствуйте, Евгений Музыченко, Вы писали:
R>>У него главная и единственная претензия к стандартной библиотеке — это то, что она шаблонная.
ЕМ>Это Вы так упрощенно понимаете. Ну, или каждый раз забываете все мои разъяснения по этим вопросам.
Всего лишь слегка утрирую. Художественная пессимизация.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, Shmj, Вы писали:
S>Вопрос такой.
S>Встречалась ли вам концепция — "C++ как C с классами".
S>Вы скажите — в чем тогда смысл, не лучше ли писать сразу на Java? А смысл чисто практический — по факту С++ наиболее кросс-платформенный и наименее гемморный на сегодня. Дошло до того, что C# компиллят в C++. Здесь не вопрос холивара — просто по факту так оно и есть.
S>Встречали ли вы такую концепция кодирования? Одобряете?
На концептуальный вопрос, концептуальный ответ
Если инструмент не позволяет сделать что-то эффективно,
то следует его заменить или разработать новый..
..Компилятор:
(1) Исходный текст -> (2) сборка модели программы -> (3) компиляция в ядре языка -> (4) целевой код.
1. Исходный текст находится терминах задачи.
Далее он трансформируется в модель программы на языке согласно некоторому стандарту.
Сейчас стандарт навязывается производителями компиляторов.
2. Исходный текст нужен лишь для первичной сборки модели программы в компиляторе.
Сложность модели зависит от стандарта (языка) компилятора.
Но здесь возможна точка сборки локального стандарта проекта
из доступных имеющихся свойств компилятора (языка),
а если нет нужных свойств, то их можно/нужно дописать под проект,
расширив свойства (языка) компилятора.
3. Если мы собрали локальный стандарт проекта,
то и компиляция в целевой код будет согласно уже локальному стандарту проекта.
4. Целевой код тоже может быть разным,
даже текстовым для компиляторов (языков) низшего уровня.
Получается:
Для входа на некоторую платформу,
необходим базовый компилятор с минимальными свойствами платформы.
Минимальные свойства можно стандартизировать,
а расширенные поставлять в виде программных свойств проекта.
Это можно проделать почти на любом языке программирования.
PS: Думаю, что модель компиляторов с закрытыми свойствами весьма ограничена.
Здравствуйте, Pzz, Вы писали:
S>>Go — это сборщик мусора, тащить за собой всю среду не оно. Как и .Net.
Pzz>.Net ташит за собой рантайм в виде кучи файлов. Go просто линкует программу статически.
Native AOT все в одном файле с урезанием. Там из рантайма только сборщик мусора несколько сотен килобайт.
Да и обычный .Net со всем рантаймом можно в 1 файл.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Marty, Вы писали:
M>>>А в чем проблема? BFE>>Это отход от принципа "не платим за то, что не используем." M>Так постоянно используется. Да и завершающий 0 — смешная плата
Это минимум одно присвоение на каждое добавление символа.
M>>>Завершающий ноль — для совместимости с сишными АПИ. BFE>>Для совместимости было бы логично завести отдельный класс. M>И туда-сюда конвертить?
Если надо.
M>А такая строка, без завершающего нуля — уже есть. Называется std::vector<char>
Это не строка: у него нет многих строковых методов find..., substr, compare, оператора сложения...
Опять же: вектор — не лучший выбор.
M>BSTR — это вообще частный случай строк в одной из технологий на одной из платформ.
Нет. Это просто название от MS, а сама методика хранения длины строки перед указателем пришла из UNIX, насколько я знаю.
M> Можешь сделать сам класс для BSTR. Хотя стоп, такие классы вроде уже есть в MFC/ATL. Не помню, правда, есть ли там конвертация в/из std::string. Можешь дописать
Написать то я могу всё что угодно, но проблема в том, что потом каждому сотруднику придётся это изучать, чтобы развивать код, а обычный программист ой как не любит изучать "велосипеды".
M>А зачем тебе отдельно С++ строка и С строка? Чтобы при вызове сишного АПИ было дополнительное преобразование?
А зачем мне C вызовы?
M>>>Не понял, когда это эта проблема с самого начала существовала? У вектора, у строк, у деки, у других контейнеров всегда была версия конструктора, принимающего count и значение элемента, которым надо заполнить. Никогда с этим не было никаких проблем.
В каком-то смысле — да, с самого начала. У конструктора с двумя параметрами очень сложная имплементация.
BFE>>Да, был не прав, конечно, у других контейнеров std конструкторы с двумя параметрами имеют ту же проблему: по виду x(a, b) который из двух конструкторов вызовется сказать нельзя — надо знать типы a и b. Разрешали и разрешают эту ситуацию с помощью метапрограммирования. M>Надо просто запомнить, что первым аргументом идёт count, вторым — значение элемента. Так как у всех контейнеров это сделано единообразно, запомнить не так уж сложно. Также есть метод assign с такой же сигнатурой. Всё несколько сложнее:
Какого размера вектора v1 и v2 ?
Есть ли какие либо проблемы с векторами v4, v5 и v6?
M>Ни разу не приходилось использовать метапрограммирование для использования таких конструкторов. Зачем? Для чего?
метапрограммирование спрятано внутри, вы им пользуетесь, просто не знаете об этом.
`v6` — самый подлый, остальные, в принципе, понятно, что получится, хоть и визуальные различия на v2 и v3 реально можно влёгкую пропустить (благо, в большинстве случаев компиляция отвалится дальше, т.к. тип элементов контейнера будет не такой, как ожидалось.
в пример, для ещё лучшего осознания красот двухпараметровой инициализации, можно добавить,
std::vector v7(a, b);
std::vector v8(b, a);
и ещё прикольнее, если тип конструируемой сущности и аргументов конструктора — параметр шаблона типа
template<typename T, typename... ARG>
auto construct(ARG&&... arg)
{
T ret( std::forward<ARG>(arg)...); // (1)
T ret{ std::forward<ARG>(arg)...}; // (2)
// do some processing, registration of `ret` etcreturn ret;
}
Какой вариант правильнее, (1) или (2)? Вроде как (2) кошернее, если там хочешь сужающих преобразований типов избежать, к примеру, ну и вообще, "Uniform" жеж. Но если T — вектор, к примеру, тады ой.
Когда vector виден в коде явно — ещё можно на опыте среагировать на то, что {} может делать не то, что от него ожидал автор. А вот в шаблоне — уже нужно напрячься.
Короче, при всей моей любви к C++, не могу не согласиться, что инициализацию сложно назвать элегантной. Возможно, самое элегантное, что можно было придумать в связи с появлением новых видов инициализации при необходимости иметь обратную совместимость, но от этого элегантности больше не становится.
Здравствуйте, serg_joker, Вы писали:
_>и ещё прикольнее, если тип конструируемой сущности и аргументов конструктора — параметр шаблона типа _>
_>template<typename T, typename... ARG>
_>auto construct(const T&, ARG&&... arg)
_>{
_> T ret( std::forward<ARG>(arg)...); // (1)
_> T ret{ std::forward<ARG>(arg)...}; // (2)
_> // do some processing, registration of `ret` etc
_> return ret;
_>}
_>
_>Какой вариант правильнее, (1) или (2)? Вроде как (2) кошернее, если там хочешь сужающих преобразований типов избежать, к примеру, ну и вообще, "Uniform" жеж. Но если T — вектор, к примеру, тады ой. _>Когда vector виден в коде явно — ещё можно на опыте среагировать на то, что {} может делать не то, что от него ожидал автор. А вот в шаблоне — уже нужно напрячься.
Ну да, это общая проблема использования инит-листов в конструкторах. Я с ней, бывало, сталкивался даже при проектировании собственных классов. С одной стороны, сделали универсальную инициализацию с фигурными скобочками, с другой подсунули эти инит-листы. Мне инит-листы с самого начала не нравились.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, rg45, Вы писали:
R>Я с ней, бывало, сталкивался даже при проектировании собственных классов.
У меня этот опыт тоже не академический, и мне не понравилось
R>Мне инит-листы с самого начала не нравились.
Да, кроме проблем с правильным выбором перегруженного конструктора, оно ж ещё и копии делает, что как бы не прям очевидно. В тестах штука удобная, в остальных местах обычно получается сделать через другие механизмы, без потери лаконичности и выразительности.
Здравствуйте, serg_joker, Вы писали:
R>>Я с ней, бывало, сталкивался даже при проектировании собственных классов. _>У меня этот опыт тоже не академический, и мне не понравилось
R>>Мне инит-листы с самого начала не нравились. _>Да, кроме проблем с правильным выбором перегруженного конструктора, оно ж ещё и копии делает, что как бы не прям очевидно. В тестах штука удобная, в остальных местах обычно получается сделать через другие механизмы, без потери лаконичности и выразительности.
Ну, кое-какой выход всё-же имеется. Сейчас инициализация с круглыми скобками обладает почти такой же полной силой, как и с фигурными, даже агрегатная инициализация работает. Отсекаются только инит-листы, что мне очень даже подходит. Так что, я в шаблонах использую почти везде круглые скобки. Исключением является только дефолтная инициализация, тут я использую фигурные скобки, чтоб компилер не воспринимал это как объявление функции.
--
Справедливость выше закона. А человечность выше справедливости.
Ты обсуждение читаешь вообще?
