Здравствуйте, CreatorCray, Вы писали:

MTD>>std::o[i]fstream
CC>Без обид, но я лично считаю пользующихся этим ужасом просто профнепригодными.
CC>std streams это один из самых лютых дизайнерских косяков.

Ой, да ладно, если просто как файл использовать (read/write(char*, size)), то все ок.

CC>Совсем ленивые просто напишут

Что-то не совсем ленивые.

CC>И передавай туда ваще что угодно, что совместимо по API

И сделай из IDE блокнот. Шаблоны — ок, но пихать их везде — лютый бред.

Здравствуйте, MTD, Вы писали:

MTD>Короче, мой месседж — С++ маргинализируется и становится убежищем фриков, на интересы инженеров там положили болт.

В Сиднее всё, что не веб, — маргинально. Либо нет денег (видеоигры), либо битва за каждую микросекунду задержек (hft). Сумасшедшие Религиозные фанатики продвигают свои фичи в язык, которым обычные прогеры давно не пользуются.

Здравствуйте, Ops, Вы писали:

P>>В этом случае я бы взял какую-нибудь проверенную временем фортрановскую библиотеку.
Ops>Зачем? Берем интеловскую IPPL, и вуаля.

В то время я с фортрановскими лучше знаком был. Кроме того, пришлось бы переписывать кучу других программ, сделанных старшими товарищами. Причем когда их начинали писать, я в детский сад ходил. Если вообще родился к тому времени.

Здравствуйте, CreatorCray, Вы писали:

MTD>>Например, в С++ передали вектор в функцию не по ссылке — получили тормоз.
CC>Ну да, С++ требует чтоб аффтар понимал что он делает.
CC>Передача по ссылке, по const & и по значению — это ж три кардинально разных use case.

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

Здравствуйте, turbocode, Вы писали:

T>1. Qt изначально был платным поэтому он пропустил время когда мог бы стать популярным.

Бесплатный Qt был всегда. Просто до нокии он был GPL, а теперь стал LGPL.

Здравствуйте, MTD, Вы писали:

CC>>Использую STL API compatible контейнеры, которые когда то пришлось написать сначала производительности ради, потом ещё и предсказуемости для.
MTD>Понял, да, есть ряд задач для которых STL не подходит.
Да не то чтоб не подходит, для специфических задач да, контейнеры специфические писать приходится, а для большинства применений и обычные нормально ложатся.
Но вот блин вышел парадокс: когда слазили с STL то написали regression performance tests и замену стандартным контейнерам по сути написали как бы алгоритмически неотличимо от STL с на глаз вроде как микроскопическими отличями, больше в стилистике кода чем в алгоритмах, но когда гоняли тесты то в довольно многих их них самописные контейнеры внезапно показали на ровном месте до пары-тройки десятков процентов прироста в скорости. Не сильно было тогда времени изучать как ж так вышло — работы было и так навалом а быстрее этож не медленнее.

Здравствуйте, MTD, Вы писали:

CC>>Да просто надо пользоваться платформенными и не морочить никому голову.
MTD>В 99% не надо.
В 100% надо не выделываться а пользоваться платформой.

CC>>Потому что генерализация всегда получается настолько кривая что без слёз не взглянешь
MTD>Вполне адекватная для большинства случаев, для исключений берешь нативный дескриптор и вперед.
Это для очень примитивного применения, когда похрен на всё, лишь бы прочитать.

CC>>Что с потоками что с файлами.
MTD>Хорошо, что в комитете еще есть практики, которые с тобой не согласны.
И кто же эти практики?

Здравствуйте, MTD, Вы писали:

MTD>Ой, да ладно, если просто как файл использовать (read/write(char*, size)), то все ок.
А накой тогда streams то?
Да и внутри там местами страшненько.

CC>>Совсем ленивые просто напишут
MTD>Что-то не совсем ленивые.
В смысле?

MTD>И сделай из IDE блокнот. Шаблоны — ок, но пихать их везде — лютый бред.
Поэтому typedef наше всио.

Здравствуйте, mrTwister, Вы писали:

T>Зачем говорить на русском, если можно придумывать свои собственные слова!

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

Здравствуйте, Pzz, Вы писали:

Pzz>В точке вызова не видно, передаешь ли ты по ссылке или по значению.
IDE покажет. Если не показывает — это не IDE, на помоечку.

