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

[pu4koff]

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

Согласен на 40%. Вопрос в другом, разве то, что вы мешаете все подряд - это проблема языка?

Проблема языка в данном случае в том, что он не предоставляет необходимого минимума.
В шарпе есть ICollection, IList, IEnumerable,... которые покрывают основную часть коллекций и благодаря которым не приходится нигде строить непонятные конструкции. Сторонние библиотеки стыкуются отлично посредством интерфейсов. Если бы таких интерфейсов не было изначально в .NET, тогда был бы такой же зоопарк, как в плюсах.
В жабе ситуация примерно как в шарпе и она собственно должна быть такой в современном языке. В плюсах же реализация основных коллекций из коробки (в STL) есть, но нормально это всё не расширяется. Если мне нужно будет "изобрести" какую-то свою особую коллекцию, то так просто я её в код, заточенный под vector, не засуну. Нужно будет сначала собрать экземпляр вектора.

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

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

Совсем не обязательно это будет буст и кутя. Это может быть парсер, который работает с сишными/STL строками, а для GUI используется тот же Qt со своими строками. Это хорошо, если это будут "стандартные" строки (они будут преобразовываться неявно), а вот если это будет некий MyParserString, то ситуация будет не такой весёлой.

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

, написать native bridge, т.е. интерфейс на си или c++ чистом, через который будут общаться требуемые библиотеки. Не думаю что это можно назвать проблемой языка.

Можно то оно можно, но всё это вводит дополнительные трудности и усложняет код.
Тут конечно же оно каждому своё. Лично мне такая ситуация не по душе и, судя по вакансиям, не одному мне

[BOBAH13]

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

Проблема языка в данном случае в том, что он не предоставляет необходимого минимума.
В шарпе есть ICollection, IList, IEnumerable,... которые покрывают основную часть коллекций и благодаря которым не приходится нигде строить непонятные конструкции. Сторонние библиотеки стыкуются отлично посредством интерфейсов. Если бы таких интерфейсов не было изначально в .NET, тогда был бы такой же зоопарк, как в плюсах.
В жабе ситуация примерно как в шарпе и она собственно должна быть такой в современном языке. В плюсах же реализация основных коллекций из коробки (в STL) есть, но нормально это всё не расширяется. Если мне нужно будет "изобрести" какую-то свою особую коллекцию, то так просто я её в код, заточенный под vector, не засуну. Нужно будет сначала собрать экземпляр вектора.

Согласен.

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

Совсем не обязательно это будет буст и кутя. Это может быть парсер, который работает с сишными/STL строками, а для GUI используется тот же Qt со своими строками. Это хорошо, если это будут "стандартные" строки (они будут преобразовываться неявно), а вот если это будет некий MyParserString, то ситуация будет не такой весёлой.

Ну как вариант опять таки, выводить преобразование вашего собственного класса в обычный тот же char*/wchar_t*

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

Можно то оно можно, но всё это вводит дополнительные трудности и усложняет код.
Тут конечно же оно каждому своё. Лично мне такая ситуация не по душе и, судя по вакансиям, не одному мне

Ну в принципе верно, тут уже больше связано с областью применения, тот же Android (я с ним имею дело, хотя сам пока писал только на SDK без NDK), там весь верхний слой на Java, хотя можно в тех же играх для увеличения производительности использовать NDK -> C++. Но там думаю или он чистый и использует обвертки от NDK. Я хочу сказать, что тут думаю, кому уже как повезет. Главное что выход есть было бы плохо если бы выхода не было.

[the_deer_one]

BOBAH13

Ну как вариант опять таки, выводить преобразование вашего собственного класса в обычный тот же char*/wchar_t*

Так это и есть недостаток.

[BOBAH13]

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

BOBAH13

Так это и есть недостаток.

А я и не говорю, что это преимущество. Просто говорю, что есть выход раз так все закручено становится.

[Blade]

