Продолжение С++

[Utkin]

Сообщение от An1ka

Это новый стандарт c++0x. Вы можете оспаривать и считать C++ отстоем, но всё равно C++ будет развиваться и улучшаться, хотите вы этого или нет

Опять из крайности в крайность. Я нигде не говорил, что С++ отстой. Каждый язык имеет свое предназначение. Я хотел чтобы Вы трезво смотрели на вещи и не обожествляли С++. А да, это следующий уровень - сначала Вы видите только преимущества языка, потом уже учитесь пользоваться его недостатками.

У меня прекрасное представление, в отличаи от вас.И ресурсоемких программ критических ко времени исполнения. Дельфи к этому не относится !

Ну хорошо - критический код - загрузчик ОС . Нет на Дельфи такие вещи не пишут . Очень хотелось бы посмотреть код на С++.

А у меня есть ответ и он был дан. А вы боитесь признать очевидного !

Я уже дал ответ - хотите холивара создайте тему, не надо засорять текущую.

[Пепел Феникса]

Кому как. Но вопрос был о новых фишках ! И о развитии языка.

Делфи тоже развивается, как бы вы этого не отрицали.

[pproger]

2Пепел Феникса

Делфи тоже развивается, как бы вы этого не отрицали.

угу. но что-то большинство сидит на 7 делфе

[Пепел Феникса]

угу. но что-то большинство сидит на 7 делфе

у меня шестерка(правда не только), но я Делфи лично применяю только изза RAD, но не для серьезного.

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

[pproger]

2Пепел Феникса
ну и кому нужно это развитие, если пользователи предпочитают более старые версии?)

[pu4koff]

Сообщение от An1ka

При чем тут новички и C++ ? Новички на любом языке будут писать плохо и не оптимально. А вот, что касается C++ , то Бьерн Страуструп пишет, что C++ и разрабатывался как быстрый язык - замена ассемблеру, но настолько же быстр

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

Сообщение от An1ka

Это уже проблемы сторонних библиотек почему их разработчики не использовали std::list. Могли бы просто перегрузить свои функции, чтобы они работали и с std::vector и с std::list, а почему они этого не сделали это уже вопрос надо задавать им !

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

Сообщение от An1ka

Для удобства. Никто не заставляет ими пользоваться.

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

Сообщение от An1ka

Можно запоминать размер или использовать std::vector.

Можно. Про то, почему мне вектор не нравится, я уже писал. если бы был базовый абстрактный класс std::icollection, то претензий по этому поводу не было бы.

Сообщение от An1ka

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

То то ломают периодически программы через переполнение буфера.

[An1ka]

Сообщение от Utkin

Опять из крайности в крайность. Я нигде не говорил, что С++ отстой. Каждый язык имеет свое предназначение. Я хотел чтобы Вы трезво смотрели на вещи и не обожествляли С++. А да, это следующий уровень - сначала Вы видите только преимущества языка, потом уже учитесь пользоваться его недостатками.

Я вот тоже говорю о предназначении языка, а именно написания ресурсоемких задач, по-этому и комитет по стандартизации не сразу принимает кучу новых фишек, выбираются только достаточно быстрые и удобные решения, чтобы язык оставался достаточно быстрым по времени исполнения !
И каких еще недостатков ? В стандарте C++ нет недостатков, там всё строго ! Или может приведете примеры этих недостатков ? Да никто не обожествляет C++, просто C++ является самым лучшим ЯП для ресурсоемких задач на сегодняшний день - это факт

Сообщение от Utkin

Я уже дал ответ - хотите холивара создайте тему, не надо засорять текущую.

Вы сами начали. В теме по C++ дельфи никого не интерессует. Не мешайте нам любить C++ !

Сообщение от pu4koff

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

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

Сообщение от pu4koff

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

Обычно так и делается. В данном случае это только с виду дублирование, а на самом деле тип данных то разный. Шаблоны тоже дублируются в коде для каждого типа и ничего. Важно, чтобы быстро работала программа !

Сообщение от pu4koff

То то ломают периодически программы через переполнение буфера.

Любую программу на любом ЯП можно сломать

[Utkin]

Тема загрузчика ОС как критически важного кода так и не раскрыта .

