У вас не получилось донести свою мысль (если таковая вообще была).
Можно предположить, что вы недовольны тем, что после появления STL разработчики на C++ стали активно использовать шаблоны. Возможно вы про это.
Ну так у меня для вас плохие новости. Шаблоны в C++ появились еще до появления STL, и начали широко использоваться (насколько это допускали тогдашние компиляторы) еще до того, как STL вошла в стандарт C++. И даже до того, как этот самый стандарт C++ был принят.
Хотите про объективную реальность и ощущения - давайте.
Про ощущения: есть у меня сомнения в вашем психологическом здоровье (в медицинском смысле), но их высказывание на таком ресурсе, как Хабр, приведет разве что к заминусовыванию кармы, так что оставлю их при себе.
Заодно и про логику
Про реальность: вы не можете в логику, что прекрасно видно по тексту вашего комментария.
Соответственно: оставить здесь комментарий чтобы пнуть вас в ваше очередное заблуждение -- это еще куда ни шло. А вот пытаться вам что-то объяснить... Ну уж нет. Не за бесплатно. Да и за деньги вряд.
Те, которые являются единицами диспетчеризации в многозадачных ОС с поддержкой вытесняющей многозадачности, и на CPU с несколькими вычислительными ядрами -- да. Это как бы объективная реальность данная нам в ощущениях.
Я предлагаю сравнить инструменты доступные Микеланджело и современному профессиональному художнику.
Это у тех, кто пишет маслом по холсту? Ну сравните. Интересно какой прогресс в кистях и палитрах вы обнаружите. Хотя химический состав красок, наверняка, далеко ушел вперед.
Скорее народная мудрость.
Какая именно?
Так и вы пришли учить Java-ов сейчас )
И тут бы ссылку на мои слова о том, где я бы говорил хоть что-то о том, как следует программировать на Java.
достаточно посмотреть на инструменты разработки которые большинство использует.
Т.е. вы предлагаете об уровне работ Микеланджело или Рафаэля судить по их кистям и палитрам? O_o
Я опросы не проводил. Но 99% стандартное правило.
Опросы не проводили, но выводы делаете. Отлично.
Про 99% -- это какое такое правило?
У меня опыт С++ тогда тоже был.
Но пришли учить C++ников программировать сейчас.
Высказал свои мысли
Ваш первый комментарий не похож на мысли, он поход на утверждение. Которое было бы желательно чем-то подтвердить. Однако, пока что все идет к тому, что ваши слова это обычный интернетовский бла-бла-бла.
Доказываю делами - опубликованными проектами.
Которые не в опенсорсе и на которые ссылки искать лень. Понятно.
О как... Мне иногда кажется, что современным говнокодерам до программистов из 90-х никогда не дорасти, но я из своей крошечной выборки никаких выводов не делаю. А вы, надо полагать, лично знакомы с кодом большинства программистов, отсюда и такие глобальные выводы.
Зачем, мне грубо говоря метать бисер перед свиньями?
Т.е. вы один здесь такой в белом пОльто стоите красивый?
Здесь бы я вернул ваши аргументы, зачем вы лезете туда, где у вас нет опыта работы?
Как раз опыт работы на Java у меня был.
В моём IoC фреймворке используется, но он ещё не в опенсорц. Ссылку искать лень.
Да, с аргументацией у вас как-то совсем слабенько. Предлагаете просто верить вам на слово?
Не помню такого. Достаточно было написать самому пару-тройку тысяч строк на ассемблере, чтобы захотеть программировать на чем угодно, только бы уровнем повыше.
Подобные аргументы были когда в массы стало проникать ООП. И, что характерно, подобные аргументы до сих пор применяются. Только вот делают это люди, которые специализируются на специфических областях, вроде вычислительной математики или разработки под совсем уж дохлый embedded (где на все про все пара-тройка килобайт в наличии). Причем, что характерно, зачастую они правы, т.к. в их областях выигрыша от того же ООП нет.
Но пришли рассказать как нужно программировать на C++? Ну OK, давайте, я с интересом послушаю. А может и не я один.
но на Java и других подобных ЯП сегодня такой код данность.
Так та же Java была убога в плане освобождения ресурсов с самого рождения. Тамошний finally есть ни что иное, как С-шный goto err, только присыпанный синтаксическим сахаром. Ну и спустя полтора десятка лет траха и собирания граблей вам дали try-with-resources скоммунизженный их C#-овского using. Так себе история успеха. Не удивительно, что приходится изобретать лисапеды.
Кстати, а можно ссылку на код, в котором вот эти вот with-ы используются в полный рост?
И лаконичность кода сегодня важна.
Этот тезис нуждается в доказательстве.
Конечно если только вы не выжимаете наносекунды на критичном участке рантайма.
В наше время не смысла применять C++ если скорость и/или предсказуемость не важны. Когда не важны люди берут ту же Java, а когда не важны совсем -- и Python с JavaScript-ом.
Но когда скорость и ресурсоемкость важны, то лаконичность, за которой прячется неявные new/delete, std::async-и с std::future и пр., однозначным достоинством уже не является. Как и лаконичность, основанная на пятиэтажных шаблонах, с сообщениями об ошибках на 800 строк и internal compiler error когда в одной единице трансляции заиспользовали пару навороченных шаблонных библиотек.
Легкость понимания, имхо, все-таки важнее легкости чтения. А код, который легко читается, не обязательно будет легким в понимании (хотя это два очень сильно связанных с друг с другом параметра). Проблема со всякими then, when, or_else, with, process и пр. в том, что слишком многое может быть (может быть, это тоже далеко не всегда так) упрятано под капот. И если хочется понять, а что же вся эта красота скрывает (есть ли там какие-то аллокации, переключения контекста и пр.), то может потребоваться не только прочитать кусок прикладного кода, но и еще больший кусок вспомогательного.
Я тут с вами поделился своей болью своим опытом. Когда пишешь код сам, то кажется, что continue -- это норм, ничего сложного. Когда въезжаешь в чужой, то оказывается, что все рекомендации про единую точку выхода, про отсутствие в теле цикла continue/break, про нежелательность goto -- это все как устав, написанный кровью :( В том числе и твоей собственной ;)
И здесь "лесенка вправо" прямо говорит о том, что последующие действия (т.е. DoSmth, DoAnother, AnotherFunc) выполняются только при срабатывании предшествующих условий. При этом в сами условия без необходимости можно не вглядываться.
Тогда как continue разбивает нормальную логику и глядя на тело цикла нужно напрягаться чтобы понять, когда мы дойдем до AnotherFunc и как это все будет связано с предшествующими действиями.
В общем, если вам придется приводить в чувства чужой (т.е. написанный не вами) код, да еще и в предметной области, с которой вы мало знакомы, то continue в циклах доставят сам незабываемых эмоций.
Языка C/C++ не существует. Если вы рассуждаете сразу о C/C++, то, вероятно, толком не знаете ни того, ни другого.
Во-вторых, далеко не все имеет смысл оборачивать в классы и объекты (это тоже накладные расходы). В-третьих, чтобы все это работало, требуется куча плясок с бубном типа автоматического вызова деструктора при выходе объекта из области видимости, порядка вызова деструкторов для набора объектов и т.п.
Матчасть подтяните. Есть ощущение, что отстали лет на 20.
И вот прямо в пространстве имен
std::?Что-то мне подсказывает, что это вряд ли была распространенная практика.
И еще больше подозрений, что внезапно замолчавший @mmMike имел в виду именно такие случаи.
Вы пришли на публичную площадку и высказались так, что вас оказалось непросто понять. Например (лишнее поскипано):
Что такое "STL класс"?
STL -- это standard template library. Как кто-то может взять и определить класс из standard template library?
У вас пытаются выяснить что вы имеете в виду, вы не можете ничего внятного ответить. Выяснить же пытаются для того, чтобы понять что вы сказали.
Если вам пофиг на то, что ваши же слова пытаются воспринять всерьез, то OK.
У вас не получилось донести свою мысль (если таковая вообще была).
Можно предположить, что вы недовольны тем, что после появления STL разработчики на C++ стали активно использовать шаблоны. Возможно вы про это.
Ну так у меня для вас плохие новости. Шаблоны в C++ появились еще до появления STL, и начали широко использоваться (насколько это допускали тогдашние компиляторы) еще до того, как STL вошла в стандарт C++. И даже до того, как этот самый стандарт C++ был принят.
Так а при чем здесь STL вообще?
Про ощущения: есть у меня сомнения в вашем психологическом здоровье (в медицинском смысле), но их высказывание на таком ресурсе, как Хабр, приведет разве что к заминусовыванию кармы, так что оставлю их при себе.
Про реальность: вы не можете в логику, что прекрасно видно по тексту вашего комментария.
Соответственно: оставить здесь комментарий чтобы пнуть вас в ваше очередное заблуждение -- это еще куда ни шло. А вот пытаться вам что-то объяснить... Ну уж нет. Не за бесплатно. Да и за деньги вряд.
Некоторые даже пытались общаться с автором. Чтобы сделать вывод, что лучше впредь таких ошибок не повторять.
Те, которые являются единицами диспетчеризации в многозадачных ОС с поддержкой вытесняющей многозадачности, и на CPU с несколькими вычислительными ядрами -- да. Это как бы объективная реальность данная нам в ощущениях.
Это у тех, кто пишет маслом по холсту? Ну сравните. Интересно какой прогресс в кистях и палитрах вы обнаружите. Хотя химический состав красок, наверняка, далеко ушел вперед.
Какая именно?
И тут бы ссылку на мои слова о том, где я бы говорил хоть что-то о том, как следует программировать на Java.
Т.е. вы предлагаете об уровне работ Микеланджело или Рафаэля судить по их кистям и палитрам? O_o
Опросы не проводили, но выводы делаете. Отлично.
Про 99% -- это какое такое правило?
Но пришли учить C++ников программировать сейчас.
Ваш первый комментарий не похож на мысли, он поход на утверждение. Которое было бы желательно чем-то подтвердить. Однако, пока что все идет к тому, что ваши слова это обычный интернетовский бла-бла-бла.
Которые не в опенсорсе и на которые ссылки искать лень. Понятно.
О как... Мне иногда кажется, что современным говнокодерам до программистов из 90-х никогда не дорасти, но я из своей крошечной выборки никаких выводов не делаю. А вы, надо полагать, лично знакомы с кодом большинства программистов, отсюда и такие глобальные выводы.
Т.е. вы один здесь такой в белом пОльто стоите красивый?
Как раз опыт работы на Java у меня был.
Да, с аргументацией у вас как-то совсем слабенько. Предлагаете просто верить вам на слово?
Не помню такого. Достаточно было написать самому пару-тройку тысяч строк на ассемблере, чтобы захотеть программировать на чем угодно, только бы уровнем повыше.
Подобные аргументы были когда в массы стало проникать ООП. И, что характерно, подобные аргументы до сих пор применяются. Только вот делают это люди, которые специализируются на специфических областях, вроде вычислительной математики или разработки под совсем уж дохлый embedded (где на все про все пара-тройка килобайт в наличии). Причем, что характерно, зачастую они правы, т.к. в их областях выигрыша от того же ООП нет.
Но пришли рассказать как нужно программировать на C++? Ну OK, давайте, я с интересом послушаю. А может и не я один.
Так та же Java была убога в плане освобождения ресурсов с самого рождения. Тамошний finally есть ни что иное, как С-шный goto err, только присыпанный синтаксическим сахаром. Ну и спустя полтора десятка лет траха и собирания граблей вам дали try-with-resources скоммунизженный их C#-овского using. Так себе история успеха. Не удивительно, что приходится изобретать лисапеды.
Кстати, а можно ссылку на код, в котором вот эти вот with-ы используются в полный рост?
Этот тезис нуждается в доказательстве.
В наше время не смысла применять C++ если скорость и/или предсказуемость не важны. Когда не важны люди берут ту же Java, а когда не важны совсем -- и Python с JavaScript-ом.
Но когда скорость и ресурсоемкость важны, то лаконичность, за которой прячется неявные new/delete, std::async-и с std::future и пр., однозначным достоинством уже не является. Как и лаконичность, основанная на пятиэтажных шаблонах, с сообщениями об ошибках на 800 строк и internal compiler error когда в одной единице трансляции заиспользовали пару навороченных шаблонных библиотек.
По-моему, мы сейчас оба говорим банальности.
Своим комментарием я хотел сказать, что понимаю и поинт @firehacker, и поинт @Foror. А дьявол, как всегда, будет в деталях (продолжаю банальности).
Легкость понимания, имхо, все-таки важнее легкости чтения. А код, который легко читается, не обязательно будет легким в понимании (хотя это два очень сильно связанных с друг с другом параметра). Проблема со всякими then, when, or_else, with, process и пр. в том, что слишком многое может быть (может быть, это тоже далеко не всегда так) упрятано под капот. И если хочется понять, а что же вся эта красота скрывает (есть ли там какие-то аллокации, переключения контекста и пр.), то может потребоваться не только прочитать кусок прикладного кода, но и еще больший кусок вспомогательного.
Простите мне мой неприкрытый сарказм, но предыдущая статья автора называлась ни много, ни мало, а "Все секреты многопоточности"
Я тут с вами поделился
своей больюсвоим опытом. Когда пишешь код сам, то кажется, что continue -- это норм, ничего сложного. Когда въезжаешь в чужой, то оказывается, что все рекомендации про единую точку выхода, про отсутствие в теле цикла continue/break, про нежелательность goto -- это все как устав, написанный кровью :(В том числе и твоей собственной ;)
Скажите, а вы о выходе C++11 с лямбдами что-нибудь слышали? Ну хотя бы в общих чертах?
Так ведь дело не в for. Дело в continue.
Ваш for и без continue можно переписать:
И здесь "лесенка вправо" прямо говорит о том, что последующие действия (т.е. DoSmth, DoAnother, AnotherFunc) выполняются только при срабатывании предшествующих условий. При этом в сами условия без необходимости можно не вглядываться.
Тогда как continue разбивает нормальную логику и глядя на тело цикла нужно напрягаться чтобы понять, когда мы дойдем до AnotherFunc и как это все будет связано с предшествующими действиями.
В общем, если вам придется приводить в чувства чужой (т.е. написанный не вами) код, да еще и в предметной области, с которой вы мало знакомы, то continue в циклах доставят сам незабываемых эмоций.
Во-первых, я ничего не говорил про C.
Языка C/C++ не существует. Если вы рассуждаете сразу о C/C++, то, вероятно, толком не знаете ни того, ни другого.
Матчасть подтяните. Есть ощущение, что отстали лет на 20.
Языка C/C++ не существует.
А в C++ есть деструкторы, которые позволяют вам делать то, что нужно перед выходом вне зависимости от причины выхода. Например.