Pzz> А если ты зовешь не просто функцию, а хитровывернутый выхлоп какого-нибудь навороченного темплейта
А это уже звоночек что орхетегтуро попахивает какашками. "Не делайте так!" (С)

Здравствуйте, CreatorCray, Вы писали:

Pzz>>В точке вызова не видно, передаешь ли ты по ссылке или по значению.
CC>IDE покажет. Если не показывает — это не IDE, на помоечку.

Хороший же это текст программы, что текстовым редактором не берется, а требует специального инструмента. Может, будем сразу AST редактировать в специализированной тулзе? Скорость компиляции должна заметно возрасти

Pzz>> А если ты зовешь не просто функцию, а хитровывернутый выхлоп какого-нибудь навороченного темплейта
CC>А это уже звоночек что орхетегтуро попахивает какашками. "Не делайте так!" (С)

Иногда приходится сталкиваться с тем, что до тебя понаписали. Или в библиотеке стороннего производителя...

Здравствуйте, kov_serg, Вы писали:

_>Главная совместимость которая ломается современными C++ компиляторами это невозможность работать на WinXP. Нахрена мне ваши фичи если после компиляции оно не будет запустится с криками это не windows приложение. Дело не конкретно winxp, скоро это будет и win7, дело в принципе. Что за мода на цифровое старенее.

Современный C++ здесь не при чём — от слова совсем.
Берем в MSVC — контекстное меню Properties проекта, там: Configuration Properties/General
далее — в строке Platform Toolset выбираем (из комбо-бокса), тулсет совместимый с WinXP.

_>Современные либы уже во всех вариантах и под все платформы и разные опции компиляции уже сейчас весят безбразно моного гигабайт.

Современные диски уже не превый год как могут хранить терабайты.
Время 40-мегабайтных русских AT — давно прошло.

Здравствуйте, Pzz, Вы писали:

Pzz>Хороший же это текст программы, что текстовым редактором не берется, а требует специального инструмента.
Не ну можешь конечно и камнем шурупы забивать. Но есть таки шуруповёрт с регулируемым усилием.
Зачем усложнять себе жизнь ненужными телодвижениями?

Pzz> Может, будем сразу AST редактировать в специализированной тулзе?
Если это будет наглядно и удобно для девелопера. Основная задача IDE помогать в первую очередь читать а во вторую уже писать код.

Pzz>Скорость компиляции должна заметно возрасти
Это довольно мало кого колышет. А вот навигация по коду — очень даже.

Здравствуйте, CreatorCray, Вы писали:

CC>В 100% надо не выделываться а пользоваться платформой.

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

MTD>>Хорошо, что в комитете еще есть практики, которые с тобой не согласны.
CC>И кто же эти практики?

Те которые, например, тредс таки протащили — огромное им спасибо. По именам не знаю.

T>>1. Qt изначально был платным поэтому он пропустил время когда мог бы стать популярным.
Pzz>Бесплатный Qt был всегда. Просто до нокии он был GPL, а теперь стал LGPL.

GPL не для коммерческого использования c закрытым кодом. Как в таком случае можно говорить о бесплатности, я не знаю.

MTD>Так я в самом начале написал как — через функцию, которая сравнивает без учета регистра.
То есть приводить строки к нижнему регистру по месту использования, даже если помногу раз для каждой строки. Ну, работать будет.

MTD>>>Во-вторых, ты не сможешь использовать методы которые принимают std::string.
M>>Метод стандартной библиотеки? Можно пример?
MTD>Слушай, ну если ты на С++ не пишешь, то зачем в тему влез? Любой конструктор от класса отнаследованного от std::exception, например, std::o[i]fstream
Есть перегрузка с const char* — так не интересно.

M>>Твой собственный метод? Ты автор — пиши метод так чтобы он принимал все что должен принимать.
MTD>Вот про это я в самом начале и писал — люди совершенно оторвавшиеся от реальности. Все же хотят вместо:
Ааа, так ты в принципе против шаблонов — с этого и надо было начинать.

Здравствуйте, Muxa, Вы писали:

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

1. Преждевременная оптимизация зло
2. Ты уверен, что умеешь писать быстрый код? Во-первых, ты не знал, что можно сравнивать хеши, что быстрее, чем сравнивать целиком строки. Во-вторых, сравнивать на больше меньше через простое сравнение тоже медленно.