Проблемы использования нескольких сторонних библиотек в проекте возникают, потому что код этих библиотек расползается по всему проекту, и везде приходится делать всевозможные конвертации для различных библиотек. Так быть не должно. Использование каждый библиотеки (и любых не стандартных средств) должно быть локализовано в одном пакете, а в других местах должны работать собственные обертки\интерфейсы. То есть, если нам нужна QtGUI, мы не должны во всем проекте использовать сущности из Qt, мы должны написать интерфейс и использовать его. Это решает и другую очень важную проблему - если через год мы захотим использовать вместо Qt что-то другое, нам придется исправить только реализацию интерфейса, а не половину проекта

[An1ka]

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

Нет. Я серьезно. Считаю плюсы костылём над Си. За все годы существования он так и остался костылём. В стандарты языка вносят вроде бы всё новые и новые фишки, но многие более полезные вещи комитет принимать не хочет. Из-за непонятного развития языка люди изворачиваются как могут и создают всякие boost, Qt,... Итог: куча библиотек со своими классами строк, массивов и прочих типов данных, которые уже давно можно приписывать к базовым, подобно int, float,...

Каких типов, например ? И зачем ? STL без проблем работает со всеми типами ! Для строк есть класс std::string, всё остальное - ненужные велосипеды
Часть функций/классов из Boost перейдет в новый стандарт C++. Qt - это вообще для кросс платформенных разработок. C++ является одним из самых быстрых языков по времени исполнения кода(практически равно коду на ассемблере) и хочется, чтобы он таким и оставался, по-этому и комитет стандартизации только принимает быстрые и удобные решения, а всё остальное отсекается.

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

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

Чем отличается "сишный массив" от "несишного" ?

[Utkin]

Чем отличается "сишный массив" от "несишного" ?

Много чем. Например, паскалевские массивы организованы по-другому. Будете подключать длл и Вас приятно удивит вылет программы. Те же строки (массив символов) - у Дельфи сначала идет число символов, потом любые байты, при желании туда можно ноль запихнуть.

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

именно Сишные массивы и строки, есть дефакто стандарт(для кроссбиблиотечного обмена например), остальное по большей части внутреннее для ЯП.
теже строки в Делфи отлично преобразуются в сишные, причем на практике без реального изменения(копии), тоже и с массивами.
так же и std::vector(C++)!=array(delphi)

[pu4koff]

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

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

Это понятно и в любом случае не со строками, так с какой-то специфической структурой такая проблема появится, если писать "вермишель" вместо нормального кода. Только вот из-за банальных строк и массивов заморачиваться мне лично лень.

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

Каких типов, например ? И зачем ? STL без проблем работает со всеми типами !

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

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

Для строк есть класс std::string, всё остальное - ненужные велосипеды

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

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

Часть функций/классов из Boost перейдет в новый стандарт C++.

Сначала эти функции висят в пространстве boost, потом пару лет в tr1, а потом может быть перекочуют в std. Так?

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

Qt - это вообще для кросс платформенных разработок. C++ является одним из самых быстрых языков по времени исполнения кода(практически равно коду на ассемблере) и хочется, чтобы он таким и оставался, по-этому и комитет стандартизации только принимает быстрые и удобные решения, а всё остальное отсекается.

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

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

Чем отличается "сишный массив" от "несишного" ?

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

[MaTBeu]

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

Каких типов, например ? И зачем ? STL без проблем работает со всеми типами ! Для строк есть класс std::string, всё остальное - ненужные велосипеды
Часть функций/классов из Boost перейдет в новый стандарт C++. Qt - это вообще для кросс платформенных разработок.

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

Ну да Qt - только для кроссплатформенных разработок. Никак иначе его использовать нельзя.

C++ является одним из самых быстрых языков по времени исполнения кода(практически равно коду на ассемблере) и хочется, чтобы он таким и оставался, по-этому и комитет стандартизации только принимает быстрые и удобные решения, а всё остальное отсекается.

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

Чем отличается "сишный массив" от "несишного" ?

Пять баллов.

int a[10];

и

std::vector<int> a;

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

Чего только стоит библиотека ACE/TAO (кто работал, тот знает). Там вообще мрак.