И каких еще недостатков ? В стандарте C++ нет недостатков, там всё строго !

Он имеет свои недостатки, раскрывать их не буду, потому что это тоже выходит за рамки данной темы. Я уже устал писать Вам, если интересует именно направление разговора отличное от основной ветви - создавайте новую тему. Например, тема о любви (или не любови) к С++ .

Да никто не обожествляет C++, просто C++ является самым лучшим ЯП для ресурсоемких задач на сегодняшний день - это факт

Ваше предложение содержит взаимоисключающие параграфы.

В теме по C++ дельфи никого не интерессует.

Речь не о Дельфи, а о сравнении механизмов. Изначально было о сишных и не сишных массивах.

Шаблоны тоже дублируются в коде для каждого типа и ничего.

О, Аллах дай терпения! Для каждого типа данных генерируется своя версия кода. Речь о дублировании не идет.

[An1ka]

Сообщение от Utkin

Тема загрузчика ОС как критически важного кода так и не раскрыта .

А что вы хотите узнать ?

Сообщение от Utkin

Он имеет свои недостатки, раскрывать их не буду, потому что это тоже выходит за рамки данной темы. Я уже устал писать Вам, если интересует именно направление разговора отличное от основной ветви - создавайте новую тему. Например, тема о любви (или не любови) к С++ .

Так сами и создавайте ! Тут тема про C++ и его развитие ! А то, что вы не хотите рассказывать о якобы недостатках языка, то это и так ясно. Ведь просто не о чем !

Сообщение от Utkin

Ваше предложение содержит взаимоисключающие параграфы.

Признавать факты не значит обожествлять

Сообщение от Utkin

Речь не о Дельфи, а о сравнении механизмов. Изначально было о сишных и не сишных массивах.

Писать размер массива в первый элемент можно и на Си. В WinApi как раз используется такой метод.

Сообщение от Utkin

О, Аллах дай терпения! Для каждого типа данных генерируется своя версия кода. Речь о дублировании не идет.

Вот именно, своя версия кода для каждого типа будет всё равно !
Но std::vector и std::list очень разные типы организации данных, чтобы их можно было под одну гребенку... Например, если использовать std::vector, то при добавлении нового элемента для всех находящихся в нем будут вызываться деструкторы. Элементы там хранятся в виде массива, т.е. последовательно и при добавлении нового элемента, массив будет полностью пересоздан, обеспечивает быстрый доступ по индексу. А в std::list элементы хранятся в виде связного списка и при добавлении нового элемента предыдущие элементы пересоздаваться не будут. Совсем разная организация данных ! Если доступ по индексу не нужен, то во всех остальных случаях лучше использовать std::list, особенно, если много элементов и часто добавляются/удаляются.

[pu4koff]

Сообщение от An1ka

Вот именно, своя версия кода для каждого типа будет всё равно !

Версия кода, которую создаст компилятор, без участия программиста. А вот если я начну писать отдельно метод для vector, list, ..., тогда, в случае какого-либо изменения, мне нужно будет это повторить для всех этих методов, вручную, с высокой вероятностью попадания на "человеческий фактор".

Сообщение от An1ka

Например, если использовать std::vector, то при добавлении нового элемента для всех находящихся в нем будут вызываться деструкторы. Элементы там хранятся в виде массива, т.е. последовательно и при добавлении нового элемента, массив будет полностью пересоздан, обеспечивает быстрый доступ по индексу. А в std::list элементы хранятся в виде связного списка и при добавлении нового элемента предыдущие элементы пересоздаваться не будут. Совсем разная организация данных !

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

Сообщение от An1ka

Если доступ по индексу не нужен, то во всех остальных случаях лучше использовать std::list, особенно, если много элементов и часто добавляются/удаляются.

Это уже проблема программиста - выбирать подходящие классы для своей задачи. Только не того программиста, который библиотеку реализует, а того, что её использует. Иначе тут получится то же самое, что при проектировании планшетника учитывать, что кто-то может захотеть им гвозди заколачивать. А если вдруг кто-то его (планшетник) "убьёт" об гвоздь, то отсудит кучу денег у производителя, т.к. тот это не учёл.