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

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

У меня есть некий алгоритм, который работает с коллекцией неких данных. Этот алгоритм хорошо ложится на список list.

тут можно выкрутится через шаблонирование(+итераторы), хотя, я вот смотрю на эту таблицу(Member Map) ведь можно же было сделать какой-нить абстрактный класс им(vector,list,deque) с общими членами, чтобы не применять шаблоны.
хотя шаблоны выйдет чуть мощнее тут(ибо в шаблон можно будет пихнуть любой класс, имеющий требуемые члены), но так же и сложнее.

вообще да, у С++ есть недостатки.(много есть о чем говорить, как лучше, или тут плохо)

STL хорош, но вот в сторонних библиотеках его не используют.

вообще в С++ шаблоны стали отчасти кошмаром, ибо они стали заменой интерфейсов.
а изза шаблонов код порою растет только так...
(пример тот же, некий алгоритм, допустим код его большой и совместим со всеми тремя хранилищами STL, изза инстанцирования под три класс, код будет в три раза больше)

[the_deer_one]

А в руби вообще может в любой переменной любой тип быть. Можно хоть в одном массиве разные типы хранить. И никакой тебе мощи шаблонов. Мощь костылей - странно звучит. :D

[An1ka]

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

Ну это вообще отлично. Если код на С++ пишет человек с 20 годами опыта в нем, тогда да, он быстр. А если, извините, его пишет криворукий новичок с 2-3 годами опыта - тогда этот код разве что компилятору можно отдать. Другие люди его читать не смогут. А уж про быстродействие и речи не идет.

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

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

Пять баллов.

int a[10];

и

std::vector<int> a;

Это только стандартные. Есть еще всякие CMyFastArray, VeryStableVector и куча другого всякого в сторонних библиотеках.

Во втором случае - это класс динамического контейнера.

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

Я выше описывал проблемы. В STL всё это есть, но vector отдельно, а list - отдельно. Пример того, что мне не нравится:
У меня есть некий алгоритм, который работает с коллекцией неких данных. Этот алгоритм хорошо ложится на список list. Так же есть сторонняя библиотека, которая собственно выдаёт исходные данные. Только вот беда: она работает или с MyData* или с vector<MyData>. В итоге я должен сначала создать Си-шный массив или вектор, потом на основе этого создать уже list и тогда мой алгоритм сможет приступить к работе. Только вот для заполнения данных в коллекцию этой сторонней библиотеке без разницы должно быть куда я хочу помещать данные. Я хочу передать ей некий ICollection и пусть она его заполняет. А уже в конкретных местах под этим интерфейсом будет скрываться вектор, список или что будет удобнее в данный момент.

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

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

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

Есть std::wstring

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

Зачем тогда добавили "умные" указатели? Это же достаточно не рационально ни по памяти, ни по скорости. "Чистые" указатели куда производительнее.

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

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

Си-шный массив небезопасен. Он не хранит размер и уже от этого куча проблем может возникнуть. Поэтому обычно их заполнение выглядит так:
int fill_array(byte *arr, int size);
на входе получаем:
arr - выделенный кусок памяти под массив
size - количество элементов, под которое выделен массив
на выходе получаем количество заполненных элементов массива.
Хорошо - если это количество не равно параметру size.
Если же равно: просто так удачно совпало по числу элементов или же памяти выделенной не хватило?

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

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

А в руби вообще может в любой переменной любой тип быть. Можно хоть в одном массиве разные типы хранить. И никакой тебе мощи шаблонов. Мощь костылей - странно звучит. :D

А в C++ можно всё проконтролировать. Для разных типов схожие операции для них могут выполняться по-разному.

[Utkin]

то Бьерн Страуструп пишет, что C++ и разрабатывался как быстрый язык - замена ассемблеру, но настолько же быстр

Гы, пахнет холиваром. Паскаль не менее быстр. Просто не используйте стандартные модули и будет Вам счастье. Вообще скорость имеет весьма отдаленное отношение к языку программирования, это вопрос реализации языка.
Счас набежит сторонник Пуре Бейсика и скажет, что его скорость не уступает С++ и самое главное будет не далек от истины .

Есть std::wstring

Не знаю как это обстоит в Дельфи, но

В европейских и многобайтовых кодировках есть некоторые символы, такие как буквы с диакритическими знаками, чей код превышает 0x80. Так как в коде чаще всего используются символы со знаком, эти символы расширяются знаком после преобразования в тип int. При этом возникает проблема с индексацией массивов, так как символы, расширенные знаком, становятся отрицательными и выходят за пределы массива. Языки, использующие многобайтовые кодировки, например, японский язык, также уникальны. Так как символ может состоять из 1 или из 2 байт, следует всегда оперировать двумя байтами одновременно.

[An1ka]

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

Гы, пахнет холиваром. Паскаль не менее быстр. Просто не используйте стандартные модули и будет Вам счастье. Вообще скорость имеет весьма отдаленное отношение к языку программирования, это вопрос реализации языка.
Счас набежит сторонник Пуре Бейсика и скажет, что его скорость не уступает С++ и самое главное будет не далек от истины .

Заметьте, вы сами начинаете холивар в обсуждении про C++ влезая со своим паскалем ! А скорость имеет самое прямое отношение - всё самое ресурсоемкое и критическое ко времени исполнения пишется на Си/C++
Паскаль неперспективен. По мимо Дельфи разве есть еще среды разработки для паскаля ?

[Utkin]

всё самое ресурсоемкое и критическое ко времени исполнения пишется на C++

Пишется на С и ассемблере. И даже самое ресурсоемкое в С++ тоже пишется на ассемблере.

Заметьте, вы сами начинаете холивар в обсуждении про C++ влезая со своим паскалем !

Надо заметить, что моя точка зрения имеет право на существование. Но речь шла не о том. Удобство использование и скорость разные вещи. Ранее я написал почему.

По мимо Дельфи разве есть еще среды разработки для паскаля ?

1. Есть
2. Дельфи давно самостоятельный язык программирования. Я писал о языках программирования, а не о средах разработки.

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

Не знаю как это обстоит в Дельфи, но

и причем тут это?
wstring использует всегда широкие символы.
тот же WideString по сути.
в винде всегда 2 байта на символ(UCS2).
в лине все 4(UCS4 помоему это называлось, или же UTF32)
iconv например оперирует через 4-байтные строки.

всё самое ресурсоемкое и критическое ко времени исполнения пишется на Си/C++

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

[Utkin]

Так как символ может состоять из 1 или из 2 байт, следует всегда оперировать двумя байтами одновременно.

в винде всегда 2 байта на символ(UCS2).

Наверно я что-то не так понял...

[pproger]

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

в лине все 4(UCS4 помоему это называлось, или же UTF32)

как локаль настроишь. обычно utf-8 используют

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

Наверно я что-то не так понял...

насчет того сколько занимает символ, зависит от кодировки. в UCS2 символ, всегда занимает 2 байта.

как локаль настроишь. обычно utf-8 используют

я именно про wchar_t и соответственно wstring.
а так знаю что там utf8 обычно.