M>Есть перегрузка с const char* — так не интересно.

А мне не интересно везде c_str писать, кроме того, есть в стандартной библиотеки методы без перегрузки, например конструктор std::random_device

MTD>>Вот про это я в самом начале и писал — люди совершенно оторвавшиеся от реальности. Все же хотят вместо:
M>Ааа, так ты в принципе против шаблонов — с этого и надо было начинать.

Это из каких слов ты понял, ткни пальцем.

Здравствуйте, CreatorCray, Вы писали:

MTD>>Нет, я хочу из коробки кроссплатформенно создать директорию. Это рокет сайнс?
CC>Ты не поверишь но для абстрактной платформы в вакууме — да!
CC>Кроссплатформ в этом плане страшное зло.

В абстрактной платформы может и директориев, как таковых, не быть. В конкретных практически значимых платформах есть либо mkdir(), либо CreateDirectory()

Здравствуйте, vdimas, Вы писали:

V>Наоборот, считай все более-менее серьёзные либы в этом направлении писаны на С/С++. Последние лет 10-15 почти всегда последнее.
V>На других языках наблюдается только бинд/обертки нейтивного плюсового кода.
V>Слово "стандартный" мог написать только человек, который не в теме наглухо.

С++ имеет одну очеь бедную стандартную библиотеку. И "N" других, не стандартных библиотек с "N" вариантами API. Это проблема.

V>Наоборот, только для плюсов есть всевозможные либы на абсолютно все востребованные направления. Ни для каких других языков такого набора готового функционала нет и не предвидится, ес-но.

Нет _стандартных_ и _удобных_ средств и библиотек, а так дооо — есть. Я же об этом прямо и сказал.

V>Без разбора конкретных не устраивающих АПИ популлярных библиотек подобные высказывания являются пустозвонством.

boost::log vs C# Log, qt declarative vs WPF(xaml), .Net DateTime vs любая плюсовая либа, чтобы покрыть библиотеку .Net коммуникации через интернет вообще нужен зоопарк с++ библиотек и их использование не будет настолько удобным как в шарпике, по части библиотек вообще сложно сранивать так как оно является частью C# языка и несоизмеримо удобнее библиотечных версий плюсов.
Вообще на всём подмножестве задач, которые покрывает шарпик — он по удобствую использования уделывает плюсы и в хвост и в гриву.

V>Конкретней, плиз. Есть огромный список драфтов для включения в будущие версии. Пройдись по ним и дай нам знать, что конкретно ты имел ввиду.

Да что ж конкретней? Ничего же нет, всё надо — и xml, и сеть, и базы, и IPC человеческое, и RPC, и сериализация, и GUI, .... — короче тупо всё надо.

V>Если ты про включение аудио в стандартную библиотеку, то, повторюсь, ты не в теме абсолютно.
V>Различные технологии аудио порой отличаются кардинально. Любая попытка привести всё к одному некоему "стандарту" — это будет вредная гиря на ногах для индустрии.

Ну ок. А проиграть mp3, остановить проигрывание, добавить эффект — это rocket science? Или раз мы не можем добавить всё — то хрен вам, вообще ничего не будет!?

V>И да, тебе-то, как разработчику, какая нафик разница, идёт ли библиотека, например Cubase ASIO или C++20 std::asio_audio?

Огромная, можно сказать фундаментальная. Я могу быть уверенным, что она есть, я могу на это закладываться.
Второе, мне не надо изучать API н-го количества библиотек, чтобы иметь возможность работать по данному направлению.

P>>ПС: но как-бы то ни было, альтернативы плюсам пока что не наблюдается, печалька
V>И этому есть весомые причины, не?

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

Как только появится язык, обладающий теми же характеристиками, но хоть с какой-то стандартной инфрастуртурой — плюсы не спасут ни количество сторонних библиотек, ни легаси. Будет второй COBOL.

Здравствуйте, kov_serg, Вы писали:

_>В C был такой синтаксис. Помоему гораздо приятнее чем в C++, где каждому аргументу надо писать тип. Да в коде меньше мусора.
_>

_>int add(x,y)
_>int x,y;
_>{
_>  int z;

_>  z=x+y;
_>  return z;
_>}
_>

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