В ветках С++ тоска — изредка правда встречаются фрики, которые не имея опыта пилят странные велосипеды, что доставляет массу веселья, да 3 с половиной опытных плюсовиков немножко оторвавшихся от реальности. О подобных персонажах и тенденциях развития С++ и хочется поговорить. Вообще С++ классный язык появившийся в нужное время, который покрыл потребности инженеров — тот-же С, но с классами и шаблонами. И если классы и виртуальные функции на С еще можно самому написать, пусть и ценой излишних усилий, то аналогов шаблонам там нет. И все было класно, но потом в комьюнити пролезли фрики оторванные от реальности и стали пилить чудовишную дичь под названием Boost: в разы замедлившаяся компиляция, километры невнятных ошибок, быстродействие даже не на уровне Питона, а в 3 раза хуже (пруф: http://rsdn.org/forum/flame.comp/6943929.1
Дальше было хуже, из своей резервации они пролезли в комитет, да спасибо друзья за смартпоинтеры и пару других удобных вещей, но то что вы делаете сейчас просто ни в какие ворота! Внимание, на дворе 2017 год, а в языке нет юникодных строк, нет файловых операций, нет модульности и корутин, зато с азартом обсуждаются новые фичи метапрограммирования. Блин, дорогие ученые, да я рад за вас, пилите, если вам это нужно, но не в ущерб же интересам инженеров на которых был положен болт.
Посмотрев любой мастер класс по плюсам уже через пять минут ловишь себя на мысли — да все упоролись, то что на других языках делается не задумываясь тут предмет для получасового обсуждения. Вот не самый упоротый случай:
Чувак на полном серьезе рассказыват, что вместо того чтобы пилить класс строк для того чтобы сравнивать строки независимо от регистра, можно написать класс-свойство, который передать в шаблон стандартной строки и который будет переводить строки в нижний регистр перед тем как положить в память, ну и потом можно эти строки сравнивать. Друг, ты совсем что-ли? Может лучше просто написать функцию (а лучше чтобы она была в стандартной библиотеке) compareCaseInsensitivity? Это и проще и в коде сразу понятно, что происходит
Короче, мой месседж — С++ маргинализируется и становится убежищем фриков, на интересы инженеров там положили болт.
“Внутри С++ сидит более компактный и понятный язык, отчаянно пытающийся выбраться наружу.” — Бьерн Страуструп
Здравствуйте, MTD, Вы писали:
MTD> В ветках С++ тоска — изредка правда встречаются фрики, которые не имея опыта пилят странные велосипеды, что доставляет массу веселья, да 3 с половиной опытных плюсовиков немножко оторвавшихся от реальности.
MTD>Чувак на полном серьезе рассказыват, что вместо того чтобы пилить класс строк для того чтобы сравнивать строки независимо от регистра, можно написать класс-свойство, который передать в шаблон стандартной строки и который будет переводить строки в нижний регистр перед тем как положить в память, ну и потом можно эти строки сравнивать. Друг, ты совсем что-ли? Может лучше просто написать функцию (а лучше чтобы она была в стандартной библиотеке) compareCaseInsensitivity? Это и проще и в коде сразу понятно, что происходит
Видео не смотрел, но пример более чем показателен.
Если строка например изначально в верхнем регистре, а потом будет сравниваться 100 раз, то будешь делать фактически 100 раз приведение к нижнему регистру. А если это национальный алфавит и прочие умляуты, где приведение в нижний регистр дорого?
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>А альтернативы всё равно нет.
Ну как сказать. Надо смотреть на предметную область. Например, сервера писать меня Go впечатлил — код пишется раз в 5-10 быстрее, чем на С++, по производительности одинаково. Конечно, на плюсах можно на голом epoll поднатужится и чуть обойти, но времени на разработку тогда уйдет раз в 20 больше.
Ниша для С++ конечно есть и будет еще очень долго, уверен, мне до пенсии на хлеб с икрой хватит, но речь про то, что люди в С++ задающие развитие сейчас малость оторвались от реальности.
Здравствуйте, MShura, Вы писали:
MS>Видео не смотрел, но пример более чем показателен. MS>Если строка например изначально в верхнем регистре, а потом будет сравниваться 100 раз, то будешь делать фактически 100 раз приведение к нижнему регистру. А если это национальный алфавит и прочие умляуты, где приведение в нижний регистр дорого?
Про преждевременную пессимизацию не писал только ленивый. Сначала надо написать понятно и чтобы работало правильно, потом по необходимости начинать оптимизировать. Вот ты привел пример с быстродействием и мимо, например, почему ты не предложил сравнивать хеши?
Здравствуйте, rudzuk, Вы писали:
R>Твоя попаболь доставляет куда сильнее.
Тем не менее моя боль позволяет общаться конструктивно, то есть приводить аргументы, а тебе, Nuzhny и кто там еще сейчас набежит только страдать и остается.
MTD>“Внутри С++ сидит более компактный и понятный язык, отчаянно пытающийся выбраться наружу.” — Бьерн Страуструп
MTD>Увы, его отчаянные попытки тщетны.
Я слышал, что планируется создание некоего "C++ lite" — простого подмножества. Было бы круто. А всё остальное, не вошедшее в это подмножество, надо смыть в унитаз
Здравствуйте, MTD, Вы писали:
R>>Твоя попаболь доставляет куда сильнее. MTD>Тем не менее моя боль позволяет общаться конструктивно, то есть приводить аргументы, а тебе, Nuzhny и кто там еще сейчас набежит только страдать и остается.
Ну-ну, обиделся за минус? Ты начал тему в соответствующем разделе и пообещал угар. А вместо этого плач Ярославны. У кого боль-то?
Я пишу на связке Питон + С++, никаких проблем не испытываю. И в С++ последнем мне всего хватает. А чего не хватает, то на OpenCL переписываю. Так что мне все твои больные темы намного менее интересны того, чем занимается комитет сейчас. Даже так: С++ наоборот начал поворачиваться ко мне лицом не только благодаря метапрограммированию. Ещё специальные математические функции в стандарт добавил, тот же clamp появился и т.п.
Здравствуйте, MTD, Вы писали:
MTD>Ну как сказать. Надо смотреть на предметную область. Например, сервера писать меня Go впечатлил — код пишется раз в 5-10 быстрее, чем на С++, по производительности одинаково. Конечно, на плюсах можно на голом epoll поднатужится и чуть обойти, но времени на разработку тогда уйдет раз в 20 больше.
Если посмотреть strace'ом, чем там программа на Go занимается, то можно с изумлением увидеть, что унутре нее тот же epoll (и completion port на венде, причем из тех же исходников).
Но вот что в этом Go мне в плане производительности действительно не нравится, это то, что библиотека евонная так и норовит на каждый чих чего-нибудь маленькое зааллоцировать в куче, а сборщику мусора потом подбирать.
Здравствуйте, Nuzhny, Вы писали:
R>>>Твоя попаболь доставляет куда сильнее. MTD>>Тем не менее моя боль позволяет общаться конструктивно, то есть приводить аргументы, а тебе, Nuzhny и кто там еще сейчас набежит только страдать и остается.
N>Ну-ну, обиделся за минус?
И в чем ты увидел проявление обиды? Ткни пальцем пожалуйста.
N>Ты начал тему в соответствующем разделе и пообещал угар. А вместо этого плач Ярославны. У кого боль-то?
Ты бы читал, прежде чем писать — да у меня боль. Я в ответе rudzuk этого не отрицал. С выяснением этого закончили?
N>Я пишу на связке Питон + С++, никаких проблем не испытываю.
Рад за тебя. А меня не устраивает, что на каждом более-менее крупном проекте гора своих велосипедов, например в одной компании где я работал было 5 классов-строк и два для работы с датой и временем. Мне бы хотелось, чтобы наконец в стандарте появились адекватные средства для этого. Ты против?
N>Так что мне все твои больные темы намного менее интересны того, чем занимается комитет сейчас.
У тебя все хорошо, непонятно тогда отчего ты так разволновался?
Здравствуйте, MTD, Вы писали:
N>>Ну-ну, обиделся за минус? MTD>И в чем ты увидел проявление обиды? Ткни пальцем пожалуйста.
В том что диагностировал у меня какую-то боль.
MTD>Рад за тебя. А меня не устраивает, что на каждом более-менее крупном проекте гора своих велосипедов, например в одной компании где я работал было 5 классов-строк и два для работы с датой и временем. Мне бы хотелось, чтобы наконец в стандарте появились адекватные средства для этого. Ты против?
Нет, не против. Я спрашиваю, почему ты оффтопишь!
MTD>У тебя все хорошо, непонятно тогда отчего ты так разволновался?
Потому что, снимая майку у девушки, я ожидаю там увидеть сиськи. Если их нет, то волнуюсь. Также и в твоей теме.
Здравствуйте, Pzz, Вы писали:
Pzz>Если посмотреть strace'ом, чем там программа на Go занимается, то можно с изумлением увидеть, что унутре нее тот же epoll
Поразительно, кто бы мог подумать.
Pzz>Но вот что в этом Go мне в плане производительности действительно не нравится, это то, что библиотека евонная так и норовит на каждый чих чего-нибудь маленькое зааллоцировать в куче, а сборщику мусора потом подбирать.
Будто STL не такая. Те же аллокации на каждый чих, например, возможность перевести число в строку в выделенный буфер только в С++17 добавили. Мапе дать буфер и сказать его использовать из коробке тоже нельзя.
Здравствуйте, MTD, Вы писали:
MTD>Короче, мой месседж — С++ маргинализируется и становится убежищем фриков, на интересы инженеров там положили болт.
Просто для С++ почему-то не нашлось корпорации, которая бы родила к нему простой, но обширный рантайм.
Кто писал на Qt меня поймут — там есть всё, что нужно обыкновенному программисту для обыкновенных задач.
И опнсорса развитого на С++ нет — все велосипедят сами как умеют.
Здравствуйте, scf, Вы писали:
scf>Кто писал на Qt меня поймут — там есть всё, что нужно обыкновенному программисту для обыкновенных задач.
Кстати да, очень удобный фреймворк. Мне доводилось писать на разных железках, на некоторых были старые компиляторы в которых не было части стандартной библиотеки и Boost там не собирался, но Qt работал вообще везде и сразу из коробки ты получал все, что нужно для работы. Неудивительно, что столько фриков от труЪ С++ Qt ненавидят — ведь там можно просто сесть и писать код решающий конкретную задачу.
Здравствуйте, Nuzhny, Вы писали:
N>>>Ну-ну, обиделся за минус? MTD>>И в чем ты увидел проявление обиды? Ткни пальцем пожалуйста.
N>В том что диагностировал у меня какую-то боль.
Не приписывай себе чужие заслуги — это rudzuk диагностировал, а я не стал отрицать. Так что незачет.
MTD>>Рад за тебя. А меня не устраивает, что на каждом более-менее крупном проекте гора своих велосипедов, например в одной компании где я работал было 5 классов-строк и два для работы с датой и временем. Мне бы хотелось, чтобы наконец в стандарте появились адекватные средства для этого. Ты против?
N>Нет, не против. Я спрашиваю, почему ты оффтопишь!
Выражайся понятней.
MTD>>У тебя все хорошо, непонятно тогда отчего ты так разволновался?
N>Потому что, снимая майку у девушки, я ожидаю там увидеть сиськи. Если их нет, то волнуюсь. Также и в твоей теме.
Ты про то, что угара нет? А по моему есть, в 3 раза слить Питону — это надо постараться.
Здравствуйте, MTD, Вы писали:
Pzz>>Если посмотреть strace'ом, чем там программа на Go занимается, то можно с изумлением увидеть, что унутре нее тот же epoll
MTD>Поразительно, кто бы мог подумать.
Это даже в инструкции где-то написано, но пальцем не покажу.
Pzz>>Но вот что в этом Go мне в плане производительности действительно не нравится, это то, что библиотека евонная так и норовит на каждый чих чего-нибудь маленькое зааллоцировать в куче, а сборщику мусора потом подбирать.
MTD>Будто STL не такая. Те же аллокации на каждый чих, например, возможность перевести число в строку в выделенный буфер только в С++17 добавили. Мапе дать буфер и сказать его использовать из коробке тоже нельзя.
У Go, в силу того, что там не возбраняется завести локальную переменную, передать ее адрес куда-нибудь, где его сохранят, и выйти из процедуры, всякое заведение локальной переменной является потенциальной аллокацией из кучи. Компилятор пытается угадать про каждую переменную, переживет ли она выход из области видимости, где она определена, или не переживет. И в зависимости от этого заводит ее либо в стеке, либо в куче. Это называется escape analysis. А поскольку компилятор у Go, в плане кодогенерации, доволько игрушечный, то правильно угадывает он не всегда.
Скажем, простой вызов recvfrom аллоцирует буфер для сетевого адреса раза три на пакет, в разных форматах. И все промежуточные становятся добычей сборщика мусора. Когда у него дотуда руки дойдут...
Кстати, в Go судьба куска памяти, в котором живет переменная, мало зависит от того, выделели его через new, или объявили локальную переменную. Выделение через new может быть уоптимизировано в создание переменной на стеке, а объявление локальной переменной может превратиться в аллокацию из кучи.
Здравствуйте, MTD, Вы писали:
MTD>В ветках С++ тоска — изредка правда встречаются фрики, которые не имея опыта пилят странные велосипеды, что доставляет массу веселья, да 3 с половиной опытных плюсовиков немножко оторвавшихся от реальности. О подобных персонажах и тенденциях развития С++ и хочется поговорить. Вообще С++ классный язык появившийся в нужное время, который покрыл потребности инженеров — тот-же С, но с классами и шаблонами. И если классы и виртуальные функции на С еще можно самому написать, пусть и ценой излишних усилий, то аналогов шаблонам там нет. И все было класно, но потом в комьюнити пролезли фрики оторванные от реальности и стали пилить чудовишную дичь под названием Boost
На самом деле: Boost классная вещица!
Использовать boost в своих наработках приятно.
MTD>Дальше было хуже, из своей резервации они пролезли в комитет, да спасибо друзья за смартпоинтеры и пару других удобных вещей, но то что вы делаете сейчас просто ни в какие ворота! Внимание, на дворе 2017 год, а в языке нет юникодных строк, нет файловых операций, нет модульности и корутин, зато с азартом обсуждаются новые фичи метапрограммирования. Блин, дорогие ученые, да я рад за вас, пилите, если вам это нужно, но не в ущерб же интересам инженеров на которых был положен болт.
Зачем это всё,когда есть библиотеки?
К чему всё это тащить именно в ЯП?
MTD>Посмотрев любой мастер класс по плюсам уже через пять минут ловишь себя на мысли — да все упоролись, то что на других языках делается не задумываясь тут предмет для получасового обсуждения. Вот не самый упоротый случай:
...так ведь у каждого — свои мозги, правда в приведенном видео ИМХО ими так и не воспользовались...
MTD>Короче, мой месседж — С++ маргинализируется и становится убежищем фриков, на интересы инженеров там положили болт.
Что такое интересы инженеров? Можно посмотреть примеры именно инженерных интересов?
Вот чем таким инженерные интересы в разработке ПО отличаются, ну скажем от интересов врачей, бухгалтеров, диспетчеров?
MTD>
MTD>“Внутри С++ сидит более компактный и понятный язык, отчаянно пытающийся выбраться наружу.” — Бьерн Страуструп
А разве новые стандарты (от C++11 и позднее) не сделали C++ компактнее и ближе к запросам разработчиков софта?
Здравствуйте, MTD, Вы писали:
MTD>Про преждевременную пессимизацию не писал только ленивый. Сначала надо написать понятно и чтобы работало правильно, потом по необходимости начинать оптимизировать. Вот ты привел пример с быстродействием и мимо, например, почему ты не предложил сравнивать хеши?
А можно написать строку, которая все строки будет держать в общей хеш-таблице, по одному экземпляру на каждое конкретное значение. Тогда сравнение строк сведется к сравнению указателей, и памяти будет меньше расходоваться.
Здравствуйте, Pzz, Вы писали:
Pzz>>>Если посмотреть strace'ом, чем там программа на Go занимается, то можно с изумлением увидеть, что унутре нее тот же epoll
MTD>>Поразительно, кто бы мог подумать.
Pzz>Это даже в инструкции где-то написано, но пальцем не покажу.
Блин, да очевидно, что внутри будет системный вызов.
Pzz>У Go, в силу того, что там не возбраняется завести локальную переменную, передать ее адрес куда-нибудь, где его сохранят, и выйти из процедуры, всякое заведение локальной переменной является потенциальной аллокацией из кучи.
Пофиг. Куча в языках со сборкой мусора быстрая. На практике производительность достаточная, да на С++ можно написать быстрей, но можно и в 3 раза медленнее, чем на Питоне. Этим Го и хорош — средний программист напишет лучше, чем на С++, язык не позволяет делать совсем дикие вещи. Например, в С++ передали вектор в функцию не по ссылке — получили тормоз.
Здравствуйте, scf, Вы писали:
scf>Просто для С++ почему-то не нашлось корпорации, которая бы родила к нему простой, но обширный рантайм. scf>Кто писал на Qt меня поймут — там есть всё, что нужно обыкновенному программисту для обыкновенных задач.
Я думаю, если бы в языке C++ некоторые общеупотребительные вещи были встроены прямо в язык (например, строки, вектора, мапы), то было бы сильно меньше бардака.
Увы, если есть две реализации строки, которые делают одно и тоже, но представляют собой разные классы, они не взаимозаменяемы. Поэтому если в библиотеке A свои строки, в библиотеке B свои, а программа использует std::string, то существенная часть программы будет заниматься преобразованием между разными типами строк.
MTD>Кстати да, очень удобный фреймворк. Мне доводилось писать на разных железках, на некоторых были старые компиляторы в которых не было части стандартной библиотеки и Boost там не собирался, но Qt работал вообще везде и сразу из коробки ты получал все, что нужно для работы. Неудивительно, что столько фриков от труЪ С++ Qt ненавидят — ведь там можно просто сесть и писать код решающий конкретную задачу.
1. Qt изначально был платным поэтому он пропустил время когда мог бы стать популярным.
2. В те времена еще не была популярна кроссплатформенная разработка и если брать платный продукт то лучше было взять С++Builder чем Qt;
3. Первый раз когда смотрел на Qt это выглядело как большая свалка классов, а не как упорядоченный набор классов где каждый класс решает свою задачу;
4. Убогая система событий, тогда как С++Builder ловлю всех нужных событий программисту давал из коробки;
Возможно сейчас Qt неплох но время упущено, все нашли себе решения своих задач без Qt.
Здравствуйте, AlexGin, Вы писали:
AG>Зачем это всё,когда есть библиотеки? AG>К чему всё это тащить именно в ЯП?
А вот как раз библиотек и не наблюдается.
Набираем в гугле c++ unicode string и радуемся жизни и советам тащить iconv или юзать чей-то код с сотней звезд на гитхабе.
Пример, конечно, единичный, но показательный. Правильно сделать юникод — задача непростая и посильная только крупной компании, которые почему-то не рвутся поддерживать опнсорс С++ библиотеки.
Здравствуйте, MTD, Вы писали:
MTD>Не приписывай себе чужие заслуги — это rudzuk диагностировал, а я не стал отрицать. Так что незачет.
Он про меня ничего не писал.
N>>Нет, не против. Я спрашиваю, почему ты оффтопишь! MTD>Выражайся понятней.
Куда уж понятней: тема называется поугараем, а внутри твои сопли. Или над тобой надо угарать?
N>>Потому что, снимая майку у девушки, я ожидаю там увидеть сиськи. Если их нет, то волнуюсь. Также и в твоей теме. MTD>Ты про то, что угара нет? А по моему есть, в 3 раза слить Питону — это надо постараться.
Да! Догадался всё таки. Где угар? Кроме твоей боли и плача нет ничего.
Здравствуйте, AlexGin, Вы писали:
AG>На самом деле: Boost классная вещица! AG>Использовать boost в своих наработках приятно.
Сделать из С++ Питон по быстродействию — классно! Замедлить компиляцию в 10 раз — отлично! Получить ошибку на 10 экранов — да, черт побери!
AG>Зачем это всё,когда есть библиотеки?
Потому, что мне не нужен зоопарк. Я хочу из коробки получить совместимые интерфейсы и гарантии качества.
AG>К чему всё это тащить именно в ЯП?
Потому, что это удобно.
AG>...так ведь у каждого — свои мозги, правда в приведенном видео ИМХО ими так и не воспользовались...
Любой мастер класс на С++ — часовое обсуждение такой чухни про которую в других языках даже не думаешь. Бери любой наугад, не прогадаешь:
https://www.youtube.com/watch?v=LuaNbkRPGRo
MTD>>Короче, мой месседж — С++ маргинализируется и становится убежищем фриков, на интересы инженеров там положили болт. AG> AG>Что такое интересы инженеров?
Блин, народ уже даже словарь открыть чтобы узнать незнакомое слово ленится. Ну давай я для тебя его открою:
Инжене́р (фр. ingénieur ← от лат. ingenium — способности, изобретательность[1]) — специалист, осуществляющий инженерную деятельность.
Целями инженерной деятельности являются изобретение, разработка, создание, внедрение, ремонт, обслуживание и/или улучшение техники, материалов или процессов.
Мне платят деньги за решение практических задач, а не академические исследования — я инженер.
AG>Можно посмотреть примеры именно инженерных интересов?
Мне например нужны юникодные строки, классы работы с временем и датой, файловые операции, модули, корутины — это только так навскидку, что нужно и чего нет.
AG>Вот чем таким инженерные интересы в разработке ПО отличаются, ну скажем от интересов врачей, бухгалтеров, диспетчеров?
Врачи людей лечат, а не ПО разрабатывают. Ты что вообще пишешь?
AG>А разве новые стандарты (от C++11 и позднее) не сделали C++ компактнее и ближе к запросам разработчиков софта?
Сделали, но много чего не сделали. Я считаю, что проблема в приоритетах.
Здравствуйте, Nuzhny, Вы писали:
MTD>>Не приписывай себе чужие заслуги — это rudzuk диагностировал, а я не стал отрицать. Так что незачет. N>Он про меня ничего не писал.
А ты тут при чем? Про мою же боль и обиды говорили.
N>Куда уж понятней: тема называется поугараем, а внутри твои сопли.
Не нравится — не читай, судя по тому, что ты тут — ты лукавишь.
N>Или над тобой надо угарать?
Поугарай. В чем проблема?
MTD>>Ты про то, что угара нет? А по моему есть, в 3 раза слить Питону — это надо постараться.
N>Да! Догадался всё таки. Где угар? Кроме твоей боли и плача нет ничего.
А по моему есть, в 3 раза слить Питону — это надо постараться.
До тех пор, пока язык придерживается правила "ты не платишь за то, что не используешь", — пофик насколько упоротые люди сидят в комитете (я не считаю, что они упоротые, но предположим). Не нравится что-то новое — просто его не используешь, и его наличие никак тебя не задевает.
Хочешь юникодных строк и т.п — пожалуйста, пиши на QT, С++ может быть любым, каким угодно, в это и есть его сила.)
Здравствуйте, jahr, Вы писали:
J>Хочешь юникодных строк и т.п — пожалуйста, пиши на QT, С++ может быть любым, каким угодно, в это и есть его сила.)
А с модулями и корутинами как быть?
Кроме того у каждой более/менее серьезной либы свои контейнеры и строки, мне не хочется постоянно писать код занимающийся конвертацией — во-первых, уныло, во-вторых, а что с быстродействием, С++ же.
Здравствуйте, Pzz, Вы писали:
Pzz>А можно написать строку, которая все строки будет держать в общей хеш-таблице, по одному экземпляру на каждое конкретное значение. Тогда сравнение строк сведется к сравнению указателей, и памяти будет меньше расходоваться.
Вы только что изобрели string.Intern из JVM и .NET. А в сообщении Поугараем над С++ комьюнити? обсуждается примерно то же самое, из их мира. Вывод — байтогрызные подходы в Go не работают.
MS>>Видео не смотрел, но пример более чем показателен. MS>>Если строка например изначально в верхнем регистре, а потом будет сравниваться 100 раз, то будешь делать фактически 100 раз приведение к нижнему регистру. А если это национальный алфавит и прочие умляуты, где приведение в нижний регистр дорого?
MTD>Про преждевременную пессимизацию не писал только ленивый. Сначала надо написать понятно и чтобы работало правильно, потом по необходимости начинать оптимизировать. Вот ты привел пример с быстродействием и мимо, например, почему ты не предложил сравнивать хеши?
Чтобы сравнивать хэши строк, нечуствительно к регистру надо сначала перевести в нижний регистр, но не оставлять на потом. Т.е. опять за предварительную конвертацию строки.
Если ответить на вопрос сопадает-ли строка хэш подойдет, то для сравения больше/меньше уже нет
Здравствуйте, Слава, Вы писали:
С>Вы только что изобрели string.Intern из JVM и .NET. А в сообщении Поугараем над С++ комьюнити? обсуждается примерно то же самое, из их мира. Вывод — байтогрызные подходы в Go не работают.
Pzz сказал же — это появилось в Снобол-4. Это 60-е годы прошлого века. Создатели Java тогда в детский сад ходили (те, кто уже родился).
Здравствуйте, Went, Вы писали:
W>А разве нет кросс-платформенных библиотек корутин?
Хах)) Это можно про любую библиотеку с++ сказать — "а разве нет кросс-платформенных библиотек XXXX?".
Теоретически как бы всё есть. Теоретически.
А практически оно в таком виде (или сложность или способы использования), что можно сказать нет.
Здравствуйте, MTD, Вы писали:
MTD>А с модулями и корутинами как быть?
Модули есть в MSVC, а корутины — в бусте.)
MTD>Кроме того у каждой более/менее серьезной либы свои контейнеры и строки, мне не хочется постоянно писать код занимающийся конвертацией — во-первых, уныло, во-вторых, а что с быстродействием, С++ же.
Ну, Вы же программист на плюсах, должны уметь состыковать идеологически разнородные библиотеки.) Хотя, уверен, что и для этого что-то есть, видел где-то недавно какую-то библиотеку для генерации врапперов над другими библиотеками.)
Здравствуйте, Pzz, Вы писали:
Pzz>Но вот что в этом Go мне в плане производительности действительно не нравится, это то, что библиотека евонная так и норовит на каждый чих чего-нибудь маленькое зааллоцировать в куче, а сборщику мусора потом подбирать.
Для нормальных сборщиков мусора куча короткоживущих объектов не помеха и на перформанс не влияет. GC страдают от развесистых графов зависимостей и долгоживущих объектов.
MTD>Чувак на полном серьезе рассказыват, что вместо того чтобы пилить класс строк для того чтобы сравнивать строки независимо от регистра, можно написать класс-свойство, который передать в шаблон стандартной строки и который будет переводить строки в нижний регистр перед тем как положить в память, ну и потом можно эти строки сравнивать.
Изначальная идея написания этого класса-свойства, рассказанная в видео, немного не такая как ты описал.
Здравствуйте, Pzz, Вы писали:
Pzz>У Go, в силу того, что там не возбраняется завести локальную переменную, передать ее адрес куда-нибудь, где его сохранят, и выйти из процедуры, всякое заведение локальной переменной является потенциальной аллокацией из кучи. Компилятор пытается угадать про каждую переменную, переживет ли она выход из области видимости, где она определена, или не переживет. И в зависимости от этого заводит ее либо в стеке, либо в куче. Это называется escape analysis.
Не. Escape analysis это наоборот, когда ты говоришь что в куче хочешь, а оно, на основе анализа, пихает в стек. А вот локальные переменные вытащить в кучу — там совсем примитивно все. Совершенно бинарная логика — если локальная переменная поиспользовалась в чем то вроде замыкания или выдачи ссылки на нее в чужой метод, то автоматично двигаем ее в кучу.
Здравствуйте, scf, Вы писали:
scf>Просто для С++ почему-то не нашлось корпорации, которая бы родила к нему простой, но обширный рантайм.
Дело не в корпорации, а в самом языке, сильно неудобном для создания фреймворков. Ни ABI с компонентной моделью, ни рефлексии, ни даже стандартных доккомментов.
Ну и отчасти в коммьюнити. Ни в одном другом языке, к примеру, нет такой страсти к переписыванию RTL.
Здравствуйте, MTD, Вы писали:
AG>>Использовать boost в своих наработках приятно. MTD>Сделать из С++ Питон по быстродействию — классно! Замедлить компиляцию в 10 раз — отлично! Получить ошибку на 10 экранов — да, черт побери!
Насчёт Питона — буду спорить, это твой замыленный взгляд.
Скрость компиляции — да бывает и увеличивается, но не то чтобы на порядок.
Листинг для единичной ошибки — может быть достаточно большой, но это не препятствие для квалифицированного разработчика.
AG>>Зачем это всё,когда есть библиотеки? MTD>Потому, что мне не нужен зоопарк. Я хочу из коробки получить совместимые интерфейсы и гарантии качества.
Гарантии какчества...
Это в ГОССТРАХ разработчик как бы и должен обеспечить сам.
Компания Microsoft вместо него качества НЕ ОБОСПЕЧИТ — ни для C# (где очень много чего именно в ЯП), ни для C++.
AG>>К чему всё это тащить именно в ЯП? MTD>Потому, что это удобно.
Удобно что? Безальтернативность?
AG>>...так ведь у каждого — свои мозги, правда в приведенном видео ИМХО ими так и не воспользовались... MTD>Любой мастер класс на С++ — часовое обсуждение такой чухни про которую в других языках даже не думаешь. Бери любой наугад, не прогадаешь
А зачем тогда применять C++, для тех задач, которые можно закрыть — например на .NET (C#)?
Насчёт мастер классов — так это смотря от кого этот самый "мастер класс"...
AG>>Что такое интересы инженеров? MTD>Блин, народ уже даже словарь открыть чтобы узнать незнакомое слово ленится. Ну давай я для тебя его открою:
...
...налицо подмена понятий... я, будучи ведущим инженером с более чем 20-летним стажем, прекрасно понимаю смысл слова.
Ты поясни, чем для разработки software интересы инженера и финансиста принципиально отличаются?
MTD>Мне платят деньги за решение практических задач, а не академические исследования — я инженер.
Тогда может ты мастер, или слесарь, или просто наладчик?
Sorry: ничего личного, не хочу тебя обижать, уважаемый MTD.
Это мои размышления о человеке, который занимается только практикой, без исследований.
AG>>Можно посмотреть примеры именно инженерных интересов? MTD>Мне например нужны юникодные строки, классы работы с временем и датой, файловые операции, модули, корутины — это только так навскидку, что нужно и чего нет.
a) юникодные строки — std::wstring есть также и QString;
b) классы работы с временем и датой — std::time есть также и QDateTime;
c) файловые операции — здесь завязано сильно на специфику ОС, но WinAPI нам поможет: https://msdn.microsoft.com/en-us/library/windows/desktop/aa364232(v=vs.85).aspx
e) модули — вроде как уже есть (на уровне передовых средств разработки): https://habrahabr.ru/company/infopulse/blog/267781 https://habrahabr.ru/company/pvs-studio/blog/328482
f) корутины — в том же Qt сигналы и слоты решат эти задачи, тот же boost: http://www.boost.org/doc/libs/1_55_0/libs/coroutine/doc/html/index.html — в общем есть практически всё.
AG>>Вот чем таким инженерные интересы в разработке ПО отличаются, ну скажем от интересов врачей, бухгалтеров, диспетчеров? MTD>Врачи людей лечат, а не ПО разрабатывают. Ты что вообще пишешь?
Ну так ведь и врачи, и финансисты, и инженеры не ПО разрабатывают — а только пишут ТЗ...
Да знаю я, о чём пишу: я сам из инженера переквалифицировался в разработчика ПО.
При этом, разработкой на C++ занимаюсь последние 15 лет.
AG>>А разве новые стандарты (от C++11 и позднее) не сделали C++ компактнее и ближе к запросам разработчиков софта? MTD>Сделали, но много чего не сделали. Я считаю, что проблема в приоритетах.
...
IMHO проблема в нашем восприятии происходящего.
По сравнению с C++ 98 — красота, лепота
По сравнению с современным C# — да, чего то и не хватает, но за счёт библиотек это можно успешно закрыть.
P.S. Возможность выполнить то же самое преобразование Фурье примерно в 100 раз быстрее на C++, нежели то же самое на C# (в управляемом коде) — с лихвой компенсирует эти небольшие недостатки.
Здравствуйте, AlexGin, Вы писали:
MTD>>Сделать из С++ Питон по быстродействию — классно! Замедлить компиляцию в 10 раз — отлично! Получить ошибку на 10 экранов — да, черт побери! AG> AG>Насчёт Питона — буду спорить, это твой замыленный взгляд.
Это измеренная скорость выполнения. Я привел цифры, тебе может быть неприятно, но это объективная реальность.
AG>Скрость компиляции — да бывает и увеличивается, но не то чтобы на порядок.
Именно на порядок. На деньги готов спорить? Немного, ради интереса, тысяч на 5, например?
AG>Листинг для единичной ошибки — может быть достаточно большой, но это не препятствие для квалифицированного разработчика.
А дуршлаг на голову надеть тоже не препятствие, просто сконцентрируйся и работай. Но зачем?
AG>Гарантии какчества... AG>Это в ГОССТРАХ разработчик как бы и должен обеспечить сам. AG>Компания Microsoft вместо него качества НЕ ОБОСПЕЧИТ — ни для C# (где очень много чего именно в ЯП), ни для C++.
Ты видимо не понимаешь смысла стандартизации. Стандарт гарантирует, что это будет выполняться так, а не иначе, на это можно закладываться. Если что-то работает не так — это не соответствует стандарту.
AG>Удобно что? Безальтернативность?
Да. Если в языке есть адекватные средства, то зачем альтернативы? Если очень хочется бери. Или ты весь такой жесткий и радикальный? Потребуй убрать стандартную бибилиотеку, да и сам язык как-то уж очень того.
MTD>>Любой мастер класс на С++ — часовое обсуждение такой чухни про которую в других языках даже не думаешь. Бери любой наугад, не прогадаешь AG> AG>А зачем тогда применять C++, для тех задач, которые можно закрыть — например на .NET (C#)?
Язык С++ — универсальный. Мне, что на С++ вообще ничего не писать, так как вот С, вот Питон, вот Ява?
AG>...налицо подмена понятий... я, будучи ведущим инженером с более чем 20-летним стажем, прекрасно понимаю смысл слова. AG>Ты поясни, чем для разработки software интересы инженера и финансиста принципиально отличаются?
Финансист не разрабатывает ПО, он ставит высокоуровневые задачи, какие там инструменты применит инженер ему все равно, а инженеру нет.
MTD>>Мне платят деньги за решение практических задач, а не академические исследования — я инженер. AG> AG>Тогда может ты мастер, или слесарь, или просто наладчик?
Я программист, такой вот мастер-слесарь от IT.
AG>Это мои размышления о человеке, который занимается только практикой, без исследований.
Ну да, не всем же монады изобретать, кто-то должен просто решить задачу.
AG>>>Можно посмотреть примеры именно инженерных интересов? MTD>>Мне например нужны юникодные строки, классы работы с временем и датой, файловые операции, модули, корутины — это только так навскидку, что нужно и чего нет. AG> AG>a) юникодные строки — std::wstring есть также
Без обид, ты не понимаешь, что такое юникод.
AG>и QString;
Этого нет в стандарте.
AG>b) классы работы с временем и датой — std::time
Скажи как мне стандартными средствами С++ от некоей даты и времени получить дату и время ровно через год?
AG>c) файловые операции — здесь завязано сильно на специфику ОС, но WinAPI нам поможет:
Нет, я хочу из коробки кроссплатформенно создать директорию. Это рокет сайнс?
AG>e) модули — вроде как уже есть (на уровне передовых средств разработки):
Причем тут студия?
AG>f) корутины — в том же Qt сигналы и слоты решат эти задачи.
Это вообще другое.
AG>Ну так ведь и врачи, и финансисты, и инженеры не ПО разрабатывают — а только пишут ТЗ... AG>Да знаю я, о чём пишу: я сам из инженера переквалифицировался в разработчика ПО.
Не понял, разработчик не разрабатывает ПО или он не инженер?
M>>Изначальная идея написания этого класса-свойства, рассказанная в видео, немного не такая как ты описал. MTD>Спасибо, интересно. Интрига останется или ты напишешь как оно на самом деле?
Написать класс строки, который хранит строчку в нижнем регистре
Немного отличается от того что ты сказал: "чувак написал класс, которым затем параметризовал шаблонный класс строки, для того чтобы используя эту конструкцию сравнивать потом строки".
Здравствуйте, Muxa, Вы писали:
M>>>Изначальная идея написания этого класса-свойства, рассказанная в видео, немного не такая как ты описал. MTD>>Спасибо, интересно. Интрига останется или ты напишешь как оно на самом деле?
M>Немного отличается от того что ты сказал: "чувак написал класс, которым затем параметризовал шаблонный класс строки, для того чтобы используя эту конструкцию сравнивать потом строки".
Ну так ты расскажешь в чем отличие? Или я должен еще раз посмотреть? А если я тупой, я же снова ничего не пойму, будь добр помоги коллеге.
MTD>Ну так ты расскажешь в чем отличие? Или я должен еще раз посмотреть? А если я тупой, я же снова ничего не пойму, будь добр помоги коллеге.
Отличия в мотивации.
Если тебе нужно сравнить два char* или std::string регистронезависимо — написал функцию, сравнил и забыл.
Если тебе нужно хранить строки в нижнем регистре — пиши класс, в случае если будет переиспользован стандартный std::string, и будет написано всего пять новых строк кода — идеально.
Здравствуйте, turbocode, Вы писали:
T>1. Qt изначально был платным поэтому он пропустил время когда мог бы стать популярным.
Неверно — всегда была и свободная версия библиотеки: https://habrahabr.ru/post/45764 T>2. В те времена еще не была популярна кроссплатформенная разработка и если брать платный продукт то лучше было взять С++Builder чем Qt
...опять твои домыслы...
Qt можно было использовать в разработках как Windows, так и Unix, причём программный интерфейс был одинаковый на обеих платформах. С первого дня предусматривались две лицензии применения Qt: коммерческая лицензия предназначалась для коммерческих разработок, и свободно распространяемая версия предназначалась для разработок Open-source проектов.
T>3. Первый раз когда смотрел на Qt это выглядело как большая свалка классов, а не как упорядоченный набор классов где каждый класс решает свою задачу;
Это характеризует только твой уровень квалификации в те годы. К самой библиотеке Qt сие не относится.
T>4. Убогая система событий, тогда как С++Builder ловлю всех нужных событий программисту давал из коробки;
Выделенное относится именно к С++Builder — зная о чем пишу, работал с ним в 2000-х довольно плотно.
T>Возможно сейчас Qt неплох но время упущено, все нашли себе решения своих задач без Qt. https://www1.qt.io/built-with-qt
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, turbocode, Вы писали:
T>>1. Qt изначально был платным поэтому он пропустил время когда мог бы стать популярным. AG>Неверно — всегда была и свободная версия библиотеки: AG>
AG>Qt можно было использовать в разработках как Windows, так и Unix, причём программный интерфейс был одинаковый на обеих платформах. С первого дня предусматривались две лицензии применения Qt: коммерческая лицензия предназначалась для коммерческих разработок, и свободно распространяемая версия предназначалась для разработок Open-source проектов.
Много здесь пишут OpenSource? Конечно же я имел ввиду бесплатное использование Qt для разработки коммерческих продуктов.
T>>3. Первый раз когда смотрел на Qt это выглядело как большая свалка классов, а не как упорядоченный набор классов где каждый класс решает свою задачу; AG> AG>Это характеризует только твой уровень квалификации в те годы. К самой библиотеке Qt сие не относится.
Очень даже относится, никому не хочется терять свое время на рытьё на свалке в поиске алмазов.
Тогда как VCL была очень хорошо структурирована библиотека классов и используя её редко нужно было даже лезть в справку, там действительно был самодокументированный код.
T>>4. Убогая система событий, тогда как С++Builder ловлю всех нужных событий программисту давал из коробки; AG>Выделенное относится именно к С++Builder — зная о чем пишу, работал с ним в 2000-х довольно плотно.
Можно примеры?
Здравствуйте, Слава, Вы писали:
Pzz>>А можно написать строку, которая все строки будет держать в общей хеш-таблице, по одному экземпляру на каждое конкретное значение. Тогда сравнение строк сведется к сравнению указателей, и памяти будет меньше расходоваться.
С>Вы только что изобрели string.Intern из JVM и .NET. А в сообщении Поугараем над С++ комьюнити? обсуждается примерно то же самое, из их мира.
Это не я изобрел. Это я рассказал, как строки были устроены в языке Снобол-4. Язык Снобол-4 был создан в начале 60-х.
C>Вывод — байтогрызные подходы в Go не работают.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Не. Escape analysis это наоборот, когда ты говоришь что в куче хочешь, а оно, на основе анализа, пихает в стек. А вот локальные переменные вытащить в кучу — там совсем примитивно все. Совершенно бинарная логика — если локальная переменная поиспользовалась в чем то вроде замыкания или выдачи ссылки на нее в чужой метод, то автоматично двигаем ее в кучу.
Насколько я понимаю, в Go подход такой: все переменные по дефолту в куче, если только анализ не показывает, что их можно запихнуть в стек. Т.е., с содержательной точки зрения заведение локальной переменной от явной аллокации отличается только синтаксисом.
С другой стороны, Go умеет просматривать вглубь всю цепочку вызовов, причем спокойно проходит при этом сквозь границы пакетов. Поэтому если адрес переменной передали какой-то функции/методу, а она достаточно проста, чтобы анализатор мог понять, что адрес она себе на память не оставит, то такой вызов не помешает анализатору посчитать, что переменная может быть организована на стеке.
Полностью согласен. И это было очевидно всем очень давно.
А ментейнеры языка демонстративно игнорировали проблемы языка, пока уже не стало поздно — критическая масса разработчиков ушла на другие языки, а новые смотрят на возможности языка и его инфраструктуры и видят практически ноль по сравнению с другими.
Сейчас уже который год ментейнеры бегут за уехавшим поездом в надежде запрыгнуть на него опять, крича запыхавшись — "ух мы-то, огого!".
И все эти с++11, с++14, с++17, с++20 — это черепашие бега на месте. Язык и его инфрастуктура _УЖЕ_ требуется уровня с++300, если не больше.
И такое ощущение, что специально саботируют развитие языка:
1) Ввели спецификацию исключений — прям мордой потыкать хотелось, чтобы рассказали как это всё поддерживать? Серьёзно, обойти рекурсивно все функции, чтобы собрать всё, что может вылететь?
Убрали. Ну спасибо. Оставили спецификатор что не бросает исключений. Но нафига мне его писать? Компилер, что сам не может это понять? Уверен, что к с++50 и его выкинут.
2) Долго упирались на счёт range-based for. Ну хоть ввели. А интерфейсы стандартной библиотеки остались старыми. *FACEPALM* Ну хоть к с++20 опомнились.
3) Ввели потоки. Помню сколько фрики писались, что они не нужны, тра-ля-ля... а если потоков на платформе нет, то айя-йяй! Ну нет — так не используй, пусть будет проверка — можно ли использовать их или нет на конкретной платформе. Наконец к с++17 или с++20 (не помню) добавили возможность стандартной проверки.
Сами потоки ввели фриковские (линуксоидные) — без возможности просто создания потока, когда я хочу просто подготовить его (чтобы подготовился стек и тп.) и держать, а потом в нужный момент сделать "горячий" старт. Это же с++, детка, ну как так этого нет? Нет — пилите это сами.
4) constexpr — серьёзно? Вы предлагаете мне взять на себя работу компилятора и оптимизатора? В чём вообще проблема считать при компиляции, если известны все аргументы? Думаю выкинут это к с++70
5) auto — до сих пор не понимаю как фрики пропустили эту вещь. О боже, работу компилятора переложили на компилятор. Почему изначально этого небыло — вопрос века. К с++50 доведут до ума.
4) и т.д.
И как после этого ментейнеров не назвать тупыми?
Итого:
— всё разношёрстное, нет единообразия, или хотя бы единой идеологии в стандартных средствах
— отсталость языка (о боже наконец-то вводят any, optional, variant и т.д. — и то либами, фу! Нет reflection, modules, ABI и т.д.).
— отсталость основных конструкций: нет IPC, RPC, filesystem, DateTime, Plugin framework и т.д.
— отсутствие стандартных библиотек для основных направлений разработки ПО: audio, video, images, net, text processing, embedded, GUI, science, и т.д. короче тут можно перечислять вообще всё.
*я пишу нет — это значит, что нет стандартных и удобных средств и библиотек. Так-то в плюсах всё есть. Теоретически. А практически либо переусложнённое, либо настолько раком вывернутое, что можно с уверенностью сказать — практически этого нет.
Короче полный швах по всем фронтам. Да, есть с++11+14+17, но это смешная капля от того, что надо сделать.
По хорошему надо разогнать текущий комитет, сделать ревизию текущего состояния стандарта (убрать все UB и т.п.). И наконец добавить все эти нужные вещи.
И никаких "n" лет для обсуждения какой-то хрени. Учитывая весь предыдущий опыт, а также перенимая опыт других языков — _всё_ это вполне делается максимум за 1 (_один_) год.
ПС: но как-бы то ни было, альтернативы плюсам пока что не наблюдается, печалька
Здравствуйте, MTD, Вы писали:
AG>>Насчёт Питона — буду спорить, это твой замыленный взгляд. MTD>Это измеренная скорость выполнения. Я привел цифры, тебе может быть неприятно, но это объективная реальность.
Пока, я вижу что цифры эти взяты с неба бездоказательно.
AG>>Скрость компиляции — да бывает и увеличивается, но не то чтобы на порядок. MTD>Именно на порядок. На деньги готов спорить? Немного, ради интереса, тысяч на 5, например?
Нет у меня ни таких денег, ни желания спорить на них. Две с половиной штуки баксов на спор — это очень круто глупо.
MTD>Ты видимо не понимаешь смысла стандартизации. Стандарт гарантирует, что это будет выполняться так, а не иначе, на это можно закладываться. Если что-то работает не так — это не соответствует стандарту.
Просто я из тех людей что ищут возможности, а прикрывание стандартом — это для тех, кто ищет отговорки.
Возможностей в современном C++ имеется вагон и маааленьккая тележка
Главное — желание использовать эти возможности!
AG>>Удобно что? Безальтернативность? MTD>Да. Если в языке есть адекватные средства, то зачем альтернативы? Если очень хочется бери.
Альтернативы всегда приятны — можно сделать так, а можно и иначе. Всегда есть возможность выбора.
AG>>А зачем тогда применять C++, для тех задач, которые можно закрыть — например на .NET (C#)? MTD>Язык С++ — универсальный. Мне, что на С++ вообще ничего не писать, так как вот С, вот Питон, вот Ява?
+100500
Да, язык C++ универсальный. Но это не делает его серебрянной пулей.
AG>>Ты поясни, чем для разработки software интересы инженера и финансиста принципиально отличаются? MTD>Финансист не разрабатывает ПО, он ставит высокоуровневые задачи, какие там инструменты применит инженер ему все равно, а инженеру нет.
Так ведь и инженеру — всё равно:
Ну вот не могу я представить, например инженера-тракторостроителя, который скажет:
— Карданный вал трактора МТЗ-... рассчитываем только на Питоне третьей версии!
Главное — чтобы алгоритм выполнялся, чтобы правильные формулы испльзовались для расчётов.
AG>>a) юникодные строки — std::wstring MTD>Без обид, ты не понимаешь, что такое юникод.
the STL std::wstring class, which is wchar_t-based, works fine to store UTF-16 Unicode text
AG>>b) классы работы с временем и датой — std::time MTD>Скажи как мне стандартными средствами С++ от некоей даты и времени получить дату и время ровно через год?
AG>>e) модули — вроде как уже есть (на уровне передовых средств разработки): MTD>Причем тут студия?
Осовной инструмент
AG>>f) корутины — в том же Qt сигналы и слоты решат эти задачи. MTD>Это вообще другое.
Не нравится в Qt, так есть корутины в boost https://theboostcpplibraries.com/boost.coroutine
AG>>Ну так ведь и врачи, и финансисты, и инженеры не ПО разрабатывают — а только пишут ТЗ... AG>>Да знаю я, о чём пишу: я сам из инженера переквалифицировался в разработчика ПО. MTD>Не понял, разработчик не разрабатывает ПО или он не инженер?
В данном контексте — я различаю понятия:
— Инженер программист
— Инженер (как конструктор).
Здравствуйте, Muxa, Вы писали:
M>Если тебе нужно хранить строки в нижнем регистре
Переведи в нижний регистр и храни. Что за дичь для этого класс делать? Во-первых, явное лучше неявного. Во-вторых, ты не сможешь использовать методы которые принимают std::string.
Здравствуйте, AlexGin, Вы писали:
AG>>>Зачем это всё,когда есть библиотеки? MTD>>Потому, что мне не нужен зоопарк. Я хочу из коробки получить совместимые интерфейсы и гарантии качества. AG>Гарантии какчества... AG>Это в ГОССТРАХ разработчик как бы и должен обеспечить сам. AG>Компания Microsoft вместо него качества НЕ ОБОСПЕЧИТ — ни для C# (где очень много чего именно в ЯП), ни для C++.
Ну вот поэтому для mission-critical софт на C++ и не пишут. Используют либо Си, либо прочее такое, простое и сертифицированное.
P>А ментейнеры языка демонстративно игнорировали проблемы языка, пока уже не стало поздно — критическая масса разработчиков ушла на другие языки, а новые смотрят на возможности языка и его инфраструктуры и видят практически ноль по сравнению с другими.
Они не сами ушли, а их ушли. Дорого индусов держать на С++, нужны прямые руки, а где их столько взять?
P>Сейчас уже который год ментейнеры бегут за уехавшим поездом в надежде запрыгнуть на него опять, крича запыхавшись — "ух мы-то, огого!".
Они до сих пор "огого" по части производительности и расходу памяти.
Здравствуйте, push, Вы писали:
P>По хорошему надо разогнать текущий комитет, сделать ревизию текущего состояния стандарта (убрать все UB и т.п.). И наконец добавить все эти нужные вещи.
Ну да, нужно что-то вроде ломающего обратную совместимость перехода, который в питоне сделали от 2.7 к 3.0.
Здравствуйте, turbocode, Вы писали:
T>Тогда как VCL была очень хорошо структурирована библиотека классов и используя её редко нужно было даже лезть в справку, там действительно был самодокументированный код.
Бесспорно, что такие продукты как Delphi и С++ Builder пользовальсь огромным успехом лет 15 назад, и их основа VCL также.
Sic transit gloria mundi...
T>Можно примеры?
Да, если рассматривать С++ Builder по сравению с современными продуктами —
тот же Qt (со слотами и сигналами); C# (c поддержкой делегатов) — то система отправки и обработки сообщений в билдере выглядит очень скромно.
Но для конца 90-х и начала 2000-х, это было очень даже неплохо.
Здравствуйте, AlexGin, Вы писали:
AG>Пока, я вижу что цифры эти взяты с неба бездоказательно.
Код я написал, ничто кроме веры тебе не мешает запустить его у себя.
AG>Просто я из тех людей что ищут возможности, а прикрывание стандартом — это для тех, кто ищет отговорки.
Причем тут прикрывание стандартом? Мне деньги надо зарабатывать, стандартизация в этом помогает.
AG>Альтернативы всегда приятны — можно сделать так, а можно и иначе. Всегда есть возможность выбора.
Делай, кто мешает? Или от того, что язык сделают дружелюбней кому-то хуже станет?
AG>Ну вот не могу я представить, например инженера-тракторостроителя, который скажет: AG>- Карданный вал трактора МТЗ-... рассчитываем только на Питоне третьей версии! AG>Главное — чтобы алгоритм выполнялся, чтобы правильные формулы испльзовались для расчётов.
Аналогия неверна. Инженер говорит чтобы сделать этот вал с нужной точностью и в установленные сроки мне нужны станки Х, на станках Y точность будет хуже, а на станках Z я не уложусь в сроки.
AG>>>a) юникодные строки — std::wstring MTD>>Без обид, ты не понимаешь, что такое юникод.
AG>Да, только ты понимаешь что это такое.
Ты бы вместо того чтобы обижаться взял бы и прочитал ликбез по юникоду. Без обид, я конечно мог бы делать реверансы, но сказал прямо, как к этому относится дело твое.
AG>the STL std::wstring class, which is wchar_t-based, works fine to store UTF-16 Unicode text
А на Linux внезапно wchar_t не 16, а 32 бита. А еще не каждая буква в utf-16 16 бит.
AG>>>b) классы работы с временем и датой — std::time MTD>>Скажи как мне стандартными средствами С++ от некоей даты и времени получить дату и время ровно через год?
AG> std::time_t t1 = std::time(nullptr); AG> std::time_t t2 = t1 + 3600 * 24 * 365; // 3600 seconds in one hour
И сразу первый косяк — высокосные года были проигнорированы. Забегая вперед — это не единственная сложность с календарем.
MTD>>Причем тут студия? AG>Осовной инструмент
Это у кого как.
AG>>>f) корутины — в том же Qt сигналы и слоты решат эти задачи. MTD>>Это вообще другое. AG>Не нравится в Qt
Дело не в Qt, просто сигналы и слоты не то, что нужно. Смысл корутин в том, что ты пишешь как-будто синхронный код, при этом компилятор код развернет так, что на вызове функций, которые занимают время вместо блокировки начнет выполнятся другой код, причем не обязательно в другом потоке.
MTD>>Не понял, разработчик не разрабатывает ПО или он не инженер?
AG>В данном контексте — я различаю понятия: AG>- Инженер программист AG>- Инженер (как конструктор).
Что конструктор не инженер? Или программист не инженер?
Здравствуйте, AlexGin, Вы писали:
AG>Ну вот не могу я представить, например инженера-тракторостроителя, который скажет: AG>- Карданный вал трактора МТЗ-... рассчитываем только на Питоне третьей версии!
Зато я могу представить себе фашиста с палкой на роли генерального конструктора, который скажет "Из дерева карданный вал не делать. Из конструктора лего — не делать. Вот справочник видов конструкционных сталей — из них делать".
AG>
T>>Можно примеры? AG>Да, если рассматривать С++ Builder по сравению с современными продуктами — AG>тот же Qt (со слотами и сигналами); C# (c поддержкой делегатов) — то система отправки и обработки сообщений в билдере выглядит очень скромно.
С# тогда не было еще. Что значит скромно по сравнению с Qt?
Ну, начнём с того, что я пока не вижу фич, которые поломают обратную совместимость. А если будут ломать — то в чём проблема сделать ключики компиляции? Старые либы, которые ломаются компилить как обычно, а новые фичи будут доступны в либах, скомпиленых с нужным ключиком (как, например в msvs есть ключики для разных версий языка, а можно делать и по другому — вообще только на фичи языка). Проблемы я вообще никакой не вижу.
А во-вторых, оно уже как бы да — auto, спецификация исключений И ничего, все выжили.
Здравствуйте, Слава, Вы писали:
С>Ну вот поэтому для mission-critical софт на C++ и не пишут. Используют либо Си, либо прочее такое, простое и сертифицированное.
Подозреваю, что дело прежде всего именно в простоте.
Сертифицированное, но сложное — ИМХО в таких местах также вряд-ли применят.
Если простое — то и крайнего найти (в случае проблем) всегда проще.
Здравствуйте, Privalov, Вы писали:
P>Pzz сказал же — это появилось в Снобол-4. Это 60-е годы прошлого века. Создатели Java тогда в детский сад ходили (те, кто уже родился).
Я не удивлюсь, если это появилось еще раньше. Я никогда не интересовался историей вопроса. Но в Сноболе это было сделано именно так.
Здравствуйте, AlexGin, Вы писали:
AG>P.S. Возможность выполнить то же самое преобразование Фурье примерно в 100 раз быстрее на C++, нежели то же самое на C# (в управляемом коде) — с лихвой компенсирует эти небольшие недостатки.
Преобразование Фурье на С++ пишут только полные неадекваты, ибо GPU сделает это в десятки раз быстрее. Особенно если речь идёт об embedded системе, где обычно такие вещи и требуются — туда проще поставить ПЛИСку для (I)FFT, чем насиловать AP.
Здравствуйте, MTD, Вы писали:
MTD>Например, в С++ передали вектор в функцию не по ссылке — получили тормоз.
Ну да, С++ требует чтоб аффтар понимал что он делает.
Передача по ссылке, по const & и по значению — это ж три кардинально разных use case.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, MTD, Вы писали:
MTD>Мне бы хотелось, чтобы наконец в стандарте появились адекватные средства для этого. Ты против?
Да, потому что будет как с другими стандартными всемогутерами: громоздко и неудобно но зато на все случаи жизни.
"А клиент хотел просто шину на верёвке" (С)
Так что нафиг, уж лучше мы своими специализированными фреймворками будем и дальше пользоваться.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, MTD, Вы писали:
MTD>Ты про то, что угара нет? А по моему есть, в 3 раза слить Питону — это надо постараться.
А при чём тут С++ к криворуким погромистам? При должной кривизне верхних хваталок можно и в бОльшее колво раз слить.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, AlexRK, Вы писали:
ARK>Я слышал, что планируется создание некоего "C++ lite" — простого подмножества. Было бы круто.
А что тебе мешает писать прямо сейчас на этом подмножестве?
Какой то нежный программист пошёл — всё ему надо чтоб за него делали.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, scf, Вы писали:
scf>Просто для С++ почему-то не нашлось корпорации, которая бы родила к нему простой, но обширный рантайм.
Для всех платформ под который он существует?
Это будет такой суровый героизм!
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, MTD, Вы писали:
MTD>Нет, я хочу из коробки кроссплатформенно создать директорию. Это рокет сайнс?
Ты не поверишь но для абстрактной платформы в вакууме — да!
Кроссплатформ в этом плане страшное зло.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, push, Вы писали:
P>2) Долго упирались на счёт range-based for. Ну хоть ввели. А интерфейсы стандартной библиотеки остались старыми. *FACEPALM* Ну хоть к с++20 опомнились.
А в чём проблема то? range for у меня в С++17 прекрасно жрал любые контейнеры, включая самописные.
P>3) Ввели потоки. Помню сколько фрики писались, что они не нужны, тра-ля-ля...
Потоки шмотоки! CreateThread наше всио!
P>4) constexpr — серьёзно?
Серьёзно, полезная вещь временами.
P>5) auto — до сих пор не понимаю как фрики пропустили эту вещь. О боже, работу компилятора переложили на компилятор. Почему изначально этого небыло — вопрос века. К с++50 доведут до ума.
А что там доводить то? Работает как надо
P>- отсталость основных конструкций: нет IPC, RPC, filesystem, DateTime, Plugin framework и т.д. P>- отсутствие стандартных библиотек для основных направлений разработки ПО: audio, video, images, net, text processing, embedded, GUI, science, и т.д. короче тут можно перечислять вообще всё.
— отсутствие стандартной библиотечной функции give_me_money(size_t amount), ага.
P>*я пишу нет — это значит, что нет стандартных и удобных средств и библиотек. Так-то в плюсах всё есть. Теоретически. А практически либо переусложнённое, либо настолько раком вывернутое, что можно с уверенностью сказать — практически этого нет.
Ну не умеешь на плюсах — иди на то, где можешь и не мельтеши.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, koandrew, Вы писали:
K>Преобразование Фурье на С++ пишут только полные неадекваты, ибо GPU сделает это в десятки раз быстрее. Особенно если речь идёт об embedded системе, где обычно такие вещи и требуются — туда проще поставить ПЛИСку для (I)FFT, чем насиловать AP.
Неадекваты — пытаются на форумах привести абсолютно всё к одной общей гребенке.
В той компании где я тогда работал, требовалось выполнить это на PC, в среде ОС Windows, при этом без спец-требований к аппаратуре.
P.S. Хорошо что я свалил оттуда пару лет назад
Однако сути это НЕ МЕНЯЕТ — цифры эти не с потолка, а из экспериментов.
Здравствуйте, CreatorCray, Вы писали:
CC>Для всех платформ под который он существует? CC>Это будет такой суровый героизм!
Как будто разработчики компиляторов стандартную библиотеку всегда целиком портируют
Могли бы взять пример с Java — в ней рантайм делится на слои — от самого урезанного embedded до полноценной JRE.
Здравствуйте, scf, Вы писали:
scf>А вот как раз библиотек и не наблюдается. scf>Набираем в гугле c++ unicode string и радуемся жизни и советам тащить iconv или юзать чей-то код с сотней звезд на гитхабе. scf>Пример, конечно, единичный, но показательный. Правильно сделать юникод — задача непростая и посильная только крупной компании, которые почему-то не рвутся поддерживать опнсорс С++ библиотеки.
Здравствуйте, MTD, Вы писали:
MTD>Мне например нужны юникодные строки, классы работы с временем и датой, файловые операции, модули, корутины — это только так навскидку, что нужно и чего нет.
И всё это (не считая модулей, которые очевидно нельзя реализовать библиотекой) имелось в Boost'е уже много много лет назад (и частично уже переехало в стандарт). Но у тебя же фобия на Boost, поэтому для тебя это реально проблема. ))) Сочувствую. )))
M>>Если тебе нужно хранить строки в нижнем регистре MTD>Переведи в нижний регистр и храни. Что за дичь для этого класс делать? Во-первых, явное лучше неявного.
Вот есть у тебя куча объектов const std::string, неясного происхождения — было или не было вызвано приведение в нижний регистр при создании — хз, этж нужно явно делать. Как регистронезависимо сравнивать будешь их друг с другом?
MTD>Во-вторых, ты не сможешь использовать методы которые принимают std::string.
Метод стандартной библиотеки? Можно пример?
Твой собственный метод? Ты автор — пиши метод так чтобы он принимал все что должен принимать.
Здравствуйте, push, Вы писали:
P>- отсутствие стандартных библиотек для основных направлений разработки ПО: audio, video, images, net, text processing, embedded, GUI, science, и т.д. короче тут можно перечислять вообще всё.
Наоборот, считай все более-менее серьёзные либы в этом направлении писаны на С/С++. Последние лет 10-15 почти всегда последнее.
На других языках наблюдается только бинд/обертки нейтивного плюсового кода.
Слово "стандартный" мог написать только человек, который не в теме наглухо.
P>*я пишу нет — это значит, что нет стандартных и удобных средств и библиотек.
Наоборот, только для плюсов есть всевозможные либы на абсолютно все востребованные направления. Ни для каких других языков такого набора готового функционала нет и не предвидится, ес-но.
P>Так-то в плюсах всё есть. Теоретически.
Фактически.
P>А практически либо переусложнённое, либо настолько раком вывернутое, что можно с уверенностью сказать — практически этого нет.
Без разбора конкретных не устраивающих АПИ популлярных библиотек подобные высказывания являются пустозвонством.
P>Короче полный швах по всем фронтам. Да, есть с++11+14+17, но это смешная капля от того, что надо сделать.
Да, многое надо было делать в нулевых, но тогда было увлечение управляемыми средами. С развитием мобильного сегмента опять вернулись к эффективности вычислений, поэтому, сложившаяся ситуация выглядит логичной. Нелогичным тут может быть лишь ошибочный подход родом из первой половины 2000-х, но ты демонстрируешь именно это. ))
P>По хорошему надо разогнать текущий комитет, сделать ревизию текущего состояния стандарта (убрать все UB и т.п.). И наконец добавить все эти нужные вещи.
Конкретней, плиз. Есть огромный список драфтов для включения в будущие версии. Пройдись по ним и дай нам знать, что конкретно ты имел ввиду.
P>И никаких "n" лет для обсуждения какой-то хрени. Учитывая весь предыдущий опыт, а также перенимая опыт других языков — _всё_ это вполне делается максимум за 1 (_один_) год.
Если ты про включение аудио в стандартную библиотеку, то, повторюсь, ты не в теме абсолютно.
Различные технологии аудио порой отличаются кардинально. Любая попытка привести всё к одному некоему "стандарту" — это будет вредная гиря на ногах для индустрии.
И да, тебе-то, как разработчику, какая нафик разница, идёт ли библиотека, например Cubase ASIO или C++20 std::asio_audio?
P>ПС: но как-бы то ни было, альтернативы плюсам пока что не наблюдается, печалька
Здравствуйте, push, Вы писали:
P>Ну, начнём с того, что я пока не вижу фич, которые поломают обратную совместимость.
Главная совместимость которая ломается современными C++ компиляторами это невозможность работать на WinXP. Нахрена мне ваши фичи если после компиляции оно не будет запустится с криками это не windows приложение. Дело не конкретно winxp, скоро это будет и win7, дело в принципе. Что за мода на цифровое старенее.
P>А если будут ломать — то в чём проблема сделать ключики компиляции? Старые либы, которые ломаются компилить как обычно, а новые фичи будут доступны в либах, скомпиленых с нужным ключиком (как, например в msvs есть ключики для разных версий языка, а можно делать и по другому — вообще только на фичи языка). Проблемы я вообще никакой не вижу.
Современные либы уже во всех вариантах и под все платформы и разные опции компиляции уже сейчас весят безбразно моного гигабайт.
P>А во-вторых, оно уже как бы да — auto, спецификация исключений И ничего, все выжили.
В C был такой синтаксис. Помоему гораздо приятнее чем в C++, где каждому аргументу надо писать тип. Да в коде меньше мусора.
int add(x,y)
int x,y;
{
int z;
z=x+y;
return z;
}
Кстати в C++ нельзя написать auto переменную заранее, только по месту.
Здравствуйте, kov_serg, Вы писали:
_>Главная совместимость которая ломается современными C++ компиляторами это невозможность работать на WinXP.
А при чём тут С++?
_>В C был такой синтаксис. Помоему гораздо приятнее чем в C++, где каждому аргументу надо писать тип. Да в коде меньше мусора.
_>Кстати в C++ нельзя написать auto переменную заранее, только по месту.
Жжошь!
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
_>>Главная совместимость которая ломается современными C++ компиляторами это невозможность работать на WinXP. CC>А при чём тут С++?
Вот и мне интересно. Он тут не просто причем. Это главный инструмент по выпиливанию старого железа.
Ведь компилировать с поддержкой предыдущих систем становиться всё геморройней и дороже. Хотя раньше это было бесплатно и из коробки.
В результате всё больше софта на базовом уровне становятся не совместимыми со старыми ос и железом, т.к. базовые элементы из которых они состоят собираются C++ с использованием сторонних библиотек, которые любят новомодное и компилятор C++latest подавай, а уж они генерируют бинарники которые не будут работать на старых системах.
Получаем механизм цифрового устаревания. Кому от этого хорошо понятно. Но нам то что делать со всем этим. Согласиться и каждый месяц покупать новое по и железо.
Простой пример: cygwin — не на winnt, не на winxp уже не ставиться, хотя раньше всё работало при этом на xp не работает инсталятор, а не сам cygwin.
Если железяка выполняет свои функции то с какого перепоя она устарела. Не модно, не молодёжно — плевать, главное работает и выполняет поставленные задачи.
Если надо модно то есть angular и другие шедевры компилирующие из javascript в javascipt. Может уже пора C++ на webassembly собрать и заморачиваться, отвязаться от ос и привязаться к браузеру.
Я вообще смотрю на это стремление ко всему новому. И не очень понимаю разве не видно что лучше не становиться. КПД использования железа непрерывно падает, несмотря на то что железо становиться всё более изощрённым. Для сравнимых задач теперь требуется в десятки раз больше ресурсов.
В целом мне как-то фиолетово у меня основная ось linux. Но в виртуалке xp работает, и когда софт говорит что эта ось не поддерживается этот софт идёт лесом. Остальные win7 и win10 на виртуалках тоже есть, но они используются по необходимости.
Здравствуйте, Muxa, Вы писали:
M>Как регистронезависимо сравнивать будешь их друг с другом?
Так я в самом начале написал как — через функцию, которая сравнивает без учета регистра.
MTD>>Во-вторых, ты не сможешь использовать методы которые принимают std::string. M>Метод стандартной библиотеки? Можно пример?
Слушай, ну если ты на С++ не пишешь, то зачем в тему влез? Любой конструктор от класса отнаследованного от std::exception, например, std::o[i]fstream
M>Твой собственный метод? Ты автор — пиши метод так чтобы он принимал все что должен принимать.
Вот про это я в самом начале и писал — люди совершенно оторвавшиеся от реальности. Все же хотят вместо:
void print(const std::string& text)
Писать:
template<
class CharT,
class TraitsT,
class AllocT>
void print(const std::basic_string<CharT, TraitsT, AllocT>& text)
Здравствуйте, CreatorCray, Вы писали:
MTD>>Нет, я хочу из коробки кроссплатформенно создать директорию. Это рокет сайнс? CC>Ты не поверишь но для абстрактной платформы в вакууме — да!
Этим аргументам 100 лет в обед и уже тогда они критики не выдерживали. Про треды тоже говорили, что никому не надо, на некоей платформе их может не быть, а потом разум восторжествовал и ввели, жить стало проще. Это все равно, что если у кого-то нет ног, то пусть все ездят в креслах каталках. Нет, у кого есть ноги пусть ходят, а для абстрактной платформы в вакууме это просто не будет работать.
CC>Кроссплатформ в этом плане страшное зло.
Да, ради 0.5 процента где нет файловой системы с директориями должны страдать 99.5%. Правда в комитете, хвала богам, не совсем с этим согласны и таки поддержку добавляют, хоть и криво.
Здравствуйте, CreatorCray, Вы писали:
MTD>>Ты про то, что угара нет? А по моему есть, в 3 раза слить Питону — это надо постараться. CC>А при чём тут С++ к криворуким погромистам? При должной кривизне верхних хваталок можно и в бОльшее колво раз слить.
Ты сейчас на сам божественный Буст наехал — тебя будут ненавидеть.
Здравствуйте, CreatorCray, Вы писали:
MTD>>Мне бы хотелось, чтобы наконец в стандарте появились адекватные средства для этого. Ты против? CC>Да, потому что будет как с другими стандартными всемогутерами: громоздко и неудобно но зато на все случаи жизни. CC>"А клиент хотел просто шину на верёвке" (С) CC>Так что нафиг, уж лучше мы своими специализированными фреймворками будем и дальше пользоваться.
STL ты не используешь? Да и по Бусту ты знатно проехал, один его логгер чего стоит, который никто не использует, потому что не может настроить.
Здравствуйте, CreatorCray, Вы писали:
MTD>>Например, в С++ передали вектор в функцию не по ссылке — получили тормоз. CC>Ну да, С++ требует чтоб аффтар понимал что он делает. CC>Передача по ссылке, по const & и по значению — это ж три кардинально разных use case.
Зачем рукавицы и кожух вокруг диска надеюсь понятно? В С++ можно тупо опечататься — всего один символ не набрать. Страуструп, кстати, вполне адекватный мужик и в Дизайне и эволюции писал, что считает, что копирование по дефолту надо было отключить.
Здравствуйте, AlexGin, Вы писали:
AG>Неадекваты — пытаются на форумах привести абсолютно всё к одной общей гребенке. AG>В той компании где я тогда работал, требовалось выполнить это на PC, в среде ОС Windows, при этом без спец-требований к аппаратуре.
В этом случае я бы взял какую-нибудь проверенную временем фортрановскую библиотеку.
В свое время мы именно так и делали. Все, что требовалось — разобраться с взаимодействием модулей на разных языках. Я тогда не нашел, как обращаться к безымянному COMMON-блоку. Но вменяемые разработчики не делают безымянных COMMON-блоков.
Здравствуйте, MTD, Вы писали:
MTD>Этим аргументам 100 лет в обед и уже тогда они критики не выдерживали. Про треды тоже говорили, что никому не надо, на некоей платформе их может не быть
Да просто надо пользоваться платформенными и не морочить никому голову. Потому что генерализация всегда получается настолько кривая что без слёз не взглянешь, а платформенные полезняшки и вкусности оказываются за бортом и приходится чтоб ими попользоваться городить такой угар что лучше бы сразу писали на платформенных и не выделывались.
Что с потоками что с файлами.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, MTD, Вы писали:
MTD>Ты сейчас на сам божественный Буст наехал — тебя будут ненавидеть.
Я на него уже много лет наезжаю, натрахавшись с их багами и багами в фиксам к багам в своё время.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, MTD, Вы писали:
MTD>STL ты не используешь?
Отказался давно.
Использую STL API compatible контейнеры, которые когда то пришлось написать сначала производительности ради, потом ещё и предсказуемости для.
MTD> Да и по Бусту ты знатно проехал, один его логгер чего стоит, который никто не использует, потому что не может настроить.
Угу, логгер на вариадиках у нас тоже свой имееццо, простой как три копейки и быстрый.
В бусте народ просто забился в Александрескувском экстазе и сделал GENERIC! ВСЁ! ПАРАМЕТРИЗУЕМО!
Давно когда то первое время пытались бороцца выкусывая код из буста и выкидывая излишества, получая порой реальный прирост скорости 2x+
Потом надоело и просто стали писать сразу своё, и под задачу. Оказалось быстрее и менее баговано чем курочить бустовышивания.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, MTD, Вы писали:
MTD>std::o[i]fstream
Без обид, но я лично считаю пользующихся этим ужасом просто профнепригодными.
std streams это один из самых лютых дизайнерских косяков.
MTD>
MTD>template<
MTD> class CharT,
MTD> class TraitsT,
MTD> class AllocT>
MTD>void print(const std::basic_string<CharT, TraitsT, AllocT>& text)
MTD>
Здравствуйте, Privalov, Вы писали:
P>В этом случае я бы взял какую-нибудь проверенную временем фортрановскую библиотеку.
Зачем? Берем интеловскую IPPL, и вуаля.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, alex_public, Вы писали:
_>И всё это (не считая модулей, которые очевидно нельзя реализовать библиотекой) имелось в Boost'е уже много много лет назад (и частично уже переехало в стандарт). Но у тебя же фобия на Boost, поэтому для тебя это реально проблема. ))) Сочувствую. )))
Судя по постам, как и у всех бустофобов, еще и представление о бусте как о чем-то едином-неделимом.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, CreatorCray, Вы писали:
CC>Использую STL API compatible контейнеры, которые когда то пришлось написать сначала производительности ради, потом ещё и предсказуемости для.
Понял, да, есть ряд задач для которых STL не подходит.
CC>В бусте народ просто забился в Александрескувском экстазе и сделал GENERIC! ВСЁ! ПАРАМЕТРИЗУЕМО! CC>Давно когда то первое время пытались бороцца выкусывая код из буста и выкидывая излишества, получая порой реальный прирост скорости 2x+ CC>Потом надоело и просто стали писать сразу своё, и под задачу. Оказалось быстрее и менее баговано чем курочить бустовышивания.
Здравствуйте, 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.
В точке вызова не видно, передаешь ли ты по ссылке или по значению. А если ты зовешь не просто функцию, а хитровывернутый выхлоп какого-нибудь навороченного темплейта, то не видно совсем.
Здравствуйте, MTD, Вы писали:
CC>>Использую STL API compatible контейнеры, которые когда то пришлось написать сначала производительности ради, потом ещё и предсказуемости для. MTD>Понял, да, есть ряд задач для которых STL не подходит.
Да не то чтоб не подходит, для специфических задач да, контейнеры специфические писать приходится, а для большинства применений и обычные нормально ложатся.
Но вот блин вышел парадокс: когда слазили с STL то написали regression performance tests и замену стандартным контейнерам по сути написали как бы алгоритмически неотличимо от STL с на глаз вроде как микроскопическими отличями, больше в стилистике кода чем в алгоритмах, но когда гоняли тесты то в довольно многих их них самописные контейнеры внезапно показали на ровном месте до пары-тройки десятков процентов прироста в скорости. Не сильно было тогда времени изучать как ж так вышло — работы было и так навалом а быстрее этож не медленнее.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, MTD, Вы писали:
CC>>Да просто надо пользоваться платформенными и не морочить никому голову. MTD>В 99% не надо.
В 100% надо не выделываться а пользоваться платформой.
CC>>Потому что генерализация всегда получается настолько кривая что без слёз не взглянешь MTD>Вполне адекватная для большинства случаев, для исключений берешь нативный дескриптор и вперед.
Это для очень примитивного применения, когда похрен на всё, лишь бы прочитать.
CC>>Что с потоками что с файлами. MTD>Хорошо, что в комитете еще есть практики, которые с тобой не согласны.
И кто же эти практики?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, MTD, Вы писали:
MTD>Ой, да ладно, если просто как файл использовать (read/write(char*, size)), то все ок.
А накой тогда streams то?
Да и внутри там местами страшненько.
CC>>Совсем ленивые просто напишут MTD>Что-то не совсем ленивые.
В смысле?
MTD>И сделай из IDE блокнот. Шаблоны — ок, но пихать их везде — лютый бред.
Поэтому typedef наше всио.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, mrTwister, Вы писали:
T>Зачем говорить на русском, если можно придумывать свои собственные слова!
Ты не поверишь, но на каждом проекте, в каждой конторе — есть свой сленг (терминология), где имеются свои англо-русские неологизмы.
И, как показала практика, всё это только идет на пользу проекту.
В хорошей тех-документации обычно имеется раздел, под названием глоссарий — своего рода словарь
Здравствуйте, Pzz, Вы писали:
Pzz>В точке вызова не видно, передаешь ли ты по ссылке или по значению.
IDE покажет. Если не показывает — это не IDE, на помоечку.
Pzz> А если ты зовешь не просто функцию, а хитровывернутый выхлоп какого-нибудь навороченного темплейта
А это уже звоночек что орхетегтуро попахивает какашками. "Не делайте так!" (С)
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, 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>Скорость компиляции должна заметно возрасти
Это довольно мало кого колышет. А вот навигация по коду — очень даже.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, 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, но проверять в точке вызова не будет.
Здравствуйте, CreatorCray, Вы писали:
CC>А в чём проблема то? range for у меня в С++17 прекрасно жрал любые контейнеры, включая самописные.
Не в том дело — до сих аглоритмы требуют итераторы, а не контейнеры. Но наконец-то спохватились, что это тупо. Теперь будут принимать контейнеры + возможно Range библиотеку протащат (подобие LINQ). Но сколько десятилетий спали?
CC>Потоки шмотоки! CreateThread наше всио!
Так и я то том же. Бедный язык, бедные стандартные средства — только API дёргать и остаётся.
P>>4) constexpr — серьёзно? CC>Серьёзно, полезная вещь временами.
А кто спорит? Но почему об этом должен заботиться я, а не компилер?
P>>5) auto — до сих пор не понимаю как фрики пропустили эту вещь. О боже, работу компилятора переложили на компилятор. Почему изначально этого небыло — вопрос века. К с++50 доведут до ума. CC>А что там доводить то? Работает как надо
Ну да, то-то его всё время правят от стандарта к стандарту. Осталось, чтобы ещё везде в шаблонах поддерживался и будет ок.
Здравствуйте, push, Вы писали:
P>С++ имеет одну очеь бедную стандартную библиотеку. И "N" других, не стандартных библиотек с "N" вариантами API. Это проблема.
Это единственный способ хоть как-то двигать технологии.
Любой стандарт — это смерть разума.
V>>Наоборот, только для плюсов есть всевозможные либы на абсолютно все востребованные направления. Ни для каких других языков такого набора готового функционала нет и не предвидится, ес-но. P>Нет _стандартных_ и _удобных_ средств и библиотек
Есть удобные и де-факто задающие тон в своей области.
А кто заикается о стандартах, когда речь о прикладных областх, а не базовых, тот, повторюсь, ни хрена не соображает в тех самых прикладных областях. ))
Потому что это именно и твоя задача тоже — разрабатывать прикладные библиотеки, если ты С++ программист. Например, наша контора живёт разработками библиотек. И таких полно.
M>>То есть приводить строки к нижнему регистру по месту использования, даже если помногу раз для каждой строки. Ну, работать будет. MTD>1. Преждевременная оптимизация зло
Это тут при чем? Чувак из видео прямым текстом сказал: "давайте напишем класс для хранения строк в нижнем регистре", видимо ему этот класс понадобился.
Эдак можно эту универсальную фразу везде пихать, не зная мотивов написания того или иного кода.
Презентация про quick sort — это предварительная оптимизация, есть же bubble sort!
MTD>2. Ты уверен, что умеешь писать быстрый код?
Нет
MTD>Во-первых, ты не знал, что можно сравнивать хеши, что быстрее, чем сравнивать целиком строки.
Ты меня с кем-то путаешь.
M>>Есть перегрузка с const char* — так не интересно. MTD>А мне не интересно везде c_str писать, кроме того,
Никто не обещал что будет интересно.
MTD>есть в стандартной библиотеки методы без перегрузки, например конструктор std::random_device
Зачет, хорошо что этот конструктор выполняется от силы один раз за все время работы приложения.
MTD>>>Вот про это я в самом начале и писал — люди совершенно оторвавшиеся от реальности. Все же хотят вместо: M>>Ааа, так ты в принципе против шаблонов — с этого и надо было начинать. MTD>Это из каких слов ты понял, ткни пальцем.
Из коммента
Здравствуйте, Muxa, Вы писали:
M>Это тут при чем? Чувак из видео прямым текстом сказал: "давайте напишем класс для хранения строк в нижнем регистре", видимо ему этот класс понадобился.
А я уверен, что он ошибается.
M>Презентация про quick sort — это предварительная оптимизация, есть же bubble sort!
Ты не поверишь, но в некоторых случаях bubble sort — оптимизация.
MTD>2. Ты уверен, что умеешь писать быстрый код? M>>>Нет
Зачем тогда так уверенно судишь о том, в чем не разбираешься?
M>Никто не обещал что будет интересно.
Я как любой нормальный разработчик ленив и мне за символы не платят.
M>>>Ааа, так ты в принципе против шаблонов — с этого и надо было начинать. MTD>>Это из каких слов ты понял, ткни пальцем. M>Из коммента
M>>Это тут при чем? Чувак из видео прямым текстом сказал: "давайте напишем класс для хранения строк в нижнем регистре", видимо ему этот класс понадобился. MTD>А я уверен, что он ошибается.
А, ну если ты в курсе для чего было написано именно так, а не иначе — то вопросов нет.
Прост, мне кажется что универсальных решений в программировании нет.
И говорить что XXX всегда лучше чем YYY — неправильно.
M>>Презентация про quick sort — это предварительная оптимизация, есть же bubble sort! MTD>Ты не поверишь, но в некоторых случаях bubble sort — оптимизация.
Поверю. Ключевое слово тут "в некоторых".
MTD>Упоролся чтоли? Я такой код лет 10 назад мог написать, но с тех пор программировать немного научился.
Тогда что ты имел в виду тут http://rsdn.org/forum/flame.comp/6944606.1
Здравствуйте, CreatorCray, Вы писали:
Pzz>>Хороший же это текст программы, что текстовым редактором не берется, а требует специального инструмента. CC>Не ну можешь конечно и камнем шурупы забивать. Но есть таки шуруповёрт с регулируемым усилием. CC>Зачем усложнять себе жизнь ненужными телодвижениями?
Достаточно натянутая аналогия. Если уж на то пошло, шуруп — это язык программирования, а любой достаточно адекватный редактор текстов — это шуроповерт с регулируемым усилием. Но вот оказывается, что некоторым шурупам нужен не шуруповерт, а токарно-ткацкий станок с цифровым програмным управлением, причем работает он не с каждым шурупом, сделанным согласно стандарту на шурупы, а лишь с шурупами определенной фирмы, и требует весь цех организовать под себя, выбирая все прочие инструменты и материалы согласно его требованиям. Да плюс еще, такой шуруп абы во что не закрутишь, дости должны быть той же фирмы да определенной версии.
Pzz>>Скорость компиляции должна заметно возрасти CC>Это довольно мало кого колышет. А вот навигация по коду — очень даже.
Ну вообще-то, C++ компилируется аццки долго. Даже по сравнению с C, не говоря уж о языках, которые действительно быстро компилируются.
Здравствуйте, AlexGin, Вы писали:
AG>Современный C++ здесь не при чём — от слова совсем.
Вы связей не видите. C++ базоый инструмент для остальных остальных инструментов сборки. И если он перестаёт где-то работать все остальные через некоторое время тоже престают работать на данной платформе. А если еще создаются дополнительные плюшка сторонние либы постепенно переходят на новые версии C++. Остальные по зависимостям от этих либ тоже начинает не поддерживать нужную платформу. Так что не только причем, C++ очень хороший рычаг. AG>Берем в MSVC — контекстное меню Properties проекта, там: Configuration Properties/General AG>далее — в строке Platform Toolset выбираем (из комбо-бокса), тулсет совместимый с WinXP.
А потом проверяем на WinXP и улыбаемся.
AG>Современные диски уже не превый год как могут хранить терабайты.
Это развращает. Взлянуть на браузеры или на visual studio этож позор. Далеко ходить не надо в эксплорере при нажатии правой кнопки мыши проискожит лютое мракобесие пред тем как откроется менюшка AG>Время 40-мегабайтных русских AT — давно прошло.
Всякие arduino негодуют.
Здравствуйте, MTD, Вы писали:
MTD>Страуструп, кстати, вполне адекватный мужик и в Дизайне и эволюции писал, что считает, что копирование по дефолту надо было отключить.
В этом я тоже с ним согласен. Но к сожалению это уже не исправить...
Здравствуйте, push, Вы писали:
V>>Конкретней, плиз. Есть огромный список драфтов для включения в будущие версии. Пройдись по ним и дай нам знать, что конкретно ты имел ввиду. P>Да что ж конкретней? Ничего же нет, всё надо — и xml, и сеть, и базы, и IPC человеческое, и RPC, и сериализация, и GUI, .... — короче тупо всё надо.
Т.е. предполагается добавить это всё в поставку компилятора? ) Естественно в виде статических библиотек, скомпилированных под все поддерживаемые данным компилятором архитектуры процессора? Так и представил себе в будущем предложение скачать компилятор C++ в сотню гигабайт... А уж какой размер и разносторонность команды, разрабатывающей такую стандартную библиотеку, будет...
Здравствуйте, push, Вы писали:
P>Не в том дело — до сих аглоритмы требуют итераторы, а не контейнеры. Но наконец-то спохватились, что это тупо. Теперь будут принимать контейнеры + возможно Range библиотеку протащат (подобие LINQ). Но сколько десятилетий спали?
Range — это да, это правильно и удобно (собственно в D подобное от рождения, вместо итераторов). А вот подобная работа с контейнерами уже не логична и я что-то не слышал о планах перехода на подобное.
Здравствуйте, Pzz, Вы писали:
Pzz>Достаточно натянутая аналогия. Если уж на то пошло, шуруп — это язык программирования, а любой достаточно адекватный редактор текстов — это шуроповерт с регулируемым усилием.
Редактор текста это простая отвёртка.
Нормальный же IDE даёт тебе всю нужную информацию прямо по месту, без необходимости пользоваться поиском и менять для этого контекст.
Pzz>Ну вообще-то, C++ компилируется аццки долго.
Меньше буста класть надо и будет компилироваться довольно таки быстро.
Pzz> Даже по сравнению с C, не говоря уж о языках, которые действительно быстро компилируются.
С быстро компилируется но кошмарно медленно и многословно пишется.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, push, Вы писали:
P>Так и я то том же. Бедный язык, бедные стандартные средства — только API дёргать и остаётся.
Ты хочешь странного. Если хочешь язык встроенный в платформу — бери C#
P>А кто спорит? Но почему об этом должен заботиться я, а не компилер?
Наверное потому, что программу пишешь ты, а не компилер.
P>Ну да, то-то его всё время правят от стандарта к стандарту. Осталось, чтобы ещё везде в шаблонах поддерживался и будет ок.
Чот я не помню чтоб с ним на практике какие то проблемы были.
Как только он появился я прошёлся по коду и везде где от него и decltype была польза — повставлял. Завелось сразу, работало как обещали.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Дело не в корпорации, а в самом языке, сильно неудобном для создания фреймворков. Ни ABI с компонентной моделью, ни рефлексии
Любое ABI+рефлексия прибивает оптимизации на корню.
Т.е., надо одновременно выкатывать как рефлексию ср-вами языка, так и способы ею не пользоваться. Дотнет шел к этому более десятка лет, для будущих стандартов С++ такое тоже готовят.
MS делала подобные расширения языка минимум дважды — один раз для COM-объектов, когда можно было не писать отдельные IDL, второй раз в виде C++/CX, с похожим подходом, когда файлы метаинформации генерятся в момент компиляции. Думаю, весь подобный опыт будет учтён.
НС>ни даже стандартных доккомментов.
Это утилитарная задача, которая не требует поддержки со стороны полноценного компилятора.
НС>Ну и отчасти в коммьюнити. Ни в одном другом языке, к примеру, нет такой страсти к переписыванию RTL.
Как минимум в дотнете и джаве наблюдается постоянное переписывание внутренностей базовых либ. Только почему это выдаётся за негатив, а не позитив? В чём плох факт постоянного совершенствования?
Ценность-то имеет человеческий труд, т.е. наши исходники, а они прекрасно обратно совместимы по версиям языка.
Здравствуйте, ononim, Вы писали:
O>У С++ нет комьюнити. Люди просто работают. Без блеска в глазах, подворотов на штанах и всего вот этого вот.
Ага, то-то меня в каждой теме, где я что-то про недостатки С++ или божественного Буста скажу меня обильно минусуют не приводя никаких аргументов. Прям вот как в этой теме. Еще вокруг С++ трется очень много быдла, которое двух слов связать не может, но мнение имеет, как вот это вот существо, например: http://rsdn.org/forum/flame.comp/6944520.1
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Pzz, Вы писали:
Pzz>>Достаточно натянутая аналогия. Если уж на то пошло, шуруп — это язык программирования, а любой достаточно адекватный редактор текстов — это шуроповерт с регулируемым усилием. CC>Редактор текста это простая отвёртка. CC>Нормальный же IDE даёт тебе всю нужную информацию прямо по месту, без необходимости пользоваться поиском и менять для этого контекст.
Простая отвертка — это нотепад.
В студию, кстати, редактор текста-то забыли положить. Очень увлеклись токарно-ткацким станком с ЧПУ.
Pzz>>Ну вообще-то, C++ компилируется аццки долго. CC>Меньше буста класть надо и будет компилироваться довольно таки быстро.
У меня не буст, а Qt. Если бы не Qt, вообще в гробу бы я видел весь этот C++
Pzz>> Даже по сравнению с C, не говоря уж о языках, которые действительно быстро компилируются. CC>С быстро компилируется но кошмарно медленно и многословно пишется.
Я не сказал бы, что C++ лаконичнее C. Скорее, наоборот. Раза в два.
Здравствуйте, Pzz, Вы писали:
Pzz>Простая отвертка — это нотепад.
Нотепад это обломок пластикового ножа которым пытаются выкрутить slot head screw.
Pzz>В студию, кстати, редактор текста-то забыли положить. Очень увлеклись токарно-ткацким станком с ЧПУ.
О чём ты?
Pzz>Я не сказал бы, что C++ лаконичнее C. Скорее, наоборот. Раза в два.
Промышленно пишу на обоих около- и просто системщину всякую. С кошмарно многословен.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, kov_serg, Вы писали:
_>Вы связей не видите. C++ базоый инструмент для остальных остальных инструментов сборки. И если он перестаёт где-то работать все остальные через некоторое время тоже престают работать на данной платформе.
Да, базовый инструмент.
Но ведь никто же не переносил WinAPI в стандарт C++
Так почему же он не должен работать, если у end-user-а стоит Windows XP?
Я ведь не говорю про разработчика, у него (для работы с современной MSVC) дложна быть минимум Windows 7 (SP1).
_>А если еще создаются дополнительные плюшка сторонние либы постепенно переходят на новые версии C++. Остальные по зависимостям от этих либ тоже начинает не поддерживать нужную платформу. Так что не только причем, C++ очень хороший рычаг.
Это рычаг, чтобы девелоперы переходили на современные версии Windows. Конечные пользователи могут сидеть и под Windows XP.
AG>Современные диски уже не превый год как могут хранить терабайты. _>Это развращает. Взлянуть на браузеры или на visual studio этож позор. Далеко ходить не надо в эксплорере при нажатии правой кнопки мыши проискожит лютое мракобесие пред тем как откроется менюшка
Нет, это НЕ РАЗВРАЩАЕТ. Это просто приучает думать масштабнее и не экономить на спичках.
Насчёт указанных тобой выше современных приложений: IMHO на технике более-менее современной они работают вполне адекватно и даже комфортно.
Речь даже не о топовых компах, а об обычном ширпотребе, который ещё не успел морально, да и физически, устареть.
AG>Время 40-мегабайтных русских AT — давно прошло. _>Всякие arduino негодуют.
А кто утверждает, что на эти самые arduino надо тащить всё?
Там, при нормальной разработке, должен быть минимальный run-time, а всё остальное — на верхнем уровне (рабочая станция).
Здравствуйте, CreatorCray, Вы писали:
Pzz>>В студию, кстати, редактор текста-то забыли положить. Очень увлеклись токарно-ткацким станком с ЧПУ. CC>О чём ты?
О том, что собственно редактор текста в студии — паршивый.
Pzz>>Я не сказал бы, что C++ лаконичнее C. Скорее, наоборот. Раза в два. CC>Промышленно пишу на обоих около- и просто системщину всякую. С кошмарно многословен.
Я тоже много на чем пишу, и все промышленно. И тем не менее, остаюсь при своем мнении. C многословен, C++ еще многословнее.
Кстати, слишком лаконичные языки тоже не шибко удобны. Достаточно вспомнить APL, как пример терминально лаконичного языка.
Здравствуйте, vdimas, Вы писали:
V>Любое ABI+рефлексия прибивает оптимизации на корню. V>Т.е., надо одновременно выкатывать как рефлексию ср-вами языка, так и способы ею не пользоваться. Дотнет шел к этому более десятка лет, для будущих стандартов С++ такое тоже готовят.
Непонятно, почему наличие в бинарнике отдельной статической секции, в которую компилятор положит информацию об использованных в программе типах, убъет всю оптимизацию на корню. Собственно, даже секция такая есть, debug info называется, осталось договориться об общепринятом интерфейсе к ее содержимому.
Здравствуйте, CreatorCray, Вы писали:
CC>Ты хочешь странного. Если хочешь язык встроенный в платформу — бери C#
Я хочу элементарного — хоть какой-то инфраструктуры, чай не в 90х уже живём.
CC>Наверное потому, что программу пишешь ты, а не компилер.
И что, я должен делать за него его работу?
P>>Ну да, то-то его всё время правят от стандарта к стандарту. Осталось, чтобы ещё везде в шаблонах поддерживался и будет ок. CC>Чот я не помню чтоб с ним на практике какие то проблемы были. CC>Как только он появился я прошёлся по коду и везде где от него и decltype была польза — повставлял. Завелось сразу, работало как обещали.
Я не о том. Его понемногу добаляют, когда-то добавят во все места (посмотри, например чем auto c++11 отличается от auto c++17). Направление правильное — заставить компилер выполнять свою работу, а вот почему надо ждать н-лет для очевидной штуки мне так и не ясно.
Здравствуйте, alex_public, Вы писали:
_>Т.е. предполагается добавить это всё в поставку компилятора? ) Естественно в виде статических библиотек, скомпилированных под все поддерживаемые данным компилятором архитектуры процессора? Так и представил себе в будущем предложение скачать компилятор C++ в сотню гигабайт... А уж какой размер и разносторонность команды, разрабатывающей такую стандартную библиотеку, будет...
Предлагается поставлять как и std либу. По поводу видов компиляции — всё уже сделано Microsoft в msvs — просто передрать оттуда.
По поводу размера — то, к примеру, сколько там .Net весит? Не так уж и много.
По поводу размера команды — очень небольшая. По сути вся работа уже сделана в сторонних либах и других языках. Чтобы передрать это оттуда с адаптацией под плюсы не потребуется ни много людей, ни много времени. К примеру ментейнеры сейчас просто копируют boost практически без изменений. И у меня большие вопросы по этому поводу — раз делают один в один, то чем занимаются в остальное время, что новые стандарты нужно ожидать годами?
Здравствуйте, push, Вы писали:
P>Здравствуйте, alex_public, Вы писали:
_>>Т.е. предполагается добавить это всё в поставку компилятора? ) Естественно в виде статических библиотек, скомпилированных под все поддерживаемые данным компилятором архитектуры процессора? Так и представил себе в будущем предложение скачать компилятор C++ в сотню гигабайт... А уж какой размер и разносторонность команды, разрабатывающей такую стандартную библиотеку, будет...
P>Предлагается поставлять как и std либу. По поводу видов компиляции — всё уже сделано Microsoft в msvs — просто передрать оттуда. P>По поводу размера — то, к примеру, сколько там .Net весит? Не так уж и много.
Ну можно еще сюда добавить и .Net Natve, там считай тот же компилятор, что и C++ только со сборкой мусора
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vdimas, Вы писали:
V>Это единственный способ хоть как-то двигать технологии. V>Любой стандарт — это смерть разума.
Это верно только для cutting-edge. И тут как раз стандартизация невозможна. Предлагаеся же стандартизация для базовых, устоявшихся вещей. В наше время это уже дико, когда их нет в стандартных инструментах.
V>Потому что это именно и твоя задача тоже — разрабатывать прикладные библиотеки, если ты С++ программист. Например, наша контора живёт разработками библиотек. И таких полно.
Мне более интересно не библиотеки писать, а прикладной софт. И тут, особенно когда нужно возвращаться после C# на плюсы — то отсутствие комфорта особо ощутимо. Особенно на контрасте, когда понимаешь насколько просто это может быть, а вместо — приходится принимать кучу телодвижений.
Здравствуйте, push, Вы писали:
V>>Это единственный способ хоть как-то двигать технологии. V>>Любой стандарт — это смерть разума. P>Это верно только для cutting-edge. И тут как раз стандартизация невозможна. Предлагаеся же стандартизация для базовых, устоявшихся вещей.
Такая стандартизация для устоявшихся и востребованных вещей есть.
Всё остальное — cutting-edge.
Т.е. не включается в стандарт по причине своей активной разработки в настоящее время.
P>В наше время это уже дико, когда их нет в стандартных инструментах.
Дико, когда кто-то не в курсе самих обсуждаемых технологий, но громко высказывается.
Есть прикольное фундаментальное противоречие для технологий навроде аудио-видео. Суть в том, что в одной системе может существовать более одной технологии одного вида. Например, в современных Windows их минимум 4 одновременных технологии аудио в наличии и порядка 4-5 графических технологий. В Linux одновременно живёт 2-3 технологии аудио и столько же графических. Но в язык нельзя включать ни одну из них. Потому что которые уже устоялись, те уже включать поздно, бо этими технологиями для разработки новых приложений не пользуются. А которые находятся в активной разработке, те нельзя включать в стандарт именно по причине активности разработки.
P>Мне более интересно не библиотеки писать, а прикладной софт. И тут, особенно когда нужно возвращаться после C# на плюсы — то отсутствие комфорта особо ощутимо. Особенно на контрасте, когда понимаешь насколько просто это может быть
Я тебе гарантирую, что ты вааще нифига не понимаешь. Чтобы что-то понять, открой рефлектор и посмотри, как много лишних телодвижений делается в дотнете для общения со многими нейтивными технологиями. Напротив, в нейтиве 90% всего того, что происходит в дотнете, банально не надо — пользуйся напрямую. Всё как раз-таки проще на порядки. И у тебя граф обработки данных подчиняется нейтивной же архитектуре (диктуется ею). Слабость же дотнета в том, что он часто пытается "транслировать" графы обработок данных друг в друга, отсюда имеем все эти пляски с контекстом синхронизации и жуткой неэффективностью IO.
Твоё ощущение дискомфорта связано с тем, что ты привык иметь всё необходимое в поставке с фреймворком. Но ты даже не в курсе, где живёт SDK под твой же фреймворк, верно? По-сути, твой каминг-аут именно об этом — о твоей панике, когда нужно попользовать системные SDK или скачать и подключить третьестороннию либу. ИМХО, уважающему себя разработчику в этом месте должно быть стыдно. Тут уже надо прикрыться ветошью и не отсвечивать, а не кричать о своих фобиях на весь интернет. Совсем совесть потеряли, смотрю. ))
P>а вместо — приходится принимать кучу телодвижений.
До NuGet в дотнете нужно было предпринимать столько же телодвижений. Откуда я заключаю, что ты в профессии относительно недавно. А со своим уставом в чужой монастырь не лезут. Пришёл в наш программерский коллектив, изволь соответствовать. Потому что получается так, что ты еще не смотрел даже на пакетные менеджеры под Linux. Потому что NuGet пока не дотягивает до современного удобства линуховых пакетных менеджеров, но изо всех сил пытается. ))
Для нейтива под Windows можно пользовать в том числе NuGet для пакетирования. Но всё более популярным под винды становится шоколадка — калька с линуховых пакетных менеджеров.
Здравствуйте, push, Вы писали:
P>По поводу размера команды — очень небольшая. По сути вся работа уже сделана в сторонних либах и других языках. Чтобы передрать это оттуда с адаптацией под плюсы
С какой еще адаптацией, если наоборот — сторонние либы как раз на С++ сделаны?
P>не потребуется ни много людей, ни много времени. К примеру ментейнеры сейчас просто копируют boost практически без изменений.
Смишно. До того, как объекты из Boost.Thread попали в стандарт, они пережили 4 (ЧЕТЫРЕ, Карл!!!) серьёзные смены архитектуры. И вот когда процесс смен архитектур превратился в затухающий, тогда и добавили наработки в стандарт.
P>И у меня большие вопросы по этому поводу — раз делают один в один, то чем занимаются в остальное время, что новые стандарты нужно ожидать годами?
Я же говорю, ты в профессии недавно.
Четыре, Карл!
Здравствуйте, vdimas, Вы писали:
V>С какой еще адаптацией, если наоборот — сторонние либы как раз на С++ сделаны?
Вот это реально смешно. Что объединяет эти либы: libcurl, openssl, icu, zlib, ffmpeg, openal? Хмм, все это индустриальный стандарт и все они написаны на С. А что же предложило С++ комьюнити в качестве альтернативы? Вопрос риторический.
Здравствуйте, MTD, Вы писали:
MTD>Вот это реально смешно. Что объединяет эти либы: libcurl, openssl, icu, zlib, ffmpeg, openal? Хмм, все это индустриальный стандарт и все они написаны на С. А что же предложило С++ комьюнити в качестве альтернативы? Вопрос риторический.
То вам подавай навороченный С++, то приводите в пример проекты на С, которые как раз являются обратной стороной вот этой медали с навороченностью — не под все архитектуры процов существуют компиляторы с навороченного С++. Забавно, как по мне, на голубом глазу выдвигать противоречивые требования и смотреть на оппонентов — как они будут реагировать на такой беспредел.
Здравствуйте, vdimas, Вы писали:
V>То вам подавай навороченный С++
Ты меня с кем-то путаешь. Я ценю простоту, удобство, надежность.
V>то приводите в пример проекты на С
Я их привел по одной причине — это индустриальный стандарт, на С++ нет ничего подобного, что идет вразрез с твоими словами, что все либы есть на С++.
V>не под все архитектуры процов существуют компиляторы с навороченного С++.
Давай больше конкретики, а то опять начинается разговор про сферического коня в вакууме. Кстати, отличный С++ фреймворк — Qt работает на самых разных железках, даже с древними компиляторами.
V>Забавно, как по мне, на голубом глазу выдвигать противоречивые требования и смотреть на оппонентов — как они будут реагировать на такой беспредел.
Обертки, обертки, обертки, причем местами делающие хуже и добавляющие своих глюков. Где плюсовые проекты такой-же зрелости? Вот так и выходит, что на С++ мы только и заняты тем, что одно оборачиваем в другое.
А вы точно смотрели конференции по другим языка/технологиям? Там точно также обсуждают очередной новый single page application framework, или (о чудо!) появление констант в языке.
MTD>Чувак на полном серьезе рассказыват, что вместо того чтобы пилить класс строк для того чтобы сравнивать строки независимо от регистра, можно написать класс-свойство, который передать в шаблон стандартной строки и который будет переводить строки в нижний регистр перед тем как положить в память, ну и потом можно эти строки сравнивать. Друг, ты совсем что-ли? Может лучше просто написать функцию (а лучше чтобы она была в стандартной библиотеке) compareCaseInsensitivity? Это и проще и в коде сразу понятно, что происходит
Я видео не смотрел, но по слайдам там только половина презентации про char_traits. Может быть вы слишком продвинуты в С++, и многие в аудитории той презентации могли просто не читать Exceptional C++, про решение одной из задач и рассказывает докладчик.
Вторая половина презентации про использование функций из <algorithm> что также уже много лет пишут книги, делают доклады и пишут в блогах.
Короче, мой месседж — я не понял над чем надо угорать.
MTD>Короче, мой месседж — С++ маргинализируется и становится убежищем фриков, на интересы инженеров там положили болт.
Ок. Тогда можно вопрос: какой бы вы выбрали язык для реализации нового проекта с требования кросс-платфроменности и высокой производительности? Скажем, игры-стрелялки от первого лица для PS4/XBox One/PC, или базы данных для новой соцсети, или системы управления автомобилем?
Здравствуйте, PM, Вы писали:
PM>Ок. Тогда можно вопрос: какой бы вы выбрали язык для реализации нового проекта с требования кросс-платфроменности и высокой производительности? Скажем, игры-стрелялки от первого лица для PS4/XBox One/PC, или базы данных для новой соцсети, или системы управления автомобилем?
С++ конечно. Язык нормальный, тут у меня нет вопросов (по большей части), мне нездоровая движуха вокруг него не нравится.
Здравствуйте, Pzz, Вы писали:
Pzz>>>В студию, кстати, редактор текста-то забыли положить. Очень увлеклись токарно-ткацким станком с ЧПУ. CC>>О чём ты? Pzz>О том, что собственно редактор текста в студии — паршивый.
А что там не так то? Вот искренне непонятно.
Pzz>И тем не менее, остаюсь при своем мнении.
Dixi then.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Pzz, Вы писали:
Pzz>Непонятно, почему наличие в бинарнике отдельной статической секции, в которую компилятор положит информацию об использованных в программе типах, убъет всю оптимизацию на корню.
Не это убивает производительность, а изменения в бинаре, которые позволят к любому из этих типов снаружи в любой момент доступаться.
Pzz> Собственно, даже секция такая есть, debug info называется, осталось договориться об общепринятом интерфейсе к ее содержимому.
Ты давно пробовал дебажить релизный бинарь с этими символами?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, MTD, Вы писали:
MTD>Что объединяет эти либы: libcurl, openssl, icu, zlib, ffmpeg, openal?
Спагетти и говнокод внутри?
MTD>А что же предложило С++ комьюнити в качестве альтернативы?
Не мумить себе мозги разбуханием стандартов путём добавления туда всего подряд.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
Pzz>>Непонятно, почему наличие в бинарнике отдельной статической секции, в которую компилятор положит информацию об использованных в программе типах, убъет всю оптимизацию на корню. CC>Не это убивает производительность, а изменения в бинаре, которые позволят к любому из этих типов снаружи в любой момент доступаться.
Ну сама по себе рефлексия будет чего-то стоить. Но я не понимаю, почему остальной код, не использующий рефлексию, должен хоть что-то за это платить.
Pzz>> Собственно, даже секция такая есть, debug info называется, осталось договориться об общепринятом интерфейсе к ее содержимому. CC>Ты давно пробовал дебажить релизный бинарь с этими символами?
Ну вот например у gcc информация, необходимая для раскрутки стека в случае исключения дублирует часть информации, нужной отладчику. Соответственно, в бинарник она кладется в одном экземпляре, и отладчит и рантайм ее используют.
Не понимаю, почему с рефлексией так нельзя поступить.
Это место может и не называться debug info, чтобы нервных барышень не смущать. Я хочу сказать, что вся инфраструктура для его генерации давно имеется.
Похоже, что коммитет по стандартизации до сих пор делает вид, что C++ реализован, как когда-то было при царе Иване Грозном, в виде препроцессора к Си, и использует имеющуюся сишную инфраструктуру. Хотя это давно уже не так.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну сама по себе рефлексия будет чего-то стоить. Но я не понимаю, почему остальной код, не использующий рефлексию, должен хоть что-то за это платить.
Что такое "остальной код" в этом контексте?
Pzz>Ну вот например у gcc информация, необходимая для раскрутки стека в случае исключения дублирует часть информации, нужной отладчику. Соответственно, в бинарник она кладется в одном экземпляре, и отладчит и рантайм ее используют.
Как ты будешь отлавливать в каком месте что лежит по регистрам? А в случае оптимизации jump inside function минуя общую шапку?
Pzz>Похоже, что коммитет по стандартизации
... просто не хочет лезть в детали имплементации.
Потому что стандартизировать такие вещи крайне геморно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
Pzz>>Ну сама по себе рефлексия будет чего-то стоить. Но я не понимаю, почему остальной код, не использующий рефлексию, должен хоть что-то за это платить. CC>Что такое "остальной код" в этом контексте?
Код (а не данные), который не использует рефлексию.
Pzz>>Ну вот например у gcc информация, необходимая для раскрутки стека в случае исключения дублирует часть информации, нужной отладчику. Соответственно, в бинарник она кладется в одном экземпляре, и отладчит и рантайм ее используют. CC>Как ты будешь отлавливать в каком месте что лежит по регистрам? А в случае оптимизации jump inside function минуя общую шапку?
Так же, как осуществляется доступ к членам структуры по указателям.
Pzz>>Похоже, что коммитет по стандартизации CC>... просто не хочет лезть в детали имплементации. CC>Потому что стандартизировать такие вещи крайне геморно.
Ну вообще-то, в коммитете сидят представители контор, которые делают основные компиляторы, и стандарт — это результат торга между ними. Детали имплементации эти люди, разумеется, хорошо знают.
Здравствуйте, Pzz, Вы писали:
Pzz>сидят представители контор, которые делают основные компиляторы, и стандарт — это результат торга между ними. Детали имплементации эти люди, разумеется, хорошо знают.
Я тут как раз с clang чуваками ругаюсь по поводу одного из их нововведений, которое заставляет компилятор втихаря(!) генерить не то, что написал программер а заведомо неверный код, который потом в рантайме у юзеров взрывается.
Они меня лечат что это правильно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Ну я вот такой "неопытный плюсовик" и плевать я хотел, что вы там на своих кошерных языках пилите, поплёвывая с высокой колокольни на нас, "болезных".
Мне тупо платят деньги за мою работу. А переписывать тонны легаси кода только, потому что "у кого-то уже всё круто работает стописят лет на языке XYZ" — мой работодатель не такой дурак.
Разумеется, в команде имеются гораздо более опытные плюсовики, с 10+ лет опыта работы в индустрии, я не один по кнопкам стучу.
Куда стандарту рулить — это определяют ТНК с прибылью в десятки миллиардов (на которые инженеры и работают), через своих представителей, а не только титулованные доктора от компьютер-недосайнс.
Не нравится Буст — не используй. Не нравится C++11/14/17 — не используй.
Просто надо понимать, как работают корпорации на частично монополизированном, но всё ещё супер-конкурентном рынке. Просто так выкидывать армии плюсовиков на улицу, нанимать жабистов-хаскеллистов, говоря заказчику "подождите, мы тут типа апгрейд делаем, приходите через полгодика" — так в крупных конторах не делается. Эксперименты можно только на пилотных проектах ставить, устоявшийся технологический процесс просто так никто в здравом уме не перетрахивает.
Здравствуйте, so5team, Вы писали:
V>>icu -> Boost.Locale S>Дык сам ICU же на C++ написан
Тем более, спасибо, я даже не интересовался этой либой, бо напрямую никогда её не использовал.
S>о чем речь вообще?
О юношеском нигилизме, т.е. о подзадержавшемся пебуртате, когда хочется прям "восстать" против устоявшегося мейнстрима.
В нашей реальности против С++.
Тогда сгоряча можно даже пытаться противопоставлять С и С++. ))
Здравствуйте, CreatorCray, Вы писали:
CC>Я тут как раз с clang чуваками ругаюсь по поводу одного из их нововведений, которое заставляет компилятор втихаря(!) генерить не то, что написал программер а заведомо неверный код, который потом в рантайме у юзеров взрывается. CC>Они меня лечат что это правильно.
У линуха есть три большие компоненты: gcc, ядро и libc. Периодически между ними возникает публичный срач на тему толкования стандартов. Поэтому твое сообщение меня совершенно не удивляет.
Здравствуйте, MTD, Вы писали:
V>>То вам подавай навороченный С++ MTD>Ты меня с кем-то путаешь. Я ценю простоту, удобство, надежность.
Ты высказываешься в той ветке, где С++ ругают за недостаточную навороченность.
MTD>Я их привел по одной причине — это индустриальный стандарт
Индустриальных стандартов много, как и комитетов по стандартизации.
Разумеется, С++ такой же индустриальный стандарт.
MTD>на С++ нет ничего подобного, что идет вразрез с твоими словами, что все либы есть на С++.
Де-факто есть, ссылки я тебе дал.
V>>не под все архитектуры процов существуют компиляторы с навороченного С++. MTD>Давай больше конкретики, а то опять начинается разговор про сферического коня в вакууме.
Ну покажи мне С++ компиляторы под архитектуры PIC, AVR, i51
MTD>Кстати, отличный С++ фреймворк — Qt работает на самых разных железках, даже с древними компиляторами.
За что его и ругают, кстате.
Отличный пример, спасибо.
MTD>Обертки, обертки, обертки, причем местами делающие хуже и добавляющие своих глюков.
В отличие от оберток для других языков, С++ обертки бесплатны. Код С компилируется непосредственно.
Поэтому, не обертка, а импрувмент. ))
MTD>Где плюсовые проекты такой-же зрелости?
Во-первых, "такой же зрелости" — это спекуляции.
Язык С банально старше.
Во-вторых, примеров зрелых С++ проектов овердохрена.
Любые физические движки, любые комплексные аудио+2d+3d фреймворки, типа SDL. Или даже простейшая SFML.
Такие вещи, как KDE, v8, node.js, XUL и прочее — всё ведь на слуху и является сегодня мейнстримом.
Любой законченный, готовый к употреблению фреймворк сегодня плюсовый.
А исключения навроде GTK+ — именно что исключения, по состоянию на сегодня.
Но, опять же, проект GTK начал развиваться тогда, когда С++ был еще во младенчестве.
Т.е. возраст проектов играет не последнюю роль, ес-но.
MTD>Вот так и выходит, что на С++ мы только и заняты тем, что одно оборачиваем в другое.
Ну ты бы сначала вопросом поинтересовался бы, потом выводы делал.
В С++ оборачивается обычно ничтожная часть АПИ любой сишной библиотеки.
Вот только те объекты, которые отвечают за ресурсы, те и оборачиваются, потому что ради RAII.
Но гораздо больше объектов никакого оборачивания не требуют.
Здравствуйте, MTD, Вы писали: V>>Только все-равно нелепость выходит. Неужели ты не в курсе про устоявшийся отродясь способ взаимодействия С/С++? V>>libcurl -> www.curlpp.org V>>icu -> Boost.Locale V>>zlib -> Boost iostream zlib filters V>>OpenGL, OpenAL, OpenES -> OpenGL++, OpenAL++, OpenES++ V>>ffmpeg -> ffmpeg DirectShow filter
MTD>Обертки, обертки, обертки, причем местами делающие хуже и добавляющие своих глюков. Где плюсовые проекты такой-же зрелости? Вот так и выходит, что на С++ мы только и заняты тем, что одно оборачиваем в другое.
А в других языках оно типа не через обёртки сделано, и каким-то магическим образом из сишечки в код на языке Х попадает?
Или нужно непременно, чтобы на плюсах сразу было, без сишечки, и начиная с самого аппаратного драйвера — иначе не по-пацански? Ну DirectX на плюсах изначально был. Он хоть и не промышленный стандарт, как OpenGL, но для геймдева в мире Wintel, на равных шёл с OpenGL, тем более что DirectX готовый для игродела фреймворк, в отличие от OpenGL. Помню, в конце 90х игры иногда даже выходили с реализацией как на OpenGL, так и на Direct3D.
А проекты "сравнимой зрелости" есть, просто они не "чисто айтишные", а нишевые и проприетарные, поэтому тот, кто в этих нишах не работал, просто не мог о них ничего слышать.
То, во что вкладывались деньги в самом начале 2000-х, и что работает до сих пор на плюсах, пилится дальше на плюсах, пока не переведутся плюсовики по приемлемой цене.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Здравствуйте, MTD, Вы писали:
MTD>>Короче, мой месседж — С++ маргинализируется и становится убежищем фриков, на интересы инженеров там положили болт.
SVZ>А альтернативы всё равно нет. SVZ>Можно было бы развивать D, но с ним всё как-то вяло. Может уже издох?
Нет, живой. Более того, корифеи C++ тоже на него переключились.
Здравствуйте, vdimas, Вы писали:
V>Такая стандартизация для устоявшихся и востребованных вещей есть. V>Всё остальное — cutting-edge. V>Т.е. не включается в стандарт по причине своей активной разработки в настоящее время.
Ты в самом деле пытаешься доказать, что чёрное — это белое?))) Ну удачи.
Открываем стандарт, смотрим что стандартизовано. Итого есть:
1) вектор
2) парочка алгоритмов
3) не эффективное io
4) так, по мелочи
5) ой, чуть не забыл — комплексные числа — это самое важное!111
Как бы и всё. Если для тебя то, из чего состоит 99% приложений — cutting-edge, то у меня для тебя плохие новости.
V>Есть прикольное фундаментальное противоречие для технологий навроде аудио-видео...
Ага, то есть в остальных языках есть стандартные средства для работы со звуком-видео без фундаментальных противоречий, а С++ в этом плане импотент. Всё верно? Так и записывать?
V>Откуда я заключаю, что ты в профессии относительно недавно...
До NuGet в дотнете нужно было предпринимать столько же телодвижений...
Да судя, что у тебя ещё не прошёл период снобизма — я явно гораздо дольше тебя в разработке.
Причём тут пакетные менеджеры? Тебе говорят, что надо делать кучу телодвижений для вещей, для которых в других языках вообще ничего делать не надо. Почувствуй разницу.
(А то, что ты открыл для себя пакетные менеджеры — это конечно похвально, но они не походят для текущего состояния плюсов. Смотри, как он должен выглядеть для плюсов — vcpkg. Бери и пользуйся, учу бесплатно. Там ещё много чего надо доделать, это наколенная версия — но идея верная, в отличии от остальных пакетных менеджеров.
Но всё это костыли. Надо менять дизайн языка, нужны модули, надо двигаться в сторону компонентной модели. Надо много чего стандартизировать.)
Здравствуйте, vdimas, Вы писали:
V>С какой еще адаптацией, если наоборот — сторонние либы как раз на С++ сделаны?
Оу, мдааа. Ещё раз посмотри .Net. Вот нужно по тому же сценарию. Развернуть интерфейс либ из положения "раком" в удобное для использования. Адаптировать их к совместному использованию:
1) однообразный подход к проектированию интерфейса
2) отсутствие бесконечного количества промежуточных действий по конвертированию данных из одного формата в другой, чтобы использовать их в другой либе.
Был бы у тебя опыт прикладной разработки, мне бы не приходилось растолковывать очевидные вещи.
V>Смишно. До того, как объекты из Boost.Thread попали в стандарт, они пережили 4 (ЧЕТЫРЕ, Карл!!!) серьёзные смены архитектуры. И вот когда процесс смен архитектур превратился в затухающий, тогда и добавили наработки в стандарт.
Действительно смишно. Приняли 1 в 1 бустовские, заменяешь "boost" на "std" — и вот, готово. И всё равно их надо переделывать.
А требовалось:
1) Сделать удобный интерфейс
2) Сделать биндинги для API
Раньше, когда каждый колхозил свои потоки, это делалось одним человеком за вечер.
Здравствуйте, so5team, Вы писали:
S>Стандартные на уровне ISO-стандарта? Это в каких языках? Можно примеры?
Не все заморачиваются с ISO. Но так есть у всех. Чисто для общего образования почитай про любой современный язык — ты очень удивишься, что там есть и насколько плюсы отстали.
Есть у всех в кого не плюнь: Delphi, C#, Python, Java и т.д. В D вообще есть стандартный пакетный менеджер — считай там всё стандартное.
Здравствуйте, push, Вы писали:
S>>Стандартные на уровне ISO-стандарта? Это в каких языках? Можно примеры?
P>В D вообще есть стандартный пакетный менеджер — считай там всё стандартное.
Здравствуйте, push, Вы писали:
V>>С какой еще адаптацией, если наоборот — сторонние либы как раз на С++ сделаны? P>Оу, мдааа. Ещё раз посмотри .Net. Вот нужно по тому же сценарию. Развернуть интерфейс либ из положения "раком" в удобное для использования.
Не вижу никакого удобства. Вижу прибитие гвоздями к интерфейсам базовой библиотеки. Вижу такое положение дел, что чуть что — слишком много надо делать ручками в дотнете, в отличие от плюсов. Причём, реально много кода получается даже по мелочам. Любая задача в дотнете, для которой нет решения в стандартной либе, требует в несколько раз больше объема исходников, чем в плюсах.
P>1) однообразный подход к проектированию интерфейса
На плюсах уже давно однообразный подход. Просто ты его не понимаешь.
P>2) отсутствие бесконечного количества промежуточных действий по конвертированию данных из одного формата в другой, чтобы использовать их в другой либе.
В какой другой?
Если у тебя файл mp3, а тебе надо позиционировать 3D-звук некоей либой. Разумеется, тебе надо перевести mp3 в сырое представление.
В общем, если ты про данные, то формат данных определяется самими данными, а не АПИ некоей библиотеки. А если ты про оперируемые библиотекой типы, то последние лет 15 библиотеки С++ обычно проектируют так, что они ожидают на входе внешних АПИ не конкретные типы, а концепты. К тому же, легко настраиваемы через typedef, policy и traits. Дотнету такая гибкость и не снилась, разумеется.
P>Был бы у тебя опыт прикладной разработки, мне бы не приходилось растолковывать очевидные вещи.
Ты и не можешь растолковать, бо у тебя пока вообще никакого опыта нет и прилично ты с дотнетом еще не трахался. Если бы ты работал с ним всерьёз, ты бы не писал всей этой чудовищной чуши, сорри.
V>>Смишно. До того, как объекты из Boost.Thread попали в стандарт, они пережили 4 (ЧЕТЫРЕ, Карл!!!) серьёзные смены архитектуры. И вот когда процесс смен архитектур превратился в затухающий, тогда и добавили наработки в стандарт. P>Действительно смишно. Приняли 1 в 1 бустовские
Буст затем и был создан, чтобы обкатывать решения.
Но 4 варианта — это разве не показатель? Похоже, ты не сосредоточился на логике аргументации оппонента. ))
А тот факт, что дотнет постоянно переписывают, потому что то это забудут, то то. То тут АПИ кривое, то там, ы?
То вообще непонятно как обеспечивать совместимость и какой выбрать таржет, если у нас идут подряд сразу 4 плохосовместимые дотнетные версии 4.5.1, 4.5.2, 4.5.3, 4.6?
Так какую из версий АПИ дотнетных либ из перечисленных вкулючать в стандарт, ы?
А какой таржет ты выберешь прямо сейчас?
Вопрос не праздный, а ставящий разработчиков в тупик, и это еще мягко говоря.
В нейтиве проще, там в конечном продукте зависимостей минимум или отсутствуют.
P>А требовалось: P>1) Сделать удобный интерфейс
АПИ в плюсах на многие порядки удобнее дотнетного. Дотнетные АПИ, к большому сожалению, диктуют вполне определённый стиль построения графа объектов в памяти и этот стиль на сегодня является самым неэффективным из всех возможных. В плюсах же у тебя есть выбор.
P>2) Сделать биндинги для API
Это вам надо сделать биндинги, а у нас всё напрямую работает. ))
P>Раньше, когда каждый колхозил свои потоки, это делалось одним человеком за вечер.
Потоки даёт не колхоз, а нижлежащая ОСь
==============
Мде. Страшно далеки они от народа. (С)
Здравствуйте, push, Вы писали: P>Ты в самом деле пытаешься доказать, что чёрное — это белое?))) Ну удачи. P>Открываем стандарт, смотрим что стандартизовано. Итого есть: P>1) вектор P>2) парочка алгоритмов P>3) не эффективное io P>4) так, по мелочи
В дотнетном стандарте CLI тоже был примерно такой же списочек.
Вот уж не ожидал от тебя, что ты будешь путать стандарты с идущими в поставке либами.
MS в поставке даёт довольно-таки внушительный SDK, на котором можно сбацать ПРОИЗВОЛЬНЫЕ приложухи под последние Видны. Причём, такие, которые дотнету и не снились, разумеется.
P>Как бы и всё. Если для тебя то, из чего состоит 99% приложений — cutting-edge, то у меня для тебя плохие новости.
Это у меня для тебя плохие новости — ты умудрился заблудиться в 3-х соснах. ))
V>>Есть прикольное фундаментальное противоречие для технологий навроде аудио-видео... P>Ага, то есть в остальных языках есть стандартные средства для работы со звуком-видео
Нету. Есть только некое жалкое подобие, крайне бедненькое и кривенькое, через которое вообще НИЧЕГО нельзя сделать, ну разве что тупо "бибикнуть" звуковым файлом, да и то, из очень узкого списка его поддерживаемых форматов.
В стандарт С++ такой бред тащить не стоит, разумеется.
С другой стороны, именно в С/С++ живут все самые навороченные современные аудио-фреймворки.
Вот уж точно, ты в пылу спора побежал называть черное белым и наоборот.
Де-факто аудио мейнстрим на сегодня — это DirectShow (угу, там не только видео), VST и AU (под маком).
Это всё компонентные плюсовые технологии.
А на низком уровне для обработки аудио требуется:
— матричные библиотеки
— свертки/FFT/обратные FFT
— забудь про сказанное из предыдущего пункта, на современных файлах импульсной характеристики в реалтайме через FFT не справляется даже мой навороченный комп. Поищи по проблематике "real-time convolution long impulse responses". Требуются более хитрые алгоритмы. Люди их разрабатывают и продают за деньги в виде аудиоплагинов или музыкального софта. Это всё самый что ни на есть cutting eddge, всегда был и будет. А ты хочешь всё это бесплатно в стандарт? Ты хочешь остановить прогресс, я правильно тебя понял? ))
P>без фундаментальных противоречий, а С++ в этом плане импотент. Всё верно? Так и записывать?
Про себя так запиши. Для С++ обязательно идут SDK под платформу, дающие к ней полный доступ. А вот у тебя такого нет, верно? В этом плане ты полный импотент, бо не в состоянии воспользоваться возможностями комьютера.
V>>Откуда я заключаю, что ты в профессии относительно недавно... P>До NuGet в дотнете нужно было предпринимать столько же телодвижений... P>Да судя, что у тебя ещё не прошёл период снобизма — я явно гораздо дольше тебя в разработке.
Нет никакого снобизма, есть ржака не самого высокого полёта. Потому что не по причине чьего-то остроумия, а из-за плохо контролируемой клоунады. Наверно ты именно с этой целью являешься тут полным анонимом, верно? Т.е. чтобы нести вот эту всю херню и совершенно не париться.
Понимаю, очень удобно, нигде не жмёт.
Здравствуйте, mrTwister, Вы писали:
T>Зачем говорить на русском, если можно придумывать свои собственные слова!
Так и придумывают. Целый воз с запада притащили. Кодеры, Менеджеры, Дизайнеры, Девопсы, Тестеры, Имиджмейкеры, Продюсеры, Продакт Плейсмент, Фичи, Баги, Дальше Продолжать?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, push, Вы писали: P>Не все заморачиваются с ISO. Но так есть у всех. Чисто для общего образования почитай про любой современный язык — ты очень удивишься, что там есть и насколько плюсы отстали. P>Есть у всех в кого не плюнь: Delphi, C#, Python, Java и т.д. В D вообще есть стандартный пакетный менеджер — считай там всё стандартное.
Конкретно для высоконадёжного эмбеддед с требованиями реалтайма (любого) из всего этого хлама с натяжечкой можно считать Джаву опробированной технологией, и то только из-за существования спеки RTSJ и существования соотв. ей виртуальных машин, т.е. обычная Джава от Оракла для писюков и серваков уже не прокатит. Да и даже для дешевого ширпотреба. Не зря же Гугловцы свой ДельвигВМ переписали, а то так бы и остался Андроид тормозным УГ.
Здравствуйте, MTD, Вы писали:
MTD>Чувак на полном серьезе рассказыват...
Антон Полухин, конечно, заслуживает уважение за то, что представляет Россию в коммитете по стандартизации, но на этой презентации он только выпендривается и гнёт пальцы, типа какой он крутой, куда бежать. А полезной информации-то — кот наплакал.
Здравствуйте, student__, Вы писали:
__>А в других языках оно типа не через обёртки сделано, и каким-то магическим образом из сишечки в код на языке Х попадает?
Экак ты С++ приложил. Чисто для справки С++ позволяет эффективно взаимодействовать с ОС через нативный для платформы код, ничем не хуже С.
__>Или нужно непременно, чтобы на плюсах сразу было, без сишечки, и начиная с самого аппаратного драйвера — иначе не по-пацански?
Просто направленность сишных либ показывает, что в С сообществе занимаются решением практических вопросов, а сообщество С++ занято в основном написанием нелепыт тормозных велосипедов (Буст).
Здравствуйте, vdimas, Вы писали:
V>Ты высказываешься в той ветке, где С++ ругают за недостаточную навороченность.
Чего? Я начал эту тему и у меня наоборот претензии, что сейчас сообщество увлеклось переусложнением.
V>Индустриальных стандартов много, как и комитетов по стандартизации. V>Разумеется, С++ такой же индустриальный стандарт.
У тебя какая-то каша в голове. Например, никто их не стандартизировал, просто используют все в индустрии, а на С++ сообщество не осилило сделать ничего такого же уровня.
MTD>>на С++ нет ничего подобного, что идет вразрез с твоими словами, что все либы есть на С++.
V>Де-факто есть, ссылки я тебе дал.
На обертки ты дал ссылки, а не на либы. Вот я написал плюсовую обертку над openssl что мне теперь кричать, что я гуру криптографиии и внес огромный вклад?
V>Ну покажи мне С++ компиляторы под архитектуры PIC, AVR, i51
Для них нет компиляторов С++? Это что же ты так решил высказаться, что С++ отстой?
MTD>>Кстати, отличный С++ фреймворк — Qt работает на самых разных железках, даже с древними компиляторами.
V>За что его и ругают, кстате. V>Отличный пример, спасибо.
Конечно, у труЪ модерн С++ разработчиков, бомбит когда кто-то зарабатывает деньги и решает проблемы людей.
V>Ну ты бы сначала вопросом поинтересовался бы, потом выводы делал.
Хочешь длиной меряться? Ну расскажи, что ты на С++ написал.
V>В С++ оборачивается обычно ничтожная часть АПИ любой сишной библиотеки.
Это бессмысленное высказывание, оборачиваю всегда только внешний интерфейс.
Здравствуйте, student__, Вы писали:
__>Конкретно для высоконадёжного эмбеддед с требованиями реалтайма (любого) из всего этого хлама с натяжечкой можно считать Джаву опробированной технологией, и то только из-за существования спеки RTSJ и существования соотв. ей виртуальных машин, т.е. обычная Джава от Оракла для писюков и серваков уже не прокатит. Да и даже для дешевого ширпотреба. Не зря же Гугловцы свой ДельвигВМ переписали, а то так бы и остался Андроид тормозным УГ.
Тут не о том речь. С++ слил абсолютно все ниши, кроме тех, где критична скорость.
Никто в здравом уме сейчас не начинает новые проекты на плюсах. Последее из новых проектов, что лично мне встречалось было в 2008 году. Сейчас все проекты на плюсах — это либо performance critical софт, либо переписывание проектов с дотнета, джавы, питона. Когда бизнес уже построен, отлажен, приносит хорошую прибыль и риски уже не страшны.
Причина этого в дизайне языка, недоразвитости, но в первую очередь — в отсутствии хоть какой-либо стандартной инфрастуктуры.
Это не могут игнорировать уже даже ментейнеры (которые в своё время клали болт вообще на все претензии). И понемногу начинают развивать язык и обогащать стандартную библиотеку.
Сообщение топикстартера было о том, что движение с++ комьюнити принимает фриковские формы. И это факт — достаточно посмотреть презентации к примеру со сходок C# — где люди решают реальные проблемы, и сравнить с презентациями со сходок С++ — где в основном решают проблемы С++.
Я дополнил, что и ментейнеры подвержены влиянию комьюнити, к тому же развитие языка и особенно стандартной библиотеки идёт недопустимо медленными темпами (делают на отвяжись). В наше время такого черепашего развития уже не достаточно, особенно когда ты проспал _всё_
Вот vdimas с этим не согласен, считает что развитие языка и стандартной библиотеки очень вредно и принесёт урон (хотя я уверен, что например когда стандартизируют работу с сетью — он будет пользоваться этим и радоваться). Но аргументировать не может, и это понятно, потому что его посыл не логичен и все современные языки являются примерами того, что он не прав.
Потому он пытается увести раговор на другую тему, либо уйти в частности и крайности.
В данной ветке разговора — что в принципе невозможно иметь стандартных средств для работы со звуком. Я напомнил, что это "невозможно" уже давно реализовано во всех современных языках.
Здравствуйте, vdimas, Вы писали:
V>MS в поставке даёт довольно-таки внушительный SDK V>Для С++ обязательно идут SDK под платформу, дающие к ней полный доступ.
Ага, тоесть ты предлагаешь всё делать на API?
Ты случайно никогда не задумывался по какой причине во всех языках создаются стандартные средства и инфраструктура? Наверное от безделья?
Или к примеру для чего развивают с++ стандартную библиотеку? Или вообще зачем она появилась, ведь есть API и SDK?
V>Есть только некое жалкое подобие, крайне бедненькое и кривенькое
Ну вот наконец мы пришли к тому, что всё же есть.
То, что ты хочешь невозможно в принципе. Но вполне достаточно, когда библиотека покроет основные потребности 90% задач.
V>Наверно ты именно с этой целью являешься тут полным анонимом, верно?
Я не гражданин РФ. Тебя это может шокировать, но во всём остальном мире чтобы жить не нужно носить с собой пасспорт — и это считается нормой.
Здравствуйте, vdimas, Вы писали:
V>Любая задача в дотнете, для которой нет решения в стандартной либе, требует в несколько раз больше объема исходников, чем в плюсах.
В плюсах так же — любая задача, которая отсуствует в стандартной либе требует много кода.
О том и речь, чтобы все основные базовые вещи внести в стандартную библиотеку и радоваться.
V>АПИ в плюсах на многие порядки удобнее дотнетного. Дотнетные АПИ, к большому сожалению, диктуют вполне определённый стиль построения графа объектов в памяти и этот стиль на сегодня является самым неэффективным из всех возможных. В плюсах же у тебя есть выбор.
Про удобство, если сам не видишь, то расспроси кого-нибудь, кто недавно пользует с++, а не провёл за ним полжизни. Узнаешь много интересного про гибкость и удобство с++шных либ.
P>>2) Сделать биндинги для API V>Это вам надо сделать биндинги, а у нас всё напрямую работает. ))
Это ничего, когда-нибудь придёт знание/понимание, что ваше "напрямую" работает через API.
Здравствуйте, push, Вы писали:
P>Тут не о том речь. С++ слил абсолютно все ниши, кроме тех, где критична скорость.
Вы не понимаете. С++ изначально создавался только под те ниши, для которых скорость и ресурсопотребление критичны. Но из-за того, что в промежутке между 1985-1995 мощность компьютеров была вообще никакая, скорость и ресурсоемкость была критична практически везде. Потому-то C++ и пихали куда не попадя. Но потом RAM и CPU стало хватать даже для софта, написанного на Ruby, так что надобность в C++ постепенно пришла в норму и C++ просто-напросто вернулся туда, где и должен был быть изначально.
Здравствуйте, push, Вы писали:
_>>Т.е. предполагается добавить это всё в поставку компилятора? ) Естественно в виде статических библиотек, скомпилированных под все поддерживаемые данным компилятором архитектуры процессора? Так и представил себе в будущем предложение скачать компилятор C++ в сотню гигабайт... А уж какой размер и разносторонность команды, разрабатывающей такую стандартную библиотеку, будет... P>Предлагается поставлять как и std либу.
Ну т.е. вместе с компилятором, правильно? )
P>По поводу видов компиляции — всё уже сделано Microsoft в msvs — просто передрать оттуда.
Что там сделано? Там как раз те самые статические и динамические библиотеки, как и положено. Только одно дело маленькая стандартная библиотека, а другое жирный монстр типа Qt. )
P>По поводу размера — то, к примеру, сколько там .Net весит? Не так уж и много.
Причём тут .net, если мы говорим о C++? Статические библиотеки (т.е. это я ещё не учитываю заголовки, инструменты и т.п.) какой-нибудь Qt под винду занимает где-то 170 МиБ, плюс динамические 60+ МиБ. Это релизные версии (отладочные ещё во много раз больше) и только под одну архитектуру процессора (т.е. умножаем ещё на 2, т.к. надо и 32 и 64 бита). Под OSX и iOS аналогично, но можно обойтись одной архитектурной процессора. А вот под Андроид надо делать от 1 до 6 архитектур в зависимости от целевого охвата платформ. В итоге только на релизной сборке (причём это ещё без заголовков и внутренних тулчейнов, которые у Qt не переиспользуются между сборками) GUI библиотеки мы уже получили более гигабайта. На отладочной сборке будет ещё значительно больше. А в твоём списке "обязательных для поставки вместе с компилятором" библиотек это был всего лишь один из многих пунктов... )))
P>По поводу размера команды — очень небольшая. По сути вся работа уже сделана в сторонних либах и других языках. Чтобы передрать это оттуда с адаптацией под плюсы не потребуется ни много людей, ни много времени.
Вообще то это как раз в других языках берут C/C++ библиотеки, оборачивают их и используют для реализации всех этих задач. Так что "взять из других языков" — это будет очень смешно выглядеть.
P>К примеру ментейнеры сейчас просто копируют boost практически без изменений. И у меня большие вопросы по этому поводу — раз делают один в один, то чем занимаются в остальное время, что новые стандарты нужно ожидать годами?
Насколько я пониманию, 99% времени они занимаются достижением компромисса между сторонниками разных подходов к решению задачи. Если предложение имеющее реальную пользу для языка имеет ровно один вариант реализации, то они принимается быстро и просто. К сожалению таких случаев меньшинство, потому как почти всегда есть конкурирующие варианты.
Здравствуйте, push, Вы писали:
P>Ага, то есть в остальных языках есть стандартные средства для работы со звуком-видео без фундаментальных противоречий, а С++ в этом плане импотент. Всё верно? Так и записывать?
Ну вот расскажи, как мне проиграть свой mp3 (ты же вроде про подобный пример говорил, правильно?) средствами стандартной библиотеки например на Python'е?
Здравствуйте, push, Вы писали:
P>Тут не о том речь. С++ слил абсолютно все ниши, кроме тех, где критична скорость.
Т.е. по сути всего существующего базового ПО, поверх которого уже ложатся различные кастомные пользовательские скрипты...
Вот когда (или правильнее "если"?) появится первый приемлемо работающий браузер, написанный не на C++ (вроде как Mozilla что-то там такое планирует в далёком будущем на Rust'е), то только тогда мы сможем сказать, что у C++ появился первый реальный конкурент и он кому-то что-то сливает.
P>Никто в здравом уме сейчас не начинает новые проекты на плюсах.
P>Сообщение топикстартера было о том, что движение с++ комьюнити принимает фриковские формы. И это факт — достаточно посмотреть презентации к примеру со сходок C# — где люди решают реальные проблемы, и сравнить с презентациями со сходок С++ — где в основном решают проблемы С++.
Ты похоже просто не понимаешь разницу в задачах. На каком-нибудь там C# или JS решают "реальную проблему" удобной генерации формочек. А на C++ решают проблему, что бы этот самый C# или JS код собственно запустился и выполнился. )))
P>Я дополнил, что и ментейнеры подвержены влиянию комьюнити, к тому же развитие языка и особенно стандартной библиотеки идёт недопустимо медленными темпами (делают на отвяжись). В наше время такого черепашего развития уже не достаточно, особенно когда ты проспал _всё_
Я согласен, что лучше бы развиваться побыстрее. Правда не в области стандартной библиотеки (это вообще не особо нужно, т.к. всегда можно взять тот же Boost), а в области самого языка (к примеру статической интроспекции крайне не хватает в языке и её легко можно было добавить ещё несколько лет назад, по образцу языка D). Но т.к. реальных конкурентов у языка всё равно пока нет, то...
Здравствуйте, alex_public, Вы писали:
_>Ты похоже просто не понимаешь разницу в задачах. На каком-нибудь там C# или JS решают "реальную проблему" удобной генерации формочек. А на C++ решают проблему, что бы этот самый C# или JS код собственно запустился и выполнился. )))
Ну вот с выходом .NetStandard 2, UWP .Net Native его будет больше. И выполняется он без CLR, только сборщик мусора, который занимает mrt100_app.dll 317608 байт. Вот для неё и нужен C++
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, push, Вы писали:
V>>MS в поставке даёт довольно-таки внушительный SDK V>>Для С++ обязательно идут SDK под платформу, дающие к ней полный доступ. P>Ага, тоесть ты предлагаешь всё делать на API?
На плюсовом АПИ, заметь. Современные аудио-АПИ плюсовые.
P>Ты случайно никогда не задумывался по какой причине во всех языках создаются стандартные средства и инфраструктура?
Потому что им недоступно непосредственное АПИ?
Потому что сами эти языки содержат внушительный список ограничений, которым должно удовлетворять предоставляемое им АПИ?
P>Наверное от безделья?
От беспомощности. Наверно поэтому "во всех языках" никаких вменяемых ср-в для аудио, видео и графики банально НЕТ.
Не существует в природе. Ты тупо бредишь. ))
Всё это живет исключительно и только в С/С++.
К слову. Единичные эксперименты на rust в последние пару лет — это именно что "проверка" самого языка, т.е. его возможностей, а не показатель того, что мода разрабатывать все эти вещи стала двигаться куда-то в другую сторону. Не стала и не предвидится.
P>Или к примеру для чего развивают с++ стандартную библиотеку? Или вообще зачем она появилась, ведь есть API и SDK?
А зачем ты задаёшь глупые вопросы? Действительно ли другой коллега должен объяснять тебе отличие узкоприкладных ср-в от широких-общих, типа базовых структур данных, строк, алгоритмов сортировки/поиска и т.д.?
V>>Есть только некое жалкое подобие, крайне бедненькое и кривенькое P>Ну вот наконец мы пришли к тому, что всё же есть.
Нету. Язык ВО — это инструмент в руках программиста. А то, что есть в других языках из обсуждаемой области — это не инструмент ни разу. Это муляж, ни для чего не пригодный. И это не от того, что в тех языках нельзя создать полноценный инструмент, ес-но. Можно. Просто сами эти языки не годятся для обсуждаемой предметной области. По крайней мере такова ситуация на сейчас. Попытки пилить матан на дотнете были, особенно в середине 2000-х. Были попытки решать на ём все задачи подряд... Не взлетело... В общем, глупый разговор ты устроил. Все вокруг прекрасно в курсе, почему ситуация такова, какая она есть, и только ты бегаешь аки удивлённое создание, в первый раз увидевший белый свет.
P>То, что ты хочешь невозможно в принципе. Но вполне достаточно, когда библиотека покроет основные потребности 90% задач.
Ты еще и склонен себя обманывать?
Де-факто не покрывает потребностей и 1% задач.
По крайней мере музыкальных программ на дотнете менее 1% от общей их массы, где вся эта масса сугубо нейтивная.
V>>Наверно ты именно с этой целью являешься тут полным анонимом, верно? P>Я не гражданин РФ. Тебя это может шокировать, но во всём остальном мире чтобы жить не нужно носить с собой пасспорт — и это считается нормой.
Это уже какой-то анонизм в квадрате (от слова аноним, а не онаний). Мне всегда казалось, что будучи анонимом необязательно выкручиваться с целью сохранения "лица", бо лица-то нет? )) Можно же просто "идите в сад" и всех делов, не? Это уж всяко лучше, чем пороть чушь про паспорта.
Здравствуйте, push, Вы писали:
V>>Любая задача в дотнете, для которой нет решения в стандартной либе, требует в несколько раз больше объема исходников, чем в плюсах. P>В плюсах так же — любая задача, которая отсуствует в стандартной либе требует много кода.
Всё в мире относительно.
По сравнению с дотнетом на последних плюсах надо от 5 до 30 раз меньше кода (чем больше комбинаторики типов в решении, тем чудовищней отрыв).
Сюрпрайз!!!
А если посмотреть сюда: http://www.rsdn.org/forum/cpp/6948363.1
То через пяток лет отрыв будет раз в 50-100 или больше.
Здравствуйте, MTD, Вы писали:
MTD>В ветках С++ тоска — изредка правда встречаются фрики, которые не имея опыта пилят странные велосипеды, что доставляет массу веселья, да 3 с половиной опытных плюсовиков немножко оторвавшихся от реальности. О подобных персонажах и тенденциях развития С++ и хочется поговорить.
Интересно, чем вызвано такое желание? Если ты уверен в том, что говоришь, то зачем тебе это с кем-то обсуждать?
MTD>Короче, мой месседж — С++ маргинализируется и становится убежищем фриков, на интересы инженеров там положили болт.
И, словно в насмешку над самим собой, приводишь пример, где С++ делает C# в 3 раза, а питон в 6. Ты как-то выпустил из виду, что fmtlib — это тоже C++ А на задачах, насыщенных более-менее сложными вычислениями (векторно-матричными, например), разница в производительности может быть гораздо более существенной.
В каждом языке есть свои сильные и слабые стороны и настоящий профессионализм — это умение сочетать их, а не противопоставлять. Наезды на сложность кода и диагностики не новы, по-моему трудно найти более избитую тему. И для опытного плюсовика эти наезды звучат не иначе как "ниасилил".
Здравствуйте, rg45, Вы писали:
R>В каждом языке есть свои сильные и слабые стороны и настоящий профессионализм — это умение сочетать их, а не противопоставлять. Наезды на сложность кода и диагностики не новы, по-моему трудно найти более избитую тему. И для опытного плюсовика эти наезды звучат не иначе как "ниасилил".
Я понимаю, что все новшевста в стандарте ты считаешь неоспоримыми достоинствами. Но даже Страуструп в недавнем интервью сказал, что в комитете есть трения насчет того, что одни хотят добавить в стандарт сложные навороты вроде шаблонов, которые нужны только авторам boost, а другие за язык для обычных программистов(в широком смысле).
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
R>>В каждом языке есть свои сильные и слабые стороны и настоящий профессионализм — это умение сочетать их, а не противопоставлять. Наезды на сложность кода и диагностики не новы, по-моему трудно найти более избитую тему. И для опытного плюсовика эти наезды звучат не иначе как "ниасилил".
lpd>Я понимаю, что все новшевста в стандарте ты считаешь неоспоримыми достоинствами.
Откуда такой вывод? Прочитай еще раз, что я пишу: "в каждом языке есть свои сильные и слабые стороны".
lpd>Но даже Страуструп в недавнем интервью сказал, что в комитете есть трения насчет того, что одни хотят добавить в стандарт сложные навороты вроде шаблонов, которые нужны только авторам boost, а другие за язык для обычных программистов(в широком смысле).
Вполне естественно, что кто-то старается проталкивать свои интересы — такова человеческая природа, ничего тут не поделаешь. В то же время есть и другие участники, которые их уравновешивают противоположными усилиями. В результате есть надежда, что равновесие будет достигнуто где-то в районе здравого смысла.
Здравствуйте, rg45, Вы писали:
R>Интересно, чем вызвано такое желание?
С++ — мой основной инструмент, мне не нравится, что с ним происходит.
R>Если ты уверен в том, что говоришь, то зачем тебе это с кем-то обсуждать?
А зачем вообще этот форум, особенно ветка КСВ? Чтобы общаться, вот я и общаюсь. Если тебе обменяться мнениями не интересно, а хочется сразу на мою персону переключиться, то не тяни — сэкономим время.
MTD>>Короче, мой месседж — С++ маргинализируется и становится убежищем фриков, на интересы инженеров там положили болт.
R>И, словно в насмешку над самим собой, приводишь пример, где С++ делает C# в 3 раза, а питон в 6. Ты как-то выпустил из виду, что fmtlib — это тоже C++
Так, видимо я слишком сложно выразился, объясняю: С++ позволяет получить самый быстрый код, автор fmtlib не стал усложнять — получилась простая, компактная и производительная библиотека, в отличии от Буст.
R>В каждом языке есть свои сильные и слабые стороны и настоящий профессионализм — это умение сочетать их, а не противопоставлять.
Еще раз — С++ хороший язык, с точки зрения практика, мне не нравится тенденция переусложнять и уходить в астрал (пример — Буст).
R>И для опытного плюсовика эти наезды звучат не иначе как "ниасилил".
Если хочется сразу на мою персону переключиться, то не тяни — сэкономим время.
Здравствуйте, MTD, Вы писали:
MTD>Еще раз — С++ хороший язык, с точки зрения практика, мне не нравится тенденция переусложнять и уходить в астрал (пример — Буст).
Ну так о бусте бы и говорил сразу, зачем же обобщать на весь язык? Да и буст ведь он очень большой, при таких масштабах было бы странно, если бы в нем нельзя было найти чего-то, к чему можно докопаться. Ставить крест на всем бусте (а тем более, на всем языке) на основании какого-то частного примера, пусть даже двух — тут прямо сквозит какой-то предвзятостью.
R>>И для опытного плюсовика эти наезды звучат не иначе как "ниасилил". MTD>Если хочется сразу на мою персону переключиться, то не тяни — сэкономим время.
Я имел ввиду не конкретно тебя, а весьма распространенные нападки на C++. Извини, если задел.
Здравствуйте, alex_public, Вы писали:
_>Ну т.е. вместе с компилятором, правильно? )
можно побить на либы и отдельно, вообще не вижу проблем
_>Причём тут .net, если мы говорим о C++? Статические библиотеки (т.е. это я ещё не учитываю заголовки, инструменты и т.п.) какой-нибудь Qt под винду занимает где-то 170 МиБ, плюс динамические 60+ МиБ. Это релизные версии (отладочные ещё во много раз больше) и только под одну архитектуру процессора (т.е. умножаем ещё на 2, т.к. надо и 32 и 64 бита). Под OSX и iOS аналогично, но можно обойтись одной архитектурной процессора. А вот под Андроид надо делать от 1 до 6 архитектур в зависимости от целевого охвата платформ. В итоге только на релизной сборке (причём это ещё без заголовков и внутренних тулчейнов, которые у Qt не переиспользуются между сборками) GUI библиотеки мы уже получили более гигабайта. На отладочной сборке будет ещё значительно больше. А в твоём списке "обязательных для поставки вместе с компилятором" библиотек это был всего лишь один из многих пунктов... )))
Я не понял в чём проблема. Для конкретной платформы берёш конкретную версию. Если делаешь кросс-компиляцию, то ещё и под все целевые платформы.
Или ты о том, что под все целевые платформы будет много весить? Ну дык если оно надо — то надо.
_>Насколько я пониманию, 99% времени они занимаются достижением компромисса между сторонниками разных подходов к решению задачи. Если предложение имеющее реальную пользу для языка имеет ровно один вариант реализации, то они принимается быстро и просто. К сожалению таких случаев меньшинство, потому как почти всегда есть конкурирующие варианты.
Ну так и я о том же. 99% времени идёт торг — занимаются непонятно чем. А итоговый выхлоп более чем скромен по сравнению с затраченным на это временем.
Здравствуйте, alex_public, Вы писали:
_>Ну вот расскажи, как мне проиграть свой mp3 (ты же вроде про подобный пример говорил, правильно?) средствами стандартной библиотеки например на Python'е?
Здравствуйте, vdimas, Вы писали:
P>>Ага, тоесть ты предлагаешь всё делать на API? V>На плюсовом АПИ, заметь. Современные аудио-АПИ плюсовые.
Ну я вижу насколько популярна разработка чисто на API.
V>Потому что им недоступно непосредственное АПИ?
Да все имеют доступ к API. Не имеют желания на нём работать.
V>От беспомощности. Наверно поэтому "во всех языках" никаких вменяемых ср-в для аудио, видео и графики банально НЕТ.
Ok, закрываем глаза и считаем, что раз не видно — то и нет.
V>А зачем ты задаёшь глупые вопросы? Действительно ли другой коллега должен объяснять тебе отличие узкоприкладных ср-в от широких-общих, типа базовых структур данных, строк, алгоритмов сортировки/поиска и т.д.?
А также остальных базовых средств: log, process, IPC, xml, net, RPC и т.д. Действительно! И почему мне приходится это объяснять?)))
V>>>Есть только некое жалкое подобие, крайне бедненькое и кривенькое P>>Ну вот наконец мы пришли к тому, что всё же есть.
V>Нету. Язык ВО — это инструмент в руках программиста. А то, что есть в других языках из обсуждаемой области — это не инструмент ни разу. Это муляж, ни для чего не пригодный.
Ты можешь как угодно это называть, но реальность такова, что на них приложение делается в несколько раз быстрее, проще и меннее проблемно в поддержке. Именно из-за инфраструктуры языка. И этот, ни для чего не годный муляж, выгнал плюсы с большинства денежных мест.
V>Это уже какой-то анонизм в квадрате (от слова аноним, а не онаний). Мне всегда казалось, что будучи анонимом необязательно выкручиваться с целью сохранения "лица", бо лица-то нет? )) Можно же просто "идите в сад" и всех делов, не? Это уж всяко лучше, чем пороть чушь про паспорта.
OMG)))) За всю мою жизнь ты второй кадр после яндекса, которому я что-то "обязан" в интернете. Хах, даже угадал, что вы оба с одних краёв.
Ну если хочешь, можешь плюнуть в мой ник — даже не обижусь.
Здравствуйте, so5team, Вы писали:
S>Вы не понимаете. С++ изначально создавался только под те ниши, для которых скорость и ресурсопотребление критичны. Но из-за того, что в промежутке между 1985-1995 мощность компьютеров была вообще никакая, скорость и ресурсоемкость была критична практически везде. Потому-то C++ и пихали куда не попадя. Но потом RAM и CPU стало хватать даже для софта, написанного на Ruby, так что надобность в C++ постепенно пришла в норму и C++ просто-напросто вернулся туда, где и должен был быть изначально.
Вообщето нет. С++ создавался для увеличения производительности программиста на С, по возможности сохраняя эффективность насколько это возможно. Страуструп сам пишет об этом в предисловии своей книги.
Если бы он создавался для скорости — то как минимум по умолчанию копирования небыло, не было бы и виртуальных функций, исключений, RTTI.
С++ позиционировался как язык общего назначения. Повторюсь, Старутруп сам пишет об этом в предисловии.
Когда RAM и CPU стало хватать — другие языки начали развиваться и откусывать области применения. Когда Delphi налегке отхватил самый смачный шмат чисто за счёт инфраструктуры и стандартных средств — то уже надо было срочно начинать вращать лапами.
Но нет, спали. Java спокойно и уверенно выметала плюсы из всех областей, C# махал на прощание платочком.
Вот и получилось, что С++ скукожили лишь до ресурсокритичных ниш. Но тут тоже сюрпрайз. Какими-ни какими темпами но язык С тоже развивается и поддавливает плюсы с другой стороны. Основные библиотеки успешно пишуться на С, иногда даже есть смысл переписать изначально плюсовую библиотеку на С (zeromq -> nanomq).
А учитывая, что критически вайжные задачи не велики по объёму и занимают совсем немного рынка по сравнению с большинством задач, то плюсам нужно уже не только вращать лапами, но и махать плавниками, хвостом и х...(ладно, опустим рифму).
Здравствуйте, push, Вы писали:
S>>Вы не понимаете. С++ изначально создавался только под те ниши, для которых скорость и ресурсопотребление критичны. Но из-за того, что в промежутке между 1985-1995 мощность компьютеров была вообще никакая, скорость и ресурсоемкость была критична практически везде. Потому-то C++ и пихали куда не попадя. Но потом RAM и CPU стало хватать даже для софта, написанного на Ruby, так что надобность в C++ постепенно пришла в норму и C++ просто-напросто вернулся туда, где и должен был быть изначально.
P>Вообщето нет. С++ создавался для увеличения производительности программиста на С, по возможности сохраняя эффективность насколько это возможно. Страуструп сам пишет об этом в предисловии своей книги.
Страуструпу нужен был язык, сочетающий мощность Simula 67 и эффективность C. Поскольку он делал программу на Simula 67, но она работала слишком медленно и ее пришлось переписывать на BCPL. Про "увеличение производительности программиста на С" речи не было, т.к. сам C был взят исключительно из утилитарных соображений.
P>Если бы он создавался для скорости — то как минимум по умолчанию копирования небыло, не было бы и виртуальных функций, исключений, RTTI.
Тем не менее, он создавался для скорости. Копирование по умолчанию нужно было для унификации системы типов, чтобы поведение объекта пользовательского типа A не отличалось от поведения экземпляра какого-нибудь int-а или double. За счет этой унификации шаблоны в C++ получились настолько мощными. Исключения и RTTI добавились несколько позже. Виртуальные функции не тормозят, т.к. там, где они нужны, тормозить будет и все остальное. Кроме того, C++ давным-давно позволяет иметь полиморфизм и без виртуальных функций.
P>С++ позиционировался как язык общего назначения. Повторюсь, Старутруп сам пишет об этом в предисловии.
Язык общего назначения не может создаваться под ниши с повышенными требованиями к ресурсоемкости и производительности? OK.
P>Когда RAM и CPU стало хватать — другие языки начали развиваться и откусывать области применения.
Это стало означать лишь, что ниши высокопроизводительных и ресурсоемких приложений скукожились естественными путем. Как это произошло с гужевым транспортом после появления и развития автомобилей.
P>Но нет, спали. Java спокойно и уверенно выметала плюсы из всех областей, C# махал на прощание платочком.
Здравствуйте, push, Вы писали:
P>>>Ага, тоесть ты предлагаешь всё делать на API? V>>На плюсовом АПИ, заметь. Современные аудио-АПИ плюсовые. P>Ну я вижу насколько популярна разработка чисто на API.
Из своего болота тебе ничего не может быть видно.
V>>Потому что им недоступно непосредственное АПИ? P>Да все имеют доступ к API.
Не имеют.
Потому что производители технологий дают АПИ для С/С++.
Для других языков надо писать обертки.
P>Не имеют желания на нём работать.
Разумеется. Мультимедию надо окучивать из сурового нейтива.
V>>От беспомощности. Наверно поэтому "во всех языках" никаких вменяемых ср-в для аудио, видео и графики банально НЕТ. P>Ok, закрываем глаза и считаем, что раз не видно — то и нет.
Ну я-то смотрел подробно, в отличие от.
Первые кое-какие ср-ва для мультимедиа появились в сервелате, но это было курам на смех.
В дотнете вообще ничего из этой области нет.
Ну вот разве что под WinRT/UWP для дотнета сделали более-менее обертки для нейтивной подсистемы WinRT API.
P>А также остальных базовых средств: log, process, IPC, xml, net, RPC и т.д. Действительно! И почему мне приходится это объяснять?)))
Это лог-то базовый?
Здрасьте.
В различных сценариях логгеру предъявляются порой противоречивые требования.
Про XML вообще смишно. Напомню, что в этой реальности AJAX впервые получил развитие через использование плюсовой COM msxml.dll.
Это уже потом остальные платформы и браузеры подтянулись, а теперь это стандарт де-факто.
Просто на плюсах не заворачивают в дебильный XML то, что туда явно не лезет. Конечно, на плюсах используют XML аж бегом, но не так упорото, как в Джаве и дотнете. Потому что малость другие подходы. Можно и парсер конфига нарисовать или свой текстовый или бинарный протокол. Это в духе нейтива, бо в нём удобно парсить и генерить строки.
Ну и, в 90% случаев, когда в дотнете используют XML, авторов надо пожизненно отлучать от клавиатуры. За тот самый инженерный идиотизм.
V>>Нету. Язык ВО — это инструмент в руках программиста. А то, что есть в других языках из обсуждаемой области — это не инструмент ни разу. Это муляж, ни для чего не пригодный. P>Ты можешь как угодно это называть, но реальность такова, что на них приложение делается в несколько раз быстрее
Ты бредишь.
Только самая базовая функциональность подобных приложений в дотнете делается примерно с той же скоростью, как в нейтиве (просто бибикнуть файлом). А за пределами самой базовой функциональности, суммарная трудоёмкость на дотнете начинает резко приближаться к бесконечности, а в нейтиве всё продолжает развиваться более чем легко.
Ну и разработка на дотнете медленная, увы.
Она может давать буст только за счёт, например, визуальных редакторов UI.
Как только начинаешь лепить тот же UI ручками, так сразу никакого отрыва даже в GUI.
Всё остальное даже обсуждать лень.
Там, где в нейтиве надо десяток строк, там в дотнете сотни их на ровном месте.
Параметр шаблона как базовый класс задать нельзя, делегаты не совместимы по типам, даже когда совместимы по сигнатурам. При агрегировании ручками расписываешь делегирования и куча подобного бреда. Посмотри любопытства ради вот эту либу: http://www.rsdn.org/forum/prj.codejam
В C++ ничего из того, что в ней есть, не нужно.
Потому что изкаробки всё есть.
А в дотнете каждый чих надо херачить вручную.
Единственно что более-менее можно делать в дотнете — это макетирование.
Но как более-менее вырисовывается большое приложение и приличная уникальная функциональность, которую расписывать надо самому — так это застрелиться, сломаешь пальцы, сколько кода надо фигачить.
P>проще и меннее проблемно в поддержке.
Более проблемно в реализации.
Не покупают.
Это работа "в стол", никому не нужная.
Проще тебе там или не проще — это твои проблемы.
P>Именно из-за инфраструктуры языка.
В языке там полная ж-па.
Я периодически прохожусь по косякам, но ради тебя не буду. Ты слишком поверхностен. Живешь мифами 20-тилетней давности. В кач-ве аргументации не паришься приводить в пример всякий бред, о котором не имеешь ни малейшего понятия.
P>И этот, ни для чего не годный муляж, выгнал плюсы с большинства денежных мест.
Во-во. Бредим, не приходя в сознание.
Коробочные дотнетные проги в нашей реальности НЕ ПРОДАЮТСЯ, за очень малым исключением.
Например, MS Visual Studio продаётся, как мне недавно напомнили, ы-ы-ы.
P>OMG)))) За всю мою жизнь ты второй кадр после яндекса, которому я что-то "обязан" в интернете. Хах, даже угадал, что вы оба с одних краёв.
Лучше бы ты догадался о своей упоротости.
Отличительная черта упоротых свидомых — это крайнее неуважение к самим себе, собеседнику, своим же соотечественникам и вообще ко всем. Сплошное из грязи в грязи в кач-ве послевкусия после общения.
P>Ну если хочешь, можешь плюнуть в мой ник — даже не обижусь.
О чём и речь. Вот такое позиционирование самого себя.
Наверно, мир еще не видел настолько нетребовательных к себе людей, навроде упоротых свидомых. Это просто какая-то тяжёлая эпидемия. Но пациентов она не парит.
Здравствуйте, push, Вы писали:
_>>Ну т.е. вместе с компилятором, правильно? ) P>можно побить на либы и отдельно, вообще не вижу проблем
Т.е. ты по сути просто за некую что ли стандартизацию популярных C/C++ библиотек, без переноса их в стандартную библиотеку языка? )
_>>Причём тут .net, если мы говорим о C++? Статические библиотеки (т.е. это я ещё не учитываю заголовки, инструменты и т.п.) какой-нибудь Qt под винду занимает где-то 170 МиБ, плюс динамические 60+ МиБ. Это релизные версии (отладочные ещё во много раз больше) и только под одну архитектуру процессора (т.е. умножаем ещё на 2, т.к. надо и 32 и 64 бита). Под OSX и iOS аналогично, но можно обойтись одной архитектурной процессора. А вот под Андроид надо делать от 1 до 6 архитектур в зависимости от целевого охвата платформ. В итоге только на релизной сборке (причём это ещё без заголовков и внутренних тулчейнов, которые у Qt не переиспользуются между сборками) GUI библиотеки мы уже получили более гигабайта. На отладочной сборке будет ещё значительно больше. А в твоём списке "обязательных для поставки вместе с компилятором" библиотек это был всего лишь один из многих пунктов... ))) P>Я не понял в чём проблема. Для конкретной платформы берёш конкретную версию. Если делаешь кросс-компиляцию, то ещё и под все целевые платформы. P>Или ты о том, что под все целевые платформы будет много весить? Ну дык если оно надо — то надо.
Сейчас проблем никаких нет, т.к. каждый разработчик (ну или там команда) создаёт свою собственную коллекцию необходимых им библиотек, собранных под нужные им платформы. А вот если собрать все эти возможные варианты со всего мира в единую огромную библиотеку, то мы уже получим проблему, многогигабайтную)))
Ну и кстати дело даже не столько в размере (в конце концов мы сейчас качаем фильмы по 50 ГиБ, на терабайтные диски), сколько в самой ущербности подобной модели.
_>>Насколько я пониманию, 99% времени они занимаются достижением компромисса между сторонниками разных подходов к решению задачи. Если предложение имеющее реальную пользу для языка имеет ровно один вариант реализации, то они принимается быстро и просто. К сожалению таких случаев меньшинство, потому как почти всегда есть конкурирующие варианты. P>Ну так и я о том же. 99% времени идёт торг — занимаются непонятно чем. А итоговый выхлоп более чем скромен по сравнению с затраченным на это временем.
Думаю с этим тут никто и не спорит. Все хотели бы более быстрого развития и у каждого есть свой список "самых важных хотелок" в язык. ))) Но такова реальность...
Здравствуйте, push, Вы писали:
_>>Ну вот расскажи, как мне проиграть свой mp3 (ты же вроде про подобный пример говорил, правильно?) средствами стандартной библиотеки например на Python'е? P>Именно за mp3 не скажу так как этого не касался. А то, что там в стандартной либе есть средства для работы со звуком — так вот: https://docs.python.org/3/library/index.html
Ну давай посмотрим что там есть...
И так первое по теме, что я вижу, это модуль ossaudiodev. Уже смешно, т.к. помнится у меня даже под Линухом была ALSA (а не эта хрень), а сейчас вообще нахожусь под WIndows. Это не говоря уже о том, что в ossaudiodev не видно приемлемой функции проигрывания файла (там надо ещё серьёзно напрячься, если конечно вообще удастся найти систему, где такое заведётся).
Второе, что я вижу, это модуль winsound — обёртка к каком-то из winapi. Вроде то что надо (если забыть о том, что это только под винду будет работать)... Но на практике оно почему-то не работает. Причём оно даже ошибки не выдаёт, а просто тупо исполняет команду, но при этом никакого звука нет. Просто очаровательное решение...
Больше ничего подходящего не вижу. Я что-то пропустил? Или Питон у нас теперь тоже негодный языка, как и C++? ) Перейдём к другому языку? )))
P.S. А вообще я в шоке, что вышеописанный шлак кто-то пропустил в стандартную библиотеку моего любимого Питончика. Похоже что некоторые преимущества у критичного Комитета C++ тоже есть...
Здравствуйте, MTD, Вы писали:
MTD>Так, видимо я слишком сложно выразился, объясняю: С++ позволяет получить самый быстрый код, автор fmtlib не стал усложнять — получилась простая, компактная и производительная библиотека, в отличии от Буст.
Она простая, потому что переводит в текст только целые, без развитого списка опций форматирования.
Здравствуйте, vdimas, Вы писали:
MTD>>Так, видимо я слишком сложно выразился, объясняю: С++ позволяет получить самый быстрый код, автор fmtlib не стал усложнять — получилась простая, компактная и производительная библиотека, в отличии от Буст.
V>Она простая, потому что переводит в текст только целые, без развитого списка опций форматирования.
Прежде чем нести чушь можно же бегло глянуть документацию?
Здравствуйте, MTD, Вы писали:
MTD>Дальше было хуже, из своей резервации они пролезли в комитет, да спасибо друзья за смартпоинтеры и пару других удобных вещей, но то что вы делаете сейчас просто ни в какие ворота! Внимание, на дворе 2017 год, а в языке нет юникодных строк, нет файловых операций, нет модульности и корутин, зато с азартом обсуждаются новые фичи метапрограммирования. Блин, дорогие ученые, да я рад за вас, пилите, если вам это нужно, но не в ущерб же интересам инженеров на которых был положен болт.
Здравствуйте, MTD, Вы писали:
S>>осторожно, ТС-а может разорвать в клочья
MTD>У тебя все еще полыхает?
О, этот тролль порвался, несите следующего.
MTD>P.S. Данное существо с тобой работает? Уж больно оно тебя парадирует в лексике, выражает одобрямс и пишет подозрительно в одно с тобой время.
Во-первых, "существ" в нашей команде нет в принципе.
Во-вторых, участника RSDN-а с ником rumit7 никто из нас не знает и, вероятно, никогда не видел.
В-третьих, естественно, доказать мы это никак не можем, даже если вы начнете требовать выслать вам наши фотографии или предъявите еще какое-нибудь абсурдное требование.
Ну и напоследок. Когда вам вздумается еще кого-нибудь обвинить в неуважительном отношении к вам, вспомните, пожалуйста, насколько часто вы позволяете себе высказывания вроде "существо" или "поциент" в адрес собеседников.
Здравствуйте, so5team, Вы писали:
S>Во-первых, "существ" в нашей команде нет в принципе.
Как нет? Не лукавь, а кто же тогда из вашей команды меня мудаком называл?
S>Во-вторых, участника RSDN-а с ником rumit7 никто из нас не знает и, вероятно, никогда не видел.
Ок.
S>В-третьих, естественно, доказать мы это никак не можем
Да мне и не надо, на вранье тебя пока не ловили у меня нет оснований не верить твоему слову.
S>Когда вам вздумается еще кого-нибудь обвинить в неуважительном отношении к вам, вспомните, пожалуйста, насколько часто вы позволяете себе высказывания вроде "существо" или "поциент" в адрес собеседников.
Здравствуйте, MTD, Вы писали:
S>>Когда вам вздумается еще кого-нибудь обвинить в неуважительном отношении к вам, вспомните, пожалуйста, насколько часто вы позволяете себе высказывания вроде "существо" или "поциент" в адрес собеседников.
MTD>По поводу тебя. Ты был назван поциентом после того как назвал меня мудаком (http://rsdn.org/forum/cpp.applied/6937467.1
). Так что не надо теперь из себя оскорбленного почтенного мужа изображать — хам ты обычный.
Несколько не так:
Простите, но вас никто даже в качестве бета-тестировщика не рассматривает. Ноунейм, как он есть. Непонятная квалификация. Неспособность задавать вопросы. Неспособность воспринимать ответы. Настолько тонкая душевная организация, что оскорбления вам видятся даже там, где вам просто указывают на отсутствие конструктива. Вы прям наглядная демонстрация актуальности принципа "Никогда не работай с мудаками".
И:
Да, вы "малолетний дебил" (с). Вот и весь конструктивный итог общения с вами в данной теме.
Обратите внимание на кавычки вокруг "малолетний дебил" и знак копирайта. Это устойчивое выражение господина Дмитрия "Гоблина" Пучкова, которое означает человека, ведущего себя как малолетний ребенок и/или высказывающий суждения уровня малолетнего ребенка, хотя по прожитым годам должен был бы иметь более разумные и взвешенные решения/поступки.
Как раз вы в своих спорах ведете себя именно как малолетний ребенок, не желающий видеть и слышать то, что ему пытаются объяснить. Ваше ребячество проявляется так же и в том, что вы видите оскорбление собственных нежных чувств даже там, где их нет. Например, во фразе:
Спасибо за заботу, но можно ли высказывать свои мысли более конструктивно?
после чего переходите на совершенно детские обиды вида:
На многие ответы можно получить ответ, если вежливо интересоваться, а не заявлять, что конкретики 0. Да, даже если и ноль, с людьми надо уметь работать, а если тебе это не приятно и не хочется — ты занялся не тем. Конкретно мне лень сейчас тебе все расписывать — это труд, а тут придется работать даже не за спасибо, а за слабо.
Так что если вы хотите, чтобы вас перестали воспринимать как "малолетнего дебила" (с) и общались как со взрослым и разумным человеком, то перестаньте строить из себя обиженную институтку и съезжать на выражения "у тебя полыхнуло", "у тебя все еще подгорает", "поциент", "существо" и пр. Даже если вы считаете, что по отношению к вам ведут себя не правильно, то опускаясь на уровень "Чмо (ты такой, как мы выяснили, и я имею право тебя теперь так называть), вернись под шконку." вы теряете право требовать к себе какого-то вежливого отношения.
). Так что не надо теперь из себя оскорбленного почтенного мужа изображать — хам ты обычный.
S>Несколько не так: S>
Простите, но вас никто даже в качестве бета-тестировщика не рассматривает. Ноунейм, как он есть. Непонятная квалификация. Неспособность задавать вопросы. Неспособность воспринимать ответы. Настолько тонкая душевная организация, что оскорбления вам видятся даже там, где вам просто указывают на отсутствие конструктива. Вы прям наглядная демонстрация актуальности принципа "Никогда не работай с мудаками".
S>И: S>
Да, вы "малолетний дебил" (с). Вот и весь конструктивный итог общения с вами в данной теме.
S>Обратите внимание на кавычки вокруг "малолетний дебил" и знак копирайта. Это устойчивое выражение господина Дмитрия "Гоблина" Пучкова, которое означает человека, ведущего себя как малолетний ребенок и/или высказывающий суждения уровня малолетнего ребенка, хотя по прожитым годам должен был бы иметь более разумные и взвешенные решения/поступки.
Детский сад, уровень дискуссии достиг новых высот
S>Так что если вы хотите, чтобы вас перестали воспринимать как "малолетнего дебила" (с) и общались как со взрослым и разумным человеком
Мне все равно, что там кто-то в интеренете про меня думает, конкретно за твоими корчами и вторым существом наблюдать забавно. Продолжайте.
Здравствуйте, vdimas, Вы писали:
V>Из своего болота тебе ничего не может быть видно.
Ясно, понятно.
V>>>Потому что им недоступно непосредственное АПИ? P>>Да все имеют доступ к API.
V>Не имеют. V>Потому что производители технологий дают АПИ для С/С++.
Реально смешно. Туева хуча с++ библиотек по логгированию + чуть ли не каждый пятый пишет свою, чтобы не тянуть стороннюю библиотеку. Это только на плюсах такое, когда проще написать свой велосипед, чем тянуть стороннюю библиотеку.
И все они отличаются только синтаксисом и вкусовщиной (это ещё если отличаются) — в остальном братья-близнецы.
Или ты про тот 0.001% уникальных случаев?
V>Просто на плюсах не заворачивают в дебильный XML то, что туда явно не лезет. Конечно, на плюсах используют XML аж бегом, но не так упорото, как в Джаве и дотнете. Потому что малость другие подходы. Можно и парсер конфига нарисовать или свой текстовый или бинарный протокол. Это в духе нейтива, бо в нём удобно парсить и генерить строки.
У тебя просто походу нет опыта работы с большими проектами (исходники больше 1 ГБ) и в больших компаниях (программеров больше 300).
В таких случаях абсолютно все без исключений приходят к необходимости стандартизации и унификации. Она ставится как цель номер один, иначе проект/компания утонет (более того — это логично, и это уже произошло во всех остальных областях деятельности). Это номер раз почему "везде xml".
С xml легко работать, либы уже устоявшиеся, имеется куча утилит которые работают с xml. Не требуется иметь кучу парсеров/генераторов. Отсутствует головняк с разработкой и поддержкой кастомных парсеров/генераторов. Из-за наличия единообразия нет повышенной утомляемости, когда требуется всё время переключать контекст в мозгу.
Рисовать мульён своих конфигов и протоколов — это и есть тот самый инженерный идиотизм.
Так же я думаю ты не в курсе, что на данный момент в реальной жизни всё происходит очень живо и для каждой предметной области никто сейчас не будут писать свой DSL и тратить кучу времени на его отладку, тестирование, поддержку. А xml позволяет достаточно просто и детально описать предметную область. Его очень легко использовать для кодогенерации. С ним отсутствует большинство проблем, замечу ненужных проблем, которые решает парсеро/генераторо-писатель.
Это номер два почему "везде xml".
И пока познающие дзен размышляют как правильно спроектировать DSL или вообще сделать язык под предметную область — остальные уже запилили кодогенерацию на xml и продали.
V>Ну и разработка на дотнете медленная, увы. V>Она может давать буст только за счёт, например, визуальных редакторов UI.
Ну да, ну да. А ещё за счёт работы с БД, и сетью, и конфигами, и плагинами, и RPC, и асинхронность... wait, oh shit
Все проекты которые начинаются — заказывают на C# как раз из-за скорости разработки и отсутствия рисков по сравнению с плюсами. Всё, что заказывают сейчас на плюсах — это мелкие утилиты (причём требуют обязательно сделать ещё и интерфейс на шарпе) и драйвера.
V>Во-во. Бредим, не приходя в сознание. V>Коробочные дотнетные проги в нашей реальности НЕ ПРОДАЮТСЯ, за очень малым исключением.
Во-первых покупаются, во-вторых — это ну очень маленький рынок по сравнению с частным бизнесом/корпорациями.
V>Лучше бы ты догадался о своей упоротости. V>Отличительная черта упоротых свидомых ...
Здравствуйте, alex_public, Вы писали:
_>И так первое по теме, что я вижу, это модуль ossaudiodev. Уже смешно, т.к. помнится у меня даже под Линухом была ALSA (а не эта хрень) _>Больше ничего подходящего не вижу. Я что-то пропустил? Или Питон у нас теперь тоже негодный языка, как и C++? ) Перейдём к другому языку? )))
Ну нравится-не нравится, оно есть.
Я не пойму какую мысль ты этим пытаешься дать? Что основные программные примитивы невозможно стандартизовать?
Серьезно? Ну вот во всех языках получается.
Более того факт в том, что это уже произошло именно в плюсах (потоки, файл система).
Более того — продолжает происходить (net asio) и будет продолжать происходить (короутины, ipc и т.д.).
Здравствуйте, alex_public, Вы писали:
_>Т.е. ты по сути просто за некую что ли стандартизацию популярных C/C++ библиотек, без переноса их в стандартную библиотеку языка? )
Я за стандартизацию основных програмных конструкций. А каким образом это будет выполнено — в виде одной библиотеки или набора — не суть важно. Чтобы я мог закладываться, что они есть в стандартной поставке.
На данный момент ситуация такая, что в других языках — "вот кирпичи, вот раствор, вот мастерок — строй", а в плюсах — "вот песок, вот глина, вот спички — строй, — а кирпичи? — ну иди на улице поищи, все опытные разработчики находят их на улице".
_>Сейчас проблем никаких нет, т.к. каждый разработчик (ну или там команда) создаёт свою собственную коллекцию необходимых им библиотек, собранных под нужные им платформы. А вот если собрать все эти возможные варианты со всего мира в единую огромную библиотеку, то мы уже получим проблему, многогигабайтную)))
В том то и проблема, что каждый на свой лад решает одни и те же типовые задачи (десятки либ в плюсах на каждую типовую задачу, делающие по сути одно и то же) одними и теми же типовыми способами, которые кроме синтаксиса и вкусовщины ничем не отличаются. Это и является показателем, что данный програмный примитив необходим в стандарте.
Здравствуйте, so5team, Вы писали:
S>Про "увеличение производительности программиста на С" речи не было, т.к. сам C был взят исключительно из утилитарных соображений.
Ну я взял его книгу — в предисловиях он сам так пишет
S>Тем не менее, он создавался для скорости. Копирование по умолчанию нужно было для унификации системы типов, чтобы поведение объекта пользовательского типа A не отличалось от поведения экземпляра какого-нибудь int-а или double. За счет этой унификации шаблоны в C++ получились настолько мощными. Исключения и RTTI добавились несколько позже. Виртуальные функции не тормозят, т.к. там, где они нужны, тормозить будет и все остальное. Кроме того, C++ давным-давно позволяет иметь полиморфизм и без виртуальных функций.
Тут я вообще никак не согласен, что для скорости. Да, старались делать максимально эффективно, но всё же делали язык общего назначения. Нет никаких спецсредств/концепций для скорости. Виртуальные функции вообще как концепция не могли появится в таком языке. Наличие остальных, противоположных скорости концепций подтверждает это. Да и сам автор пишет.
То, что получились ШАБЛОНЫ — тогда такое даже не закладывалось — делали просто шаблоны, а уже остальную мощь с удивлением обнаружили после.
S>Язык общего назначения не может создаваться под ниши с повышенными требованиями к ресурсоемкости и производительности? OK.
Эммм, почему? Дело лишь в сложности компилятора.
S>И что нужно было делать, GC в язык добавлять?
Нужно было развивать язык и инфраструктуру, чтобы они хотя бы не хуже остальных выглядели.
А на счёт GC — это по желанию. Лично мне не нужен, но если большому количеству нужен, то не вижу проблемы добавить. Считай как отдельный мемори пул с продвинутыми мозгами.
Здравствуйте, Слава, Вы писали:
С>Ну вот поэтому для mission-critical софт на C++ и не пишут. Используют либо Си, либо прочее такое, простое и сертифицированное.
Ага, и потом, спустя Х лет и Y команд разработчиков, сами не знают, с какой стороны подступиться, чтобы найти багу.
Здравствуйте, push, Вы писали:
S>>Про "увеличение производительности программиста на С" речи не было, т.к. сам C был взят исключительно из утилитарных соображений.
P>Ну я взял его книгу — в предисловиях он сам так пишет
Какую именно? В его книге "Дизайн и эволюция языка C++" подробно описывается как появилось решение делать C++ и какие цели при этом преследовались.
P>Тут я вообще никак не согласен, что для скорости. Да, старались делать максимально эффективно, но всё же делали язык общего назначения.
Это ваши личные проблемы и заблуждение. Например, заблуждение о том, что язык общего назначения не может быть "языком для скорости".
P>Нет никаких спецсредств/концепций для скорости.
Скорее в языке нет никаких спецсредств/концепций для замедления. В отличии от безопасных языков, в которых таковые есть в товарных количествах: начиная от проверок индексов в run-time, заканчивая сборщиком мусора.
P>Наличие остальных, противоположных скорости концепций подтверждает это.
Каких?
P>Да и сам автор пишет.
Вы уверены, что вы понимаете, что пишет Страуструп?
P>То, что получились ШАБЛОНЫ — тогда такое даже не закладывалось — делали просто шаблоны, а уже остальную мощь с удивлением обнаружили после.
Тогда -- это когда? Шаблоны появились в языке в 1990-ом, через 5 лет после публичного релиза языка. А работа над ними началась еще раньше.
S>>Язык общего назначения не может создаваться под ниши с повышенными требованиями к ресурсоемкости и производительности? OK.
P>Эммм, почему?
Это вы скажите почему. Вы же противопоставляете "язык для скорости" и "язык общего назначения".
S>>И что нужно было делать, GC в язык добавлять?
P>Нужно было развивать язык и инфраструктуру, чтобы они хотя бы не хуже остальных выглядели. P>А на счёт GC — это по желанию. Лично мне не нужен, но если большому количеству нужен, то не вижу проблемы добавить. Считай как отдельный мемори пул с продвинутыми мозгами.
Гы-гы-гы. Никогда не задумывались, насколько GC облегчает написание библиотек в других языках? Никогда не задумывались, насколько часто GC нужен при решении обычных задач, не требующих высокой производительности и низкого потребления ресурсов?
То, что GC сильно облегчает жизнь программистам, стало понятно еще в 50-е годы прошлого века. Но только в середине 1990-х компьютеры в массе своей стали обеспечивать должную производительность для языков с GC. И после этого C++ в массах без GC стал не нужен. Так что гонка с Java (а потом и с C# и с другими безопасными языками с GC) была проиграна сразу, как только RAM и CPU перестали быть ресурсом. И как бы не обеспечивали C++ библиотеками и инфраструктурой, все равно большинство бы ушло в безопасные языки с GC.
Здравствуйте, landerhigh, Вы писали:
L>Ага, и потом, спустя Х лет и Y команд разработчиков, сами не знают, с какой стороны подступиться, чтобы найти багу. L>Фильм ужасов, основанный на реальных событиях.
Много лет тому назад царь купил себе айпад
На си можно писать разборчиво, если хочется. А вообще, под простым и сертифицированным я подразумевал Ada, которую когда-то специально сделали для сложных и ответственных проектов. На мой взгляд, это самый пригодный для чтения язык общего назначения.
Здравствуйте, Слава, Вы писали:
L>>Фильм ужасов, основанный на реальных событиях.
С>Много лет тому назад царь купил себе айпад С>На си можно писать разборчиво, если хочется.
Можно. Только чуть чаще, чем всегда, разборчиво пишутся исключительно ручные реализации того, что в плюсах есть искаропки (с) вроде конструкторов и таблиц методов.
Здравствуйте, push, Вы писали:
P>Реально смешно. Туева хуча с++ библиотек по логгированию + чуть ли не каждый пятый пишет свою, чтобы не тянуть стороннюю библиотеку. Это только на плюсах такое, когда проще написать свой велосипед, чем тянуть стороннюю библиотеку.
Да, и у нас в плюсовом проекте тоже своя библиотека логгирования.
И не потому, что мы не видели других.
Видели много, даже слишком. Тем более видели из мира Джавы и Дотнета.
Но сценарии у нас слишком специфические.
Т.е. будь даже в стандарте уже встроено несколько технологий логгирования, они бы нам не подошли.
Потому что если бы со своим наивным подходом посмотрел, какой путь у нас совершают данные в нашем асинхронном логгере, у тебя бы сломался моск. )) Безблокировочность она такая, угу. Но это минимально затратно по тактам в целевом потоке обработки данных, а нам требуется именно такая минимальность.
P>И все они отличаются только синтаксисом и вкусовщиной (это ещё если отличаются) — в остальном братья-близнецы.
Они отличаются по архитектуре, потоковой модели и, соответственно, по политикам блокировок.
Просто ты пишешь из такого болота, где все эти вещи фактически не имеют смысла, поэтому, тебя интересует только внешний АПИ.
P>Или ты про тот 0.001% уникальных случаев?
Каждый случай, требующий эффективности — по-своему уникален.
Потому что не может абстрагироваться от конкретной потоковой модели происходящего.
V>>Просто на плюсах не заворачивают в дебильный XML то, что туда явно не лезет. Конечно, на плюсах используют XML аж бегом, но не так упорото, как в Джаве и дотнете. Потому что малость другие подходы. Можно и парсер конфига нарисовать или свой текстовый или бинарный протокол. Это в духе нейтива, бо в нём удобно парсить и генерить строки. P>У тебя просто походу нет опыта работы с большими проектами (исходники больше 1 ГБ) и в больших компаниях (программеров больше 300).
С этой херней сразу в сад. Потому что и опыт есть и видел разного.
Де-факто, XML пихается повсеместно исключительно от нубства разработчиков-обезъянок.
Я ничуть не спорю с тем, что полно сценариев, когда XML вполне оправдан (декларативность/структурированность). Просто их раз в 10 меньше, чем фактических случаев использования. Потому что XML в Дотнете-Джаве часто используется вовсе дико — он используется ровно в тех сценариях, где надо описывать некие императивные действия. Т.е. в этом декларативном языке описывают AST неких императивных выражений. Во дичь-то! И это в 90% случаев использования XML. Даже если на первый взгляд система выглядит сугубо декларативной, типа как Ant/NAnt — нифига, 99% схемы этого документа описывает сугубо императивные действия, а на декларатив там оставлен жалкий 1% указания зависимостей.
Вот почему над вами ржут. Потому что вы не в состоянии ОБЪЕКТИВНО посмотреть как на свои инструменты, так и на собственные поделия. Вы живёте во лжи. Врёте себе и окружающим. Блин, ну если объективно нужна динамика — так бери динамику, какие проблемы, нахера брать XML? Существуют же кучи динамических языков. Абсолютно все из них идут в виде "движков", т.е. позволяют подключать эти движки в проект простым движением руки.
P>В таких случаях абсолютно все без исключений приходят к необходимости стандартизации и унификации.
Во-во. ))
XML не даёт стандартов на данные, он даёт стандарты для структурирования этих данных.
Поэтому, тебе всё-равно надо разрабатывать СХЕМУ документа.
Т.е. не брать некую стандартную/имеющуюся, а именно ВВОДИТЬ ее в проект, т.е. тебе в любом случае приходится СТАНДАРИЗИРОВАТЬ некий свой насос из пальца.
Ну и такой момент как читабельность. XML не читабелен от слова совсем. А ведь читабельность — это важная составляющая обслуживаемости, не?
P>Она ставится как цель номер один, иначе проект/компания утонет
Это всё нубские разговоры. По-факту в крупных компаниях процент проваленных проектов больше, чем в мелких. Посмотри сколько и каких мастабшных проектов ушло "в стол" в гугле или MS. Потому что мелкие компании не могут позволить себе нанимать толпы нубов (в том числе нубов-управленцев и архитекторов), а большие — могут. В больших компаниях большая текучка и низкий средний уровень программиста и управляющего персонала.
Поэтому, давай называть вещи своими именами — для трёхсот нубов требуются совсем другие внутренние стандарты на разработку, чем для пятидесяти профессионалов. И задача профессионалов в больших компаниях тоже отличается от задач профессионалов в небольших. Если во втором случае профессионалы непосредственно занимаются разработкой 100% времени, то в больших львиная доля профессионалов тратит своё рабочее время (и нервы!) на подтирание задниц нубам и уборкой за ними несметных туч г-на в архитектуре и непосредственно в коде.
P>Это номер раз почему "везде xml".
Да нет его "везде", уже отказываются, мода уже прошла.
Он есть только в вашем дотнете-джаве, но коробочные продукты на этих технологиях не покупаются.
Посмотри, например, на QML в QT.
Это даже не JSON, хотя близкая технология.
Какой-нить упоротый дотнечик или джавист непременнос лепил бы аналогичное на XML, а как же!
P>С xml легко работать, либы уже устоявшиеся, имеется куча утилит которые работают с xml. Не требуется иметь кучу парсеров/генераторов. Отсутствует головняк с разработкой и поддержкой кастомных парсеров/генераторов. Из-за наличия единообразия нет повышенной утомляемости, когда требуется всё время переключать контекст в мозгу. P>Рисовать мульён своих конфигов и протоколов — это и есть тот самый инженерный идиотизм.
Инженерный идиотизм — это не знать самых базовых правил инженерии. Например таких, что наиболее общее решение является наихудшим для конкретного случая. Поэтому, инженер всегда ищет решение в координатах противоречивых требований. И конкретное решение, его кач-во, зависит в том числе от навыков инженера, разумеется.
Просто ты живешь во лжи и не называешь вещи своими именами. А ни таковы, что из нейтива доступны произвольные либы парсинга и произвольные движки динамических языков с развитым АПИ, а у вас НИХРЕНА НЕТ. Поэтому, лишний раз подумаешь — то ли делать биндинг скриптового движка, то ли ну его нафик, давай опишем AST эквивалентных императивных выражений в виде XML!
P>Так же я думаю ты не в курсе, что на данный момент в реальной жизни всё происходит очень живо и для каждой предметной области никто сейчас не будут писать свой DSL и тратить кучу времени на его отладку, тестирование, поддержку.
Я прекрасно знаю как оно происходит в мире заказухи.
Слепил, втюхал, побежал дальше.
Сам активно фрилансил одно время или занимался заказной разработкой в рамках компаний.
Это свинское болото в большинстве случаев, потому что приоритеты другие — свинские.
Отсюда среднее качество решений в заказухе ниже плинтуса.
P>А xml позволяет достаточно просто и детально описать предметную область.
Нет не позволяет. Позволяет некая спека — схема документа.
И вот как посмотришь на некоторые спеки над XML, так начинаются вопросы из разряда — люди, вы чего творите-то? ))
P>Его очень легко использовать для кодогенерации.
Для кодогенерации легко использовать любое типизированное структурное представление, которое уже в памяти.
Представление в памяти XML в этом смысле — одно из самых неудобных.
Чтобы проводить по такому представлению кодогенерацию, это представление надо предварительно отобразить на некоторое типизированное и потом уже что-то такое пытаться делать.
P>С ним отсутствует большинство проблем, замечу ненужных проблем, которые решает парсеро/генераторо-писатель.
А кто мешает взять готовые решения?
А, ну да. Нет бинда под дотнет... Понимаю... ))
P>Это номер два почему "везде xml".
Потому что на безрыбье ты вынужден становиться раком и больше нипочему.
P>И пока познающие дзен размышляют как правильно спроектировать DSL или вообще сделать язык под предметную область — остальные уже запилили кодогенерацию на xml и продали.
Пипец...
За то время, которое тебе потребуется на дотнете только лишь для стадии кодогенерации, в нейтиве можно сделать проект целиком.
P>А ещё за счёт работы с БД
С БД в дотнете-джаве хуже.
P>и сетью
С сетью вообще хана.
P>и конфигами
Конфиги мы уже обсудили.
P>и плагинами
COM, WinRT — вполне компонентные технологии.
Нейтивные.
Собсно, чего-то аналогичному OLE/ActiveX ни дотнет ни джава так и не породил.
И оно востребовано в Офисных док-тах до сих пор и будет востребовано еще неизвестно сколько.
Лет 20 или больше аж бегом.
P>RPC
RPC отродясь возникло как нейтивное.
Учите матчасть.
P>асинхронность... wait, oh shit
Асинхронности в дотнете НЕТ. ))
Есть её муляж в таком зачаточном состоянии, что признать ЭТО за наличие асинхронности сложновато.
Если в нейтиве асинхронность ведёт к резкому увеличению пропускной способности, то в дотнете — к очень нерезкой.
Объект Task сам по себе настолько тяжеловесен вместе со всей инфраструктурой вокруг него, столько надо сделать процессору действий для банальной постановки задачи в очередь, что это получилась профанация асинхронности.
Ты хоть имеешь представление, почему в Task настолько тяжело приходится разбираться с SynchronizationContext?
Или никогда не интересовался?
Ну так поинтересуйся, потом приходи.
В итоге, максимум где полезна такая асинхронность а ля дотнет — сугубо в GUI, т.е. ы-ы-ы много раз.
Юзер тыкает по элементам управления максимум один раз в секунду, вот мы сейчас покажем тру асинхронность!!! )))
Тут следовало бы убиться апстену и не отсвечивать, как по мне.
P>Все проекты которые начинаются — заказывают на C#
Это в какой реальности такое?
Не, на C# заказывают довольно много проектов, согласен.
Но C# не входит даже в тройку языков по популярности в заказухе.
P>как раз из-за скорости разработки и отсутствия рисков по сравнению с плюсами.
От предметной области зависит.
Если надо нарисовать неспешный магазинчик, то C#, Java, PHP, RoR — очень даже неплохие решения.
А если биржу — то увы.
P>Всё, что заказывают сейчас на плюсах — это мелкие утилиты (причём требуют обязательно сделать ещё и интерфейс на шарпе) и драйвера.
Всё, на чём ты работает, ну т.е. вообще всё — оно писано на нейтиве.
Даже твой дотнет.
Даже твои БД.
Даже твои веб-сервера.
Какую-бу программу ты не запустил, какой бы девайс не взял в руки — там нейтив и только нейтив.
Даже в Андроиде основные проги — нейтивные.
А всякими свистелками и перделками народ лишь недолго балуется, но каждый день пользуется сугубо нейтивными приложухами — модулем звонков, камерой и видео. На андроидной жабке там лишь 2-3 кнопки нарисованы, т.е. 0.0001% от всего кода, составляющего эти модули.
V>>Коробочные дотнетные проги в нашей реальности НЕ ПРОДАЮТСЯ, за очень малым исключением. P>Во-первых покупаются,
Пример?
P>во-вторых — это ну очень маленький рынок по сравнению с частным бизнесом/корпорациями.
Бизнес ПО/Деловое ПО и заказное — это две большие разницы.
Например, Парус или 1С продают на 90% (грубо) коробочный продукт и на 10% конфигурируемый.
Так же есть нехилый рынок ПО, которое поставляет производитель оборудования в составе своих девайсов.
Простой пример — автомобильные системы, модули управления движком и т.д.
Там тоже почти всегда нейтив (на более чем 99% девайсов уж точно).
Так вот, если взять "чистую заказуху", т.е. которая не писана на какой-нить бизнес-платформе (которая сама по себе является коробочным продуктом/услугой), т.е. отбросить "мальчиков-1С-ников" и прочих т.н. value-added resellers, то в "чистой заказухе" останется денег и работы даже меньше, чем выделяется денег и работы на встраиваемое ПО производителями оборудования. Более того, 90% этих денег и работы сегодня сосредоточены исключительно в вебе, где эти деньги тебе, как программисту, надо делить с дизайнерами сайтов, администраторами или хостерами. Итого, собственно программистам остаётся с гулькин нос. Именно поэтому в разработке под веб хороших денег нет. Потому что есть деньги в разработке ферм, виртуализации и прочем. Но, блин, там тоже получают свои большие денюжки нифига не дотнетчики и не джависты. ))
Здравствуйте, MTD, Вы писали:
MTD>>>Хорошо, что в комитете еще есть практики, которые с тобой не согласны. CC>>И кто же эти практики? MTD>Те которые, например, тредс таки протащили — огромное им спасибо.
Это которые начали разрабатывать их с 2000-го года? И которые трижды переписывали их реализацию?
Да еще за это время успешно сдохло несколько когда-то популярных платформ, т.е. задача резко облегчилась?
Здравствуйте, push, Вы писали:
P>- отсталость языка (о боже наконец-то вводят any, optional, variant и т.д. — и то либами, фу! Нет reflection, modules, ABI и т.д.).
Причем в C то ABI уже был и прекрасно работал. Только за один сломанный ABI Страуструп и комитетчики должны гореть в аду.
Здравствуйте, Lepsik, Вы писали:
AG>>Слоты и сигналы в Qt: AG>>https://woboq.com/blog/new-signals-slots-syntax-in-qt5.html
L>Зачем это нужно в десктопных приложениях? Билдер и сейчас в ходу и в мелких и крупбых компаниях. Qt даже не тянет на близкую альтернативу.
Именно для настольных приложений это весьма актуально!
Теперь вопрос риторический: где в 2017-ом применяется Билдер и Делфи
Насчёт выделенного — крупных компаний — приведи, пожалуйста, примеры современных разработок!
Здравствуйте, MTD, Вы писали:
V>>Ты высказываешься в той ветке, где С++ ругают за недостаточную навороченность. MTD>Чего? Я начал эту тему и у меня наоборот претензии, что сейчас сообщество увлеклось переусложнением.
А я отвечал человеку в конкретной подветке.
V>>Индустриальных стандартов много, как и комитетов по стандартизации. V>>Разумеется, С++ такой же индустриальный стандарт. MTD>У тебя какая-то каша в голове. Например, никто их не стандартизировал
Кого "их"?
MTD>а на С++ сообщество не осилило сделать ничего такого же уровня.
На язык С++ есть целая сетка версий стандартов.
MTD>На обертки ты дал ссылки, а не на либы.
Обертка обертке рознь.
MTD>Вот я написал плюсовую обертку над openssl что мне теперь кричать, что я гуру криптографиии и внес огромный вклад?
Ну, я тоже написал именно под openssl.
Пару вечеров работы, и?
Под дотнет такая же по функциональности обертка могла занять рабочую неделю.
Всё-таки, это малость опрометчиво — сбрасывать со счетов непосредственную интероперабельность С и С++ кода.
V>>Ну покажи мне С++ компиляторы под архитектуры PIC, AVR, i51 MTD>Для них нет компиляторов С++? Это что же ты так решил высказаться, что С++ отстой?
Так и дотнета под них нет.
Может, это просто такие специфические архитектуры, что под них даже реализация языка идёт С в сильно урезанном виде?
V>>За что его и ругают, кстате. V>>Отличный пример, спасибо. MTD>Конечно, у труЪ модерн С++ разработчиков, бомбит когда кто-то зарабатывает деньги и решает проблемы людей.
Да я не против. QT — это просто хороший пример того, что не всё зависит только от языка. Язык же не в вакууме живёт, а на конкретных аппаратных и программных платформах. Поэтому, тот же GTK+ сугубо сишный. Но ведь тоже мазохизм, не? Не зря же существует Vala?
V>>Ну ты бы сначала вопросом поинтересовался бы, потом выводы делал. MTD>Хочешь длиной меряться? Ну расскажи, что ты на С++ написал.
Какая прикладная область интересует?
V>>В С++ оборачивается обычно ничтожная часть АПИ любой сишной библиотеки. MTD>Это бессмысленное высказывание, оборачиваю всегда только внешний интерфейс.
Осмысленную часть ты скромно порезал:
Вот только те объекты, которые отвечают за ресурсы, те и оборачиваются, потому что ради RAII.
Но гораздо больше объектов никакого оборачивания не требуют.
Не требуют оборачивания структуры, перечисления, константы и т.д. и т.п.
А такие вещи обычно составляют более половины любой спецификации АПИ.
Здравствуйте, vdimas, Вы писали:
V>Потому что если бы со своим наивным подходом посмотрел, какой путь у нас совершают данные в нашем асинхронном логгере, у тебя бы сломался моск. )) Безблокировочность она такая, угу. Но это минимально затратно по тактам в целевом потоке обработки данных, а нам требуется именно такая минимальность.
Ага, ну то есть — нам нужна супер кастомная либа логгирования, но раз её не добавят в стандарт (потому что остальным нафиг не нужна) — то я за то, чтобы все остальные 99,9% разработчиков продолжали писать свои велосипеды?
V>Они отличаются по архитектуре, потоковой модели и, соответственно, по политикам блокировок.
Да в них всё нужное настраивается, а некоторые вещи, как "политики блокировок" в 99% случаях нафиг не нужны.
P>>Или ты про тот 0.001% уникальных случаев? V>Каждый случай, требующий эффективности — по-своему уникален. V>Потому что не может абстрагироваться от конкретной потоковой модели происходящего.
Ахахаха)))) Ты хочешь сказать, что все вещи _надо_ велосипедить? Ведь каждый случай по своему уникален. И получается что писать библиотеки вообще нет смысла? Ведь идеальных библиотек не бывает в принципе. Так или иначе каждая либа покрыват лишь некоторый процент случаев применения.
V>>>Просто на плюсах не заворачивают в дебильный XML то, что туда явно не лезет...
Оххх, да-да, оно конечно, все "нубы". Но беда в том, что такое "нубское" решение рвёт на рынке любое кастомно-плюсовое как тузик грелку во всех отраслях, где может конкурировать.
Отвечу твоими же словами. С этой херней сразу в сад. Потому что и опыт есть и видел разного.
Реально влом пережевывать настолько очевидные вещи, ибо жевать придётся много.
V>Инженерный идиотизм — это не знать самых базовых правил инженерии. Например таких, что наиболее общее решение является наихудшим для конкретного случая. Поэтому, инженер всегда ищет решение в координатах противоречивых требований. И конкретное решение, его кач-во, зависит в том числе от навыков инженера, разумеется.
Конечно, но инженер в 99,9% случаев никогда не будет заново рассчитывать, создавать и испытывать базовые конструкции — когда достаточно типовых. Более того, в современном мире, в подавляющем большинстве случаев результат собирают из стандартных конструкций из каталога.
V>Пипец... V>За то время, которое тебе потребуется на дотнете только лишь для стадии кодогенерации, в нейтиве можно сделать проект целиком.
точно пипец, до чего можно договориться
V>С БД в дотнете-джаве хуже. V>С сетью вообще хана. V>Конфиги мы уже обсудили. P>>и плагинами V>COM, WinRT — вполне компонентные технологии. V>RPC отродясь возникло как нейтивное. V>Асинхронности в дотнете НЕТ. )) V>Есть её муляж в таком зачаточном состоянии, что признать ЭТО за наличие асинхронности сложновато.
OKAY
P>>как раз из-за скорости разработки и отсутствия рисков по сравнению с плюсами. V>Если надо нарисовать неспешный магазинчик, то C#, Java, PHP, RoR — очень даже неплохие решения. V>А если биржу — то увы.
О как, ну то есть только в отрасли криточной к ресурсам.
Напомни мне какое соотношение проектов уровня "неспешный магазинчик" и "биржа"? Один к миллиону, или это я слишком уж оптимистично оценил?
Хм, интересно, и почему же такой замечательный язык, с такой замечательной инфраструктурой (по твоим словам), с невероятно быстрой скоростью написания проектов так позорно сливает остальным языкам?
Все остальные дураки и мазохисты?
V>...то в "чистой заказухе" останется денег и работы даже меньше, чем выделяется денег и работы на встраиваемое ПО производителями оборудования...
Частично верно, но ты забываешь один ньюанс — соотношение количества проектов на страиваемое ПО (и другое, критичное к ресурсам) и остальной заказухи, что на корню рушит твои выводы. Взять работу любой большой софтверной компании — на 2-3 проекта по встраиваемому ПО — десятки проектов по с/х, медицинскому, медиа, казуально-игровых, кастомных решений для бизнеса и другому ПО.
Здравствуйте, so5team, Вы писали:
S>Какую именно? В его книге "Дизайн и эволюция языка C++" подробно описывается как появилось решение делать C++ и какие цели при этом преследовались.
"Язык С++. Специальное издание." В предисловиях он описывает почему решил создать С++ и что хотел в нём видеть.
S>Это вы скажите почему. Вы же противопоставляете "язык для скорости" и "язык общего назначения".
оО Это я противопоставляю? Вообще-то это вы противопоставили. Я пытаюсь донести, что это не верно.
S>И как бы не обеспечивали C++ библиотеками и инфраструктурой, все равно большинство бы ушло в безопасные языки с GC.
Категорически не соглашусь. GC конечно помогает, но не до такой степени. Более того GC разных хватает и в плюсах. Более того, каждый может сам написать такой GC, который захочет — есть книги по шаблонным паттернам и трюкам, c подробным описанием и реализацией "шаг-за-шагом" своего GC.
Киллер-фича — это как раз стандартные библиотеки и инфраструктура. Когда я могу быстро и легко набросать приложение из "стандартных кирпичиков". То же самое можно, конечно, сделать и на плюсах, но это займёт несоизмеримо больше времени и трудозатрат.
А если нет разницы в конечном результате — то зачем платить больше?
Вот и получается, что шансов конкурировать на большей части рынка у С++ нет. И не потому, что есть какие-то фундаментальные проблемы или на С++ чего-то невозможно сделать, а потому что собственно нечем конкурировать.
И С++ не ужимается до естественных областей применения — он просто сдаёт позиции, как только в какой-то области появляется конкурент. Потому он сейчас и живёт только в тех областях, где ему (пока что) нет конкуренции.
Как это исправить? Ну для начала хотя бы перенять опыт других языков.
Здравствуйте, push, Вы писали:
S>>Какую именно? В его книге "Дизайн и эволюция языка C++" подробно описывается как появилось решение делать C++ и какие цели при этом преследовались.
P>"Язык С++. Специальное издание." В предисловиях он описывает почему решил создать С++ и что хотел в нём видеть.
Ну тогда перечитайте, а то есть ощущение, что вы чего-то не поняли. Не мог Страуструп в "Дизайне и эволюции" писать одно, а в "Язык программирования C++" -- другое.
S>>Это вы скажите почему. Вы же противопоставляете "язык для скорости" и "язык общего назначения".
P>оО Это я противопоставляю? Вообще-то это вы противопоставили. Я пытаюсь донести, что это не верно.
Конечно вы:
Если бы он создавался для скорости — то как минимум по умолчанию копирования небыло, не было бы и виртуальных функций, исключений, RTTI.
С++ позиционировался как язык общего назначения. Повторюсь, Старутруп сам пишет об этом в предисловии.
Вы же сами пишите, что C++ создавался не для скорости, а как язык общего назначения. Значит вы не можете себе представить, как это можно уместить в рамках одного языка. Вероятно, поэтому вы так феерически высказываетесь.
P>Более того GC разных хватает и в плюсах. Более того, каждый может сам написать такой GC, который захочет — есть книги по шаблонным паттернам и трюкам, c подробным описанием и реализацией "шаг-за-шагом" своего GC.
Простите, вы это сейчас серьезно?
P>Киллер-фича — это как раз стандартные библиотеки и инфраструктура.
Вы знаете, что в некоторых прикладных нишах использование STL (т.е. стандартной библиотеки C++) находится под запретом (либо целиком, либо частично)?
P>Как это исправить? Ну для начала хотя бы перенять опыт других языков.
Здравствуйте, push, Вы писали:
P>Ага, ну то есть — нам нужна супер кастомная либа логгирования, но раз её не добавят в стандарт (потому что остальным нафиг не нужна) — то я за то, чтобы все остальные 99,9% разработчиков продолжали писать свои велосипеды?
У остальных уже есть абстракция ostream и фреймворк фильтрации сверху в бусте.
V>>Они отличаются по архитектуре, потоковой модели и, соответственно, по политикам блокировок. P>Да в них всё нужное настраивается
В тех десятках, что я видел, нифига нужного не настраивается. Всё прибито гвоздями друг к другу на основе 3-4-х основных интерфейсов. Такие либы сделаны по принципу аналогичных либ из джавы и дотнета и выглядят, мягко говоря, идиотизмом. Ну и эффективность соответствующая.
P>Ахахаха)))) Ты хочешь сказать, что все вещи _надо_ велосипедить? Ведь каждый случай по своему уникален.
Тю...
Велосипедить можно по-разному. Можно самому распиливать трубы на рамы, варить их, покрывать защитными покрытиями, резать проволоку на спицы и т.д. А можно взять готовую первоклассную карбоновую раму от ведущего производителя карбоновых рам, самые подходящие под конкретный сценарий колеса (и на выбор шины к ним), затем цепь от самого лучшего в мире производителя цепей и т.д., и в итоге забацать отличный для конкретного сценария велик за смешное время. Так вот. Проблема дотнета в том, что когда в нём охота забацать велик, то приходится начинать фактически с распила труб. ЛЮБОЙ более-менее большой дотнетный проект содержит в себе еще несколько проектов (речь доходит до десятка-другого порой). Сугубо внутренних проектов, разумеется. С т.з. нейтива это давно уже дикость.
Поэтому, велосипедить в дотнете накладно, ес-но.
И глупо.
Однако ж, всё-равно велосипедят.
Потому что некуда деваться.
А в языках с хорошей выразительностью велосипедостроительство — это основной вид деятельности. Причём, замечательной приятной творческой деятельности. Вот как в функциональных языках или даже в Немерле (хоть я и не фанат). Вот где-то так же и в С++, особенно в последних стандартах. В нём сначала описывается некая предметная область, а затем программа выражается в терминах этой предметной области. На джаве/дотнете такой подход НЕ работает, увы. Там код всё-равно выходит я-ля ТурбоПаскаль — просто операторы, методы, ф-ии и мало смысла, привязанного к решаемой задаче. Потому что паттерн на паттерне сидит и паттерном погоняет. Такой подход нехило замыливает суть происходящего, разбрасывает внимание. А всё потому, что ничего друг с другом не совместимо. Там или жрите базовые интерфейсы или городите бесконечные паттерны на ровном месте. Т.е. шаг вправо-влево — считай расстрел.
P>И получается что писать библиотеки вообще нет смысла?
В языке, типа С++, нет смысла писать библиотеки all-in-one. Можно писать части библиотек.
Ты всё-время забываешь, что части различных библиотек прекрасно работают друг с другом.
Т.е. не обязательно выпускать готовые велосипеды, бо всем ты не угодишь.
Да чего уж там. Ты не угодишь даже половине. ))
Но можно выпускать отдельно номенклатуру колёс, отдельно цепей, рам и т.д.
P>Ведь идеальных библиотек не бывает в принципе. Так или иначе каждая либа покрыват лишь некоторый процент случаев применения.
МО-ЛО-ДЕЦ!
Наконец до тебя дошло.
Именно поэтому развитый базис, позволяющий комбинировать готовые "кирпичики", намного ценнее некоторого конкретного решения, которое практически невозможно на эти кирпичики разобрать.
[...]
V>>...то в "чистой заказухе" останется денег и работы даже меньше, чем выделяется денег и работы на встраиваемое ПО производителями оборудования... P>Частично верно, но ты забываешь один ньюанс — соотношение количества проектов на страиваемое ПО (и другое, критичное к ресурсам) и остальной заказухи, что на корню рушит твои выводы. Взять работу любой большой софтверной компании — на 2-3 проекта по встраиваемому ПО — десятки проектов по с/х, медицинскому, медиа, казуально-игровых, кастомных решений для бизнеса и другому ПО.
Как-то ты странно считаешь.
Сейчас номенклатура устройств, в которых работает какое-либо ПО, резко превышает кол-во тех самых "бизнес-сайтов", на которых, собсно, тру-программисты и могут заработать. Сейчас в пересчёте на каждого человека приходится примерно один проц общего назначения (в ноуте, десктопе или планшете) и порядка двух десятков процов во всех устройствах вокруг него. В общем, рынок встраиваемого ПО обогнал по денежной ёмкости рынок "чистой заказухи" еще более 5-ти лет назад. Более того. Тенденции рынка чистой заказухи все последние 15 лет хреновые — её доля продолжает ужиматься. А, скажем, в РФ, с 2012-го года ужимается не только доля чистой заказухе, но и абсолютный объем этого рынка! За счёт доли value-added resselers, ес-но. Т.е. это нормальный процесс унификации самого понятия "кастомизация ПО".
В сегодняшней реальности всё больше денег достаётся дизайнерам сайтов, бизнес-аналитикам/консультантам, администраторам и т.д.
А собственно разработчикам ПО — всё меньше.
Потому что всё уже разработано.
Так шта, бойтесь своих желаний, как грится.
Как только разработают ВСЕ библиотеки (как ты настаиваешь), так лично ты станешь не нужен.
Потому что стоит к таким либам потом протянуть ср-ва их предметно-ориентированного комбинирования (назовём так) и усё. Грамотный бухгалтер или инженер обойдутся и без тебя.
Общий объем рынка заказной разработки сайтов по оценке CMS Magazine в 2016 году — 16,4 млрд рублей. Тот же показатель в 2012 году — 17,73 млрд рублей.
На лицо — сжатие рынка.
Среди основных причин можно особо выделить следующие:
— Общая экономическая ситуация;
— Расширение возможностей коробочных CMS и, как следствие, уменьшение объема программирования в типовых проектах;
— Снижение спроса на заказную разработку небольших сайтов в пользу SaaS и расширенного функционала соцсетей;
— Увеличение количества компаний, предпочитающую внутреннюю разработку.
И если 1-й и 2-й пункты зависят много от чего, т.е. могут гулять туда-сюда, то п. 2 и 3 — они фундаментальные. Это то, куда всё движется.
Поэтому, всё более нужны именно те, кто разрабатывает библиотеки/платформы. Собсно, это и есть программисты. Все остальные будут как "мальчики-1С" — т.е. "настройщиками".
===========
Тут еще стоит учесть падение стоимости рубля, т.е. вообще полная ж-па получается.
Не, я все эти годы постоянно слышал, что рынок заказухи падал, ОК.
Но даже не представлял насколько, оказывается, глубоко сие падение.
Здравствуйте, push, Вы писали:
V>>За то время, которое тебе потребуется на дотнете только лишь для стадии кодогенерации, в нейтиве можно сделать проект целиком. P> точно пипец, до чего можно договориться
Кстате, да.
Это ведь расхожее заблуждение в мире дотнетчиков, что в нейтиве ситуация сегодня такая же, как в 2000-м году, верно?
Т.е. твой моск, смотрю, пока еще изо всех сил борется с тем фактом, что огромный пласт задач (даже сугубо прикладных) сегодня на С++ решается заметно быстрее и проще, чем даже на C# 7.0.
Здравствуйте, vdimas, Вы писали:
V>Это которые начали разрабатывать их с 2000-го года? И которые трижды переписывали их реализацию? V>Да еще за это время успешно сдохло несколько когда-то популярных платформ, т.е. задача резко облегчилась?
ОМГ, какая дичь. POSIX существует с незапамятных времен, а в нем есть описание семафора — это такой примитив на котором элементарно строятся любые конструкции и который в С++ до сих пор не осилили. В лохматых 200х годах уже за это можно было бы петь хвалебные песни комитету. А то, что на каком-то утюге нет потоков, так просто на утюге не было бы файла thread.
Здравствуйте, vdimas, Вы писали:
MTD>>а на С++ сообщество не осилило сделать ничего такого же уровня.
V>На язык С++ есть целая сетка версий стандартов.
И в каком стандарте С++ есть спецификация, например, на алгоритмы криптографии?
V>Обертка обертке рознь.
MTD>>Вот я написал плюсовую обертку над openssl что мне теперь кричать, что я гуру криптографиии и внес огромный вклад?
V>Ну, я тоже написал именно под openssl. V>Пару вечеров работы, и?
Сложности с пониманием написанного? Давай на пальцах, для чтобы даже до самых-самых дошло:
1. На С есть библиотеки, де-факто ставшие стандартом в предметной области, на С++ аналогов нет
2. Ты утверждаешь, что есть и приводишь ссылки на обертки над С либами
3. Я говорю, что написать обертку не большое достижение
4. Ты говоришь, что сам писал обертку за пару вечеров и спрашиваешь "и?"
Друг, как у тебя самочувствие?
V>Под дотнет такая же по функциональности обертка могла занять рабочую неделю.
Чего? Во-первых, дотнет — не язык, а платформа. Ты собрался сразу в байткоде писать? Во-вторых, можешь привести пример, где на C# что-то сделать сложней, чем на С++? Вычисление факториала на этапе компиляции не считается. В-третьих, писать обертки, а потом обертки над обертками — традиционная забава С++ разработчиков, в C# уже есть System.Security.Cryptography
V>>>Ну покажи мне С++ компиляторы под архитектуры PIC, AVR, i51 MTD>>Для них нет компиляторов С++? Это что же ты так решил высказаться, что С++ отстой?
V>Так и дотнета под них нет.
У тебя проблемы с дотнетом? Я его нигде не упоминал, а у тебя он все чешется.
V>Может, это просто такие специфические архитектуры, что под них даже реализация языка идёт С в сильно урезанном виде?
С теперь тоже отстой? Итого, руководствуясь твоей логикой, выбрасываем С++, выбрасываем С, оставляем только ассемблер, потому, что на некоей сферической платформе в вакууме нет полноценных компиляторов С и С++.
V>QT — это просто хороший пример того, что не всё зависит только от языка. Язык же не в вакууме живёт, а на конкретных аппаратных и программных платформах.
Глубокомысленно. Что сказать хотел?
V>Поэтому, тот же GTK+ сугубо сишный.
Почему?
MTD>>Хочешь длиной меряться? Ну расскажи, что ты на С++ написал.
V>Какая прикладная область интересует?
Любая, чем больше всего гордишься?
V>Не требуют оборачивания структуры, перечисления, константы и т.д. и т.п.
Конечно требуют. Дефайны из С просто необходимо обернуть в неймспейсы и засунуть в перечисления.
Здравствуйте, MTD, Вы писали:
MTD>Что объединяет эти либы: libcurl, openssl, icu, zlib, ffmpeg, openal?
Этот бред еще продолжают обсуждать и на него еще продолжают ссылаться? OMG
Во-первых, часть библиотек специально разрабатывается на чистом C, поскольку:
a) язык C присутствует на большем количестве платформ, чем какой-либо другой язык (включая C++);
b) язык C упрощает использование библиотеки из других языков программирования, т.к. Perl, Python, Ruby, Erlang, PHP и пр., что гораздо сложнее сделать с библиотеками на C++.
Уже из-за этих двух факторов разработчики библиотек вынуждены выбирать чистый C, даже если они сами бы предпочли использовать вместо C какой-нибудь другой ЯП (и не обязательно это будет C++). Но есть и еще один фактор, а именно:
c) наличие уже существующей библиотеки на C делает ненужным повторение ее функциональности на C++, ибо сишные библиотеки являются родными для C++. Соответственно, нет смысла переписывать zlib на C++, если zlib уже без дополнительных телодвижений доступна для C++.
В принципе, разумным людям все это и так понятно, но поскольку все это приходится объяснять персонально господину MTD, то специально для MTD нужно указать один простой факт: в попытке натянуть сову на глобус вы включили в список чисто сишных библиотек библиотеку ICU, которая написана на C++. Так что сам этот список и попытки апелляции к нему уже можно спускать в /dev/null.
Здравствуйте, MTD, Вы писали:
MTD>ОМГ, какая дичь. POSIX существует с незапамятных времен, а в нем есть описание семафора — это такой примитив на котором элементарно строятся любые конструкции и который в С++ до сих пор не осилили.
Реализаций семафоров куча разных.
И ты не понял о чём речь.
Библиотеку Boost.Thread пилят с 2000-го года и на сегодня это уже 4-я её версия.
Все версии м/у собой не совместимы.
MTD>А то, что на каком-то утюге нет потоков, так просто на утюге не было бы файла thread.
Беда, беда.
Т.е. ты даже не понял, о чём тебе говорили.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, MTD, Вы писали:
MTD>>Что объединяет эти либы: libcurl, openssl, icu, zlib, ffmpeg, openal?
S>Этот бред еще продолжают обсуждать и на него еще продолжают ссылаться? OMG
Как вариант их объединяет то, что в отличии от никому не нужных трехколесных велосипедов написанных на коленках одаренных экспертов по всему на свете, этим активно пользуются и на этом хорошо зарабатывают.
Здравствуйте, vdimas, Вы писали:
V>Реализаций семафоров куча разных.
Почитай стандарт С++, раз уж решил в теме про С++ поговорить — в нем нет требований к реализации, только к интерфейсу.
V>И ты не понял о чём речь.
Нет, ты не понял. Пример устоявшегося интерфейса я привел — POSIX.
MTD>>А то, что на каком-то утюге нет потоков, так просто на утюге не было бы файла thread.
V>Беда, беда. V>Т.е. ты даже не понял, о чём тебе говорили.
Когда сказать нечего, но очень хочется, можно просто надуть щеки и обвинить собеседника в том, что он ничего не понимает — уныло, даже в средних классах школы уже не катит.
Здравствуйте, CreatorCray, Вы писали:
CC>Вот хуже стандарта чем Posix я пока не видел.
Я тоже. Но это пример для фантазеров которые хотят написать все сразу правильно, как результат — можно ждать до посинения, поскольку "правильно" с каждым днем меняется.
CC>Закопайте его уже наконец.
Здравствуйте, MTD, Вы писали:
V>>На язык С++ есть целая сетка версий стандартов. MTD>И в каком стандарте С++ есть спецификация, например, на алгоритмы криптографии?
Какие именно алгоритмы и от каких групп стандартов? ISO/IEC, ANSI, ITU, ГОСТ?
И почему алгоритмы криптографии надо стандартизировать ср-вами языка, а не отдать от откуп сторонним либам, реализующим оответствующие стандарты? Это что же получается, с выходом нового стандарта на криптографию надо будет синхронно выпускать новый стандарт С++?
V>>Обертка обертке рознь. MTD>1. На С есть библиотеки, де-факто ставшие стандартом в предметной области, на С++ аналогов нет
Наверно потому, что на С есть? А интероперабельность там прямая. Например, как в библиотеке ACE или boost, которые прекрасно реализуют обертки вокруг openssl.
Ну и не забываем, что сама openssl еще 2 года назад имела версию 0.9x, но было (и есть) полно коммерческих реализаций, которые показывали лучшую надёжность и эффективность, чем openssl, да и сейчас ситуация не сильно изменилась.
Ты прочищаешь данные потока после работы этой либы, ась?
Или пользуешь совсем новые её версии, которые такой прочистки не требуют.
А не смотрел, как в этой либе хранятся личные данные потока? Они все хранятся в общей структуре с общей блокировкой.
Ты предлагаешь тащить ЭТО в стандарт?
Да ни боже упаси.
MTD>2. Ты утверждаешь, что есть и приводишь ссылки на обертки над С либами
Ну ты же привёл лишь некие частности. При том, что есть просто тонна либ на С++, но их тоже никто не торопится включать в стандарт.
Я вообще не понимаю, зачем прикладные либы включать в стандарт.
Не пояснишь, случаем?
MTD>3. Я говорю, что написать обертку не большое достижение MTD>4. Ты говоришь, что сам писал обертку за пару вечеров и спрашиваешь "и?" MTD>Друг, как у тебя самочувствие?
У меня-то отличное. А вот если ты требуешь включить в стандарт некую сугубо прикладную функциональность, цена которой — пара вечеров работы, то я за тебя уже начинаю волноваться.
V>>Под дотнет такая же по функциональности обертка могла занять рабочую неделю. MTD>Чего? Во-первых, дотнет — не язык, а платформа.
Бла-бла-бла.
MTD>Ты собрался сразу в байткоде писать? Во-вторых, можешь привести пример, где на C# что-то сделать сложней, чем на С++?
Тебе бы пришлось расписать для интеропа лейаут всех структур. Там одна несчастная X509 чего стоит.
И это при том, что структуры openssl нифига не плоские, а образуют граф (как объекты), то тривиального интеропа не вышло бы. Т.е. вместо интеропа структур, надо каждый структуру заворачивать в объект и весьма так хитрожопо поддерживать актуальную "зеркальность" представления в дотнете и нейтиве.
MTD>Вычисление факториала на этапе компиляции не считается. В-третьих, писать обертки, а потом обертки над обертками — традиционная забава С++ разработчиков, в C# уже есть System.Security.Cryptography
Но это же не в стандарте, а в дополнительной либе.
По той самой причине, что делать обертку над openssl в дотнете — это застрелиться.
Поэтому там обертка над Windows CryptoAPI, но это же С++-ное АПИ! И опять ты с размаху улетел в лужу!
Причём, это АПИ постоянно дорабатывается. Т.е. опять надо стандарты языка перевыпускать аккурат с выпуском новых версий этого прикладного АПИ?
V>>>>Ну покажи мне С++ компиляторы под архитектуры PIC, AVR, i51 MTD>>>Для них нет компиляторов С++? Это что же ты так решил высказаться, что С++ отстой? V>>Так и дотнета под них нет. MTD>У тебя проблемы с дотнетом? Я его нигде не упоминал, а у тебя он все чешется.
Так С++ сравнить больше и не с чем, кроме как с голым С, дотнетом или жабкой.
С жабкой, ИМХО, сравнивать вовсе было бы не спортивно. ))
V>>Может, это просто такие специфические архитектуры, что под них даже реализация языка идёт С в сильно урезанном виде? MTD>С теперь тоже отстой?
Разумеется. Причём, обратного никто не обещал. Он с самого начала был разработан как низкоуровневый язык, как прямая замена ассемблеру. Поэтому, не надо из С лепить то, чем никогда не являлся и даже не предполагал являться от рождения.
MTD>Итого, руководствуясь твоей логикой, выбрасываем С++, выбрасываем С, оставляем только ассемблер, потому, что на некоей сферической платформе в вакууме нет полноценных компиляторов С и С++.
C — это и есть своеобразный ассемблер.
А из моей логики следует только то, что ты пропустил сеанс приёма успокоительных и ничего более.
Эдак тебя лихорадит...
V>>QT — это просто хороший пример того, что не всё зависит только от языка. Язык же не в вакууме живёт, а на конкретных аппаратных и программных платформах. MTD>Глубокомысленно. Что сказать хотел?
Что ты загоняешь по самое нибалуй. Ладно, с логикой не дружишь, это еще терпимо, можно было бы и объяснить простые вещи.
Но ты же агрессивно с ней не дружишь, на коллег бросаешься.
Причём, твоя лихорадочность более чем бессмысленна. Всё-таки, С++ — это не только комитет. Это еще разработчики компиляторов. Это огромная трудоёмкость по разработке таких компиляторов. Блин, да компиляторы С++ стали более-менее совместимы вот буквально лет 7 назад и то, на троечку с минусом. Т.е., вполне объективная инерционность есть, от неё не отмахнёшься.
V>>Поэтому, тот же GTK+ сугубо сишный. MTD>Почему?
Чтобы на совсем убогих платформах работать.
Ты смотрел когда-нибудь, как в GTK+ происходит присвоение значения a значению b, не?
Ну вот посмотри.
V>>Какая прикладная область интересует? MTD>Любая, чем больше всего гордишься?
— GUI 2D/3D;
— lock-free очереди, алгоритмы и даже реализации promise/future (ибо бустовские и STL-ные в некоторых сценариях приводят к дедлоку);
— самая быстрая в природе либа для сетки с учётом специфики бижевых протоколов (наша контора стабильно держит 1-2-е место в мире на ежегодных замерах от Intel);
— система конференций, VoIP;
— обработка звука, гитарные примочки в ассортименте;
Но горжусь я другим. Тем, что мне повезло когда-то плотно присесть на С++ более 20-ти лет назад и тем самым обеспечить себя интересной работой. Потому что и других языков в массе хватало (Дельфи, VB/VBA) и с низкоуровневыми подробностями дотнета разбирался, наверно, как никто на этом сайте. Но вот удовольствия в остальных "отраслях" не хватало. Потому что постоянно как гиря на ногах.
V>>Не требуют оборачивания структуры, перечисления, константы и т.д. и т.п. MTD>Конечно требуют. Дефайны из С просто необходимо обернуть в неймспейсы и засунуть в перечисления.
В хороших сишных либах константы идут как енумы. А плохие либы и на С++ бывают.
Иногда либа становится "стандартом де-факто" лишь по причине её опенсорсности, а не потому что она хороша.
Либа openssl ужасна до безобразия. Я боролся с ней еще с версий 0.98a.
Это тупое и кривое опенсорсное поделие, увы и ах.
Я дебажил её (у ней были неустранимые утечки памяти в некоторых сценариях), заходил пошагово в её внутренности, любовался...
Как мне теперь это развидеть?
И да, как ты собрался оборачивать дефайн в неймспейс? ))
Здравствуйте, MTD, Вы писали:
V>>Реализаций семафоров куча разных. MTD>Почитай стандарт С++, раз уж решил в теме про С++ поговорить — в нем нет требований к реализации, только к интерфейсу.
Интерфейс не с неба упал. Он сначала устоялся де-факто среди куч реализаций.
V>>И ты не понял о чём речь. MTD>Нет, ты не понял. Пример устоявшегося интерфейса я привел — POSIX.
Какой из версий?
MTD>Когда сказать нечего, но очень хочется, можно просто надуть щеки и обвинить собеседника в том, что он ничего не понимает — уныло, даже в средних классах школы уже не катит.
Здравствуйте, vdimas, Вы писали:
V>>>На язык С++ есть целая сетка версий стандартов. MTD>>И в каком стандарте С++ есть спецификация, например, на алгоритмы криптографии?
V>Какие именно алгоритмы и от каких групп стандартов? ISO/IEC, ANSI, ITU, ГОСТ?
Вообще на любой. Есть такое?
V>И почему алгоритмы криптографии надо стандартизировать ср-вами языка, а не отдать от откуп сторонним либам, реализующим оответствующие стандарты?
Ткни пальцем где я такое предлагал? Это ты что-то стал про стандарты говорить, но то ли сам запутался, то ли теперь дурачка решил включить.
V>Это что же получается, с выходом нового стандарта на криптографию надо будет синхронно выпускать новый стандарт С++?
Самому с собой каково разговаривать? Нравится?
V>Ты предлагаешь тащить ЭТО в стандарт?
Где я такое предлагал?
V>Я вообще не понимаю, зачем прикладные либы включать в стандарт.
О каких прикладных либах идет речь?
V>Не пояснишь, случаем?
Пояснить что? Твои фантазии?
MTD>>3. Я говорю, что написать обертку не большое достижение MTD>>4. Ты говоришь, что сам писал обертку за пару вечеров и спрашиваешь "и?" MTD>>Друг, как у тебя самочувствие?
V>У меня-то отличное.
Ок.
V>А вот если ты требуешь включить в стандарт некую сугубо прикладную функциональность, цена которой — пара вечеров работы, то я за тебя уже начинаю волноваться.
Смотри — в стандарте есть std::thread. Включаем режим тебя и начинаем:
1. На некоторых платформах потоков нет!
2. Полно прикладных библиотек!
3. Я напишу обертку за пару вечеров!
V>>>Под дотнет такая же по функциональности обертка могла занять рабочую неделю. MTD>>Чего? Во-первых, дотнет — не язык, а платформа.
V>Бла-бла-бла.
Да, по этой части ты мастер.
MTD>>Вычисление факториала на этапе компиляции не считается. В-третьих, писать обертки, а потом обертки над обертками — традиционная забава С++ разработчиков, в C# уже есть System.Security.Cryptography
V>Но это же не в стандарте, а в дополнительной либе.
У тебя какая-то каша в голове — есть повод пофейспалмить.
V>По той самой причине, что делать обертку над openssl в дотнете — это застрелиться.
Зачем ее делать? Есть System.Security.Cryptography
V>Поэтому там обертка над Windows CryptoAPI, но это же С++-ное АПИ!
И что? Если идти до конца, то все есть обертка над системными вызовами. А мы состоим из атомов.
V>И опять ты с размаху улетел в лужу!
Какие мыслительные процессы в голове приводят к таким замечательным выводам?
V>Так С++ сравнить больше и не с чем, кроме как с голым С, дотнетом или жабкой. V>С жабкой, ИМХО, сравнивать вовсе было бы не спортивно. ))
В смысле С++ слил бы? Ну да, писать веб сервера и работать с БД из С++ боль по сравнению с Явой. А вот написать тайм критикал код — уже на Яве боль.
MTD>>С теперь тоже отстой?
V>Разумеется.
Ок. С — отстой, С++ — отстой, Java — отстой. А что тогда не отстой?
MTD>>Итого, руководствуясь твоей логикой, выбрасываем С++, выбрасываем С, оставляем только ассемблер, потому, что на некоей сферической платформе в вакууме нет полноценных компиляторов С и С++.
V>А из моей логики следует только то, что ты пропустил сеанс приёма успокоительных и ничего более. V>Эдак тебя лихорадит...
Слился? Бедолага.
V>>>QT — это просто хороший пример того, что не всё зависит только от языка. Язык же не в вакууме живёт, а на конкретных аппаратных и программных платформах. MTD>>Глубокомысленно. Что сказать хотел?
V>Что ты загоняешь по самое нибалуй. Ладно, с логикой не дружишь, это еще терпимо, можно было бы и объяснить простые вещи. V>Но ты же агрессивно с ней не дружишь, на коллег бросаешься.
Попросить тебя обосновать. То есть привести тезисы, причем не придуманные тобой, а озвученные мной. Попросить привести цепочку логических доказательст и вдруг окажется, что ты наложил в штаны. Ну чисто по приколу, прошу. Покажи мои тезисы, покажи, что из них якобы следует, покажи нелогичность суждений.
V>>>Поэтому, тот же GTK+ сугубо сишный. MTD>>Почему?
V>Чтобы на совсем убогих платформах работать.
А чем Linux убог?
V>Ты смотрел когда-нибудь, как в GTK+ происходит присвоение значения a значению b, не? V>Ну вот посмотри.
Ну скажи как.
V>>>Какая прикладная область интересует? MTD>>Любая, чем больше всего гордишься?
V>- GUI 2D/3D; V>- lock-free очереди, алгоритмы и даже реализации promise/future (ибо бустовские и STL-ные в некоторых сценариях приводят к дедлоку); V>- самая быстрая в природе либа для сетки с учётом специфики бижевых протоколов (наша контора стабильно держит 1-2-е место в мире на ежегодных замерах от Intel); V>- система конференций, VoIP; V>- обработка звука, гитарные примочки в ассортименте;
Человек оркестр, не смеши
V>>>Не требуют оборачивания структуры, перечисления, константы и т.д. и т.п. MTD>>Конечно требуют. Дефайны из С просто необходимо обернуть в неймспейсы и засунуть в перечисления.
V>И да, как ты собрался оборачивать дефайн в неймспейс? ))
Руками. Может кодогенератор напишу, как проще будет.
Здравствуйте, vdimas, Вы писали:
V>>>Реализаций семафоров куча разных. MTD>>Почитай стандарт С++, раз уж решил в теме про С++ поговорить — в нем нет требований к реализации, только к интерфейсу.
V>Интерфейс не с неба упал. Он сначала устоялся де-факто среди куч реализаций.
Это ты так в сливе расписался? Ну ок.
MTD>>Нет, ты не понял. Пример устоявшегося интерфейса я привел — POSIX.
V>Какой из версий?
Что-то у тебя много фейспалмов. Головка бо-бо? Ну покажи в какой версии POSIX в интерфейс семафоров были внесены ломающие исправления.
MTD>>Когда сказать нечего, но очень хочется, можно просто надуть щеки и обвинить собеседника в том, что он ничего не понимает — уныло, даже в средних классах школы уже не катит.
V>Но ты действительно опускаешь смысл слов.
Здравствуйте, MTD, Вы писали:
MTD>>>Что объединяет эти либы: libcurl, openssl, icu, zlib, ffmpeg, openal?
S>>Этот бред еще продолжают обсуждать и на него еще продолжают ссылаться? OMG
MTD>Как вариант их объединяет то, что в отличии от никому не нужных трехколесных велосипедов написанных на коленках одаренных экспертов по всему на свете, этим активно пользуются и на этом хорошо зарабатывают.
Какой унылый персонаж. Все контраргументы выпилил и попытался заменить очередным бредом. Ну OK, раз приходиться разговаривать с MTD, значит будем разговаривать с MTD. Поинтересуйтесь на досуге, много ли на libcurl заработал автор libcurl. И насколько хороши финансовые дела у OpenSSL-проекта, как они собирают деньги, чтобы нанять хоть кого-нибудь на full-time для сопровождения и баг-фиксинг openssl.
Ну и наберитесь смелости на назовите вещи своими именами: под "одаренными экспертами" из форумов про C++ вы подразумеваете, в первую очередь, so5team. А под "трехколесными велосипедами" -- те проекты, которые so5team делает, в частности sobjectizer и restinio. И что у вас не хватило мозгов, чтобы понять, как использовать sobjectizer, а так же смелости, чтобы попросить совета. И что у вас не хватило мозгов и кругозора, чтобы понять, для каких целей могут использоваться проекты вроде restinio (а так же c++ rest sdk, pistache и restbed, попадающие в ту же категорию). Но вы чувствуете свою ограниченность и нюх вам подсказывает, что вы не можете нормально жить в мире современного С++, откуда и возникает желание создавать подобные темы в flame.comp. А когда вас даже здесь тыкают носом в несостоятельность ваших же аргументов, вы трусливо удаляете все, что не можете опровергнуть и генерируете новый бездоказательный бред.
Здравствуйте, so5team, Вы писали:
S>Какой унылый персонаж. Все контраргументы выпилил
Да, ты малость притомил, приходится твою нудную мотню обрезать.
S>Ну OK, раз приходиться разговаривать с MTD, значит будем разговаривать с MTD.
Тебя будто кто заставляет? rumit7 наверное сидит и стимул тебе тычет.
S>Поинтересуйтесь на досуге, много ли на libcurl заработал автор libcurl.
А я не авторов библиотек имел в виду, то что они не бизнесмены и не смогли монетизировать свой труд я допускаю.
S>Ну и наберитесь смелости на назовите вещи своими именами: под "одаренными экспертами" из форумов про C++ вы подразумеваете, в первую очередь, so5team.
А ты разве одаренный эксперт? Или твоя экспертиза делать ненужную работу и быдлить на форуме? Тогда признаю — ты эксперт.
S>И что у вас не хватило мозгов, чтобы понять, как использовать sobjectizer
Ага, а так-то все эту поделку используют.
S>а так же смелости, чтобы попросить совета
О божечки, да кому это надо?
S>И что у вас не хватило мозгов и кругозора
Повторяешься. Поисписался.
S>для каких целей могут использоваться проекты вроде restinio
Отчего же? Понимаю, ты так мир покорить собрался. Увы, миру студенческие поделки не особо интересны, сначала заработай авторитет, чтобы можно было понять, что люди серьезные делали.
S>вы не можете нормально жить в мире современного С++
Отчего же? Могу. Современный С++ меня неплохо кормит, но на самом деле пофиг — это просто инструмент, а не религия.
S>откуда и возникает желание создавать подобные темы в flame.comp.
Желание у меня одно — религиозных фанатиков побесить. Удается на отлично.
Здравствуйте, MTD, Вы писали:
MTD> Да, ты малость притомил, приходится твою нудную мотню обрезать.
Так и запишем: в нормальную дискуссию MTD не смог.
S>>Поинтересуйтесь на досуге, много ли на libcurl заработал автор libcurl.
MTD>А я не авторов библиотек имел в виду, то что они не бизнесмены и не смогли монетизировать свой труд я допускаю.
Тогда кого вы имеете в виду?
S>>Ну и наберитесь смелости на назовите вещи своими именами: под "одаренными экспертами" из форумов про C++ вы подразумеваете, в первую очередь, so5team.
MTD>А ты разве одаренный эксперт? Или твоя экспертиза делать ненужную работу и быдлить на форуме? Тогда признаю — ты эксперт.
Т.е. смелости не хватило. Ну MTD как он есть.
S>>И что у вас не хватило мозгов, чтобы понять, как использовать sobjectizer
MTD>Ага, а так-то все эту поделку используют.
Да я вам страшное скажу: примеры, которые вы выше приводили, т.е. те же libcurl и libopenssl, используют далеко не все. Представляете? Или это для вас очередной разрыв шаблона?
S>>а так же смелости, чтобы попросить совета
MTD>О божечки, да кому это надо?
Вам. Вы же хотели использовать sobjectizer, даже материалы по нему прочитали, но не смогли, сами же рассказывали.
S>>И что у вас не хватило мозгов и кругозора
MTD>Повторяешься. Поисписался.
Есть надежда, маленькая правда, но есть, что только повторением в вашу голову можно загнать хоть-чуть достоверной информации.
S>>для каких целей могут использоваться проекты вроде restinio
MTD>Отчего же? Понимаю, ты так мир покорить собрался.
Браво! Может вы еще диагнозы по фото ставите? Порчу снимаете, приворотами через Интернет занимаетесь. Только такими талантами можно объяснить ваш вывод.
S>>вы не можете нормально жить в мире современного С++
MTD>Отчего же? Могу. Современный С++ меня неплохо кормит, но на самом деле пофиг — это просто инструмент, а не религия.
Ну достаточно посмотреть на ваши лисапеды, чтобы не поверить вам на слово.
Здравствуйте, so5team, Вы писали:
S>Так и запишем: в нормальную дискуссию MTD не смог.
С тобой-то? Звучит как анекдот.
MTD>>А ты разве одаренный эксперт? Или твоя экспертиза делать ненужную работу и быдлить на форуме? Тогда признаю — ты эксперт.
S>Т.е. смелости не хватило. Ну MTD как он есть.
Смелости на что? Что я хочу я говорю прямо. Конкретно ты в моих глазах — хамло и очень обидчивый человек с очень большими комплексами, который делает нелепые велосипеды и очень обижается когда его кто-то не хвалит.
S>>>И что у вас не хватило мозгов, чтобы понять, как использовать sobjectizer
MTD>>Ага, а так-то все эту поделку используют.
S>Да я вам страшное скажу: примеры, которые вы выше приводили, т.е. те же libcurl и libopenssl, используют далеко не все.
Это очевидно. Кому по http/https не надо в качестве клиента взаимодействовать те и не используют. А твою поделку только в одном месте используют — удалось тебе в свое время подсадить и то не факт, что соскочить не хотят.
S>Вам. Вы же хотели использовать sobjectizer, даже материалы по нему прочитали, но не смогли, сами же рассказывали.
Да, некоторые пассажи меня очень удивили, знакомство с кодом тоже произвело не лучшее впечатление, тяга к велосипедостроению насторожила (я про твою систему сборки).
S>>>И что у вас не хватило мозгов и кругозора
MTD>>Повторяешься. Поисписался.
S>Есть надежда, маленькая правда, но есть, что только повторением в вашу голову можно загнать хоть-чуть достоверной информации.
Говорить, что у меня мало мозгов, что я мудак и малолетний дебил — информация сомнительной ценности, да и с достоверностью ее тоже все плохо.
S>Браво! Может вы еще диагнозы по фото ставите? Порчу снимаете, приворотами через Интернет занимаетесь. Только такими талантами можно объяснить ваш вывод.
Поциент, все ваши проблемы вы выставляете напоказ, тут не надо мегапсихологом быть.
Здравствуйте, MTD, Вы писали:
V>>>>На язык С++ есть целая сетка версий стандартов. MTD>>>И в каком стандарте С++ есть спецификация, например, на алгоритмы криптографии? V>>Какие именно алгоритмы и от каких групп стандартов? ISO/IEC, ANSI, ITU, ГОСТ? MTD>Вообще на любой. Есть такое?
V>>И почему алгоритмы криптографии надо стандартизировать ср-вами языка, а не отдать от откуп сторонним либам, реализующим оответствующие стандарты? MTD>Ткни пальцем где я такое предлагал? Это ты что-то стал про стандарты говорить, но то ли сам запутался, то ли теперь дурачка решил включить.
Про "индустиальный стандарт" ты повторил более одного раза.
Это была спекуляция или как понимать?
В общем, в любом случае ты сильно ошибаешься.
OpenSSL — это не стандарт ни разу.
Более-менее широко его начали использовать буквально в 2011-2012-м году, и то, в основном на серверсайде в линухах.
И то, среди всего серверсайда OpenSSL замечен на менее 2/3-х серваков с SSL.
А на клиенте его, считай, нет (есть, но мало).
Потому что есть другое: http://www.gnutls.org https://developer.mozilla.org/ru/docs/NSS
И еще всякие коммерческие либы.
Это не считая платформенного виндового, который круче OpenSSL в бесконечное кол-во раз, бо предоставляет из себя целую инфраструктуру для обеспечения безопасности, в отличие от OpenSLL, где инфраструктуру народ накручивает в меру своей испорченности.
V>>Ты предлагаешь тащить ЭТО в стандарт? MTD>Где я такое предлагал?
Ну ты называл OpenSSL "промышленным стандартом".
А я называю его своим именем и поймал тебя на том, что глубоко ты в OpenSSL не вникал, хоть и писал для него обертку. ))
V>>А вот если ты требуешь включить в стандарт некую сугубо прикладную функциональность, цена которой — пара вечеров работы, то я за тебя уже начинаю волноваться. MTD>Смотри — в стандарте есть std::thread.
Я на это уже отвечал.
Они разрабатывались 17 лет.
И да. Ты опять про стандарт, хотя абзацем выше спрашивал "почему обязательно стандарт?"
Расколбас, аднака.
MTD>Включаем режим тебя и начинаем: MTD>1. На некоторых платформах потоков нет!
На С++ под такие платформы уже не пишут.
EC++ умер, но был популярен еще до 2010-го.
Это важный пункт, ес-но.
Но это не единственный пункт.
MTD>2. Полно прикладных библиотек!
Верно. Жили же как-то этого, не умерли.
MTD>3. Я напишу обертку за пару вечеров!
Так и было.
Проблема была в функциональном типе, move-семантике, exception_ptr, future/promise. Всё это в первую очередь для передачи данных м/у потоками было разработано. И все эти вещи пилились в бусте тоже 17 лет.
Ты разве не заметил, что std::thread вышли одновременно c лямбдами/функциями, move, future/promise и exception_ptr?
Видишь, какой длинный там хвост? А тебе всё хиханьки-хаханьки.
Кароч, никому не нужны были кальки с уже имеющихся платформенных АПИ, они и без внесения их в стандарт неплохо работали, поэтому и не было раньше никаких std::thread.
На сегодня точно так же не нужны либы, навроде OpenSSL в С++.
Потому что нужна законченная инфраструктура:
— хранение артефактов безопасности;
— сетевого транспорта over несколько протоколов.
Т.е., тут тоже приличный хвост, поэтому, еще рано рассуждать о "промышленном стандарте де факто на SSL/TLS в мире С++". Потому что перечисленные мною вещи еще не устаканились, а "находятся в активном поиске", как грится.
MTD>>>Чего? Во-первых, дотнет — не язык, а платформа. V>>Бла-бла-бла. MTD>Да, по этой части ты мастер.
Ну замечание относительно дотнета/C# уж точно бестолковое, что для меня, что для любого читателя. Дотнет чай не вчера вышел.
V>>Но это же не в стандарте, а в дополнительной либе. MTD>У тебя какая-то каша в голове — есть повод пофейспалмить.
Ну ты ж привел крайне неудачный пример.
Продолжая педалировать эту тему лишь еще больше подставляешься.
1. Эта либа НЕ разработана в рамках дотнета, в дотнете там только обертка. Т.е. когда для C++ обертка, то, почему-то, это минус, а когда для дотнета, то плюс. Оригинально!
2. Ты спрашивал "ну и где либы для С++" и приводишь пример из дотнета, который к несчатью для тебя является оберткой над плюсовой либой. Рука-лицо, аднака. Торопишься, ошибаешься.
V>>По той самой причине, что делать обертку над openssl в дотнете — это застрелиться. MTD>Зачем ее делать? Есть System.Security.Cryptography
А как же твой "индустриальный стандарт" OpenSSL? ((
Ладно, опять лицо к руке и сорри, я на этом прервусь. Процент противоречий самому себе зашкаливает, всё бессмысленно, ты просто на что-то зол, а я тебе под руку попался. В такой ипостаси ты мне более чем не интересен, скучен до безобразия, сорри за прямоту.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, MTD, Вы писали:
V>>>>>На язык С++ есть целая сетка версий стандартов. MTD>>>>И в каком стандарте С++ есть спецификация, например, на алгоритмы криптографии? V>>>Какие именно алгоритмы и от каких групп стандартов? ISO/IEC, ANSI, ITU, ГОСТ? MTD>>Вообще на любой. Есть такое?
V>В гугле забанили? V>https://www.cryptopp.com/ V>https://botan.randombit.net/
А причем тут стандарт С++? Совсем тебе поплохело?
V>Более-менее широко его начали использовать буквально в 2011-2012-м году, и то, в основном на серверсайде в линухах.
Не более-менее, а чуть менее, чем везде.
V>А на клиенте его, считай, нет (есть, но мало).
Лол, что? Навскидку — Telegram, ICQ.
V>>>Ты предлагаешь тащить ЭТО в стандарт? MTD>>Где я такое предлагал?
V>Ну ты называл OpenSSL "промышленным стандартом".
И как из этого следует, что его нужно добавить в стандарт С++? Совсем ты заврался.
V>Расколбас, аднака.
Да, колбасит тебя — мое почтение.
MTD>>1. На некоторых платформах потоков нет!
V>На С++ под такие платформы уже не пишут.
Зачем ты тогда такой аргумент использовал?
MTD>>2. Полно прикладных библиотек!
V>Верно. Жили же как-то этого, не умерли.
Да и без С++ не умирали, а до этого и без С жили.
MTD>>3. Я напишу обертку за пару вечеров!
V>Так и было.
В результате, все вместо того чтобы решать проблемы пользователей пилили велосипеды разной степени глючности.
V>move-семантике. И все эти вещи пилились в бусте тоже 17 лет.
Чего?
V>Кароч, никому не нужны были кальки с уже имеющихся платформенных АПИ, они и без внесения их в стандарт неплохо работали, поэтому и не было раньше никаких std::thread.
Тебе были не нужны, а всем остальным были нужны, поэтому буст тащили чуть менее, чем все.
V>На сегодня точно так же не нужны либы, навроде OpenSSL в С++.
Ты опять сам с собой разговариваешь. Я нигде не говорил, что аналог OpenSSL должен быть в стандарте С++. Либо заканчивай, либо покажи где я такое говорил, иначе придется считать тебя маразматиком и вруном.
V>Ну замечание относительно дотнета/C# уж точно бестолковое, что для меня, что для любого читателя. Дотнет чай не вчера вышел.
Чего? Ты разговариваешь, будто под мухоморами.
V>Ну ты ж привел крайне неудачный пример. V>Продолжая педалировать эту тему лишь еще больше подставляешься.
Чего пример? Что ты несешь? Я тебя уже не понимаю. Изложи кратко свои тезисы, муть сплошная же.
MTD>>Зачем ее делать? Есть System.Security.Cryptography
V>А как же твой "индустриальный стандарт" OpenSSL? ((
Так он для С/С++ индустриальный стандарт.
V>Ладно, опять лицо к руке и сорри, я на этом прервусь. Процент противоречий самому себе зашкаливает, всё бессмысленно, ты просто на что-то зол, а я тебе под руку попался. В такой ипостаси ты мне более чем не интересен, скучен до безобразия, сорри за прямоту.
Как только его попросили изложить тезисы и показать цепочку логических рассуждений — куча в штаны и слив. Ну давай, не хворай.
Здравствуйте, MTD, Вы писали:
S>>Так и запишем: в нормальную дискуссию MTD не смог.
MTD>С тобой-то? Звучит как анекдот.
Да только одна эта тема показывает, что ни с кем вообще. А ведь это не единственная тема. Так что вы ссытесь и удаляете то, на что не можете ответить.
S>>Да я вам страшное скажу: примеры, которые вы выше приводили, т.е. те же libcurl и libopenssl, используют далеко не все.
MTD>Это очевидно. Кому по http/https не надо в качестве клиента взаимодействовать те и не используют.
Гы-гы-гы, да вы живете в каком-то уютненьком менямирке. libcurl и libopenssl многие не используют как раз для взаимодействия по http/https.
MTD>А твою поделку только в одном месте используют — удалось тебе в свое время подсадить и то не факт, что соскочить не хотят.
Не переживайте, не в одном.
S>>Вам. Вы же хотели использовать sobjectizer, даже материалы по нему прочитали, но не смогли, сами же рассказывали.
MTD>Да, некоторые пассажи меня очень удивили, знакомство с кодом тоже произвело не лучшее впечатление, тяга к велосипедостроению насторожила (я про твою систему сборки).
Ну т.е. мозгов таки не хватило. Так и запишем.
S>>Есть надежда, маленькая правда, но есть, что только повторением в вашу голову можно загнать хоть-чуть достоверной информации.
MTD>Говорить, что у меня мало мозгов, что я мудак и малолетний дебил — информация сомнительной ценности, да и с достоверностью ее тоже все плохо.
В данном случае приходится говорить, например, о том, что libcurl и libopenssl используются далеко не всеми (именно для взаимодействия по http/https) и о том, что ICU написан на C++. Даже такие простые вещи до вас не доходят. Продолжите тормозить в таком же стиле и вывод о "малолетнем дебилизме" начнет напрашиваться сам собой не только у меня.
Здравствуйте, MTD, Вы писали:
MTD>Хамло, мне не интересно на каждый твой перл отвечать. Так что смирись, я тебе не бабушка и не мама — мне на тебя и твои чувства положить.
Вот вся суть общения с вами: вам говоришь об объективных причинах, по которым общеупотребительные библиотеки разрабатываются на C, про то, что ICU написан на C++, про том, что libopenssl используется далеко не везде... В ответ лишь "хамло", "поциент", "существо". MTD как он есть.
Здравствуйте, MTD, Вы писали:
S>>В ответ лишь "хамло", "поциент", "существо".
MTD>Обиделся?
Диагнозы по Интернету -- это не ваш конек, заканчивайте народ веселить.
Просто констатация факта: вам технические аргументы -- вы, в ответ, оскорбления. Вы хоть понимаете, что таким образом вы свою репутацию специалиста опускаете ниже плинтуса? Что после подобных разговоров любой ваш технический аргумент или претензия к чему-либо (например, к качеству кода) не будет воспринята всерьез.
Здравствуйте, so5team, Вы писали:
S>Диагнозы по Интернету -- это не ваш конек, заканчивайте народ веселить.
А кто веселится? Ну кроме меня? То что с тобой происходит весельем не назвать, а все остальные уже задолбались читать, возможно кроме твоего дружка rumit7.
Здравствуйте, MTD, Вы писали:
V>>Интерфейс не с неба упал. Он сначала устоялся де-факто среди куч реализаций. MTD>Это ты так в сливе расписался? Ну ок.
Это у меня слив? ))
Слушай, ты бы хотя бы почитал про Lock Concept (BasicLockable, Lockable).
Вот почему ранее в С++ обертках над теми же pthread в операции с condvar подавали ссылку непосредственно на мьютекс (и в первых версиях Boost.Thread тоже), но сейчас как аргумент подают тот самый unique_lock, который по-сути guard, а не сам mutex? Не разбирался еще, почему так резко дизайн эволюционировал, не? А с шашкой наголо, однако, торопимся бежим... ))
MTD>>>Нет, ты не понял. Пример устоявшегося интерфейса я привел — POSIX. V>>Какой из версий? MTD>Что-то у тебя много фейспалмов.
Да потому что кач-во твоего обсуждения именно таково.
Куча популярных систем декларируют, что совместимы с POSIX, но де-факто плохо совместимы м/у собой.
Потому что версий POSIX слишком много.
Даже внутри экосистемы Linux различные её семейства показывают различную степень совместимости с POSIX и, соответственно, друг с другом.
Если ты этого не знал, то изволь любоваться заслуженной рукой у лица.
Если же знал, но просто злостно троллишь, то ты редиска.
Здравствуйте, MTD, Вы писали:
V>>>>>>На язык С++ есть целая сетка версий стандартов. MTD>>>>>И в каком стандарте С++ есть спецификация, например, на алгоритмы криптографии? V>>>>Какие именно алгоритмы и от каких групп стандартов? ISO/IEC, ANSI, ITU, ГОСТ? MTD>>>Вообще на любой. Есть такое? V>>В гугле забанили? V>>https://www.cryptopp.com/ V>>https://botan.randombit.net/ MTD>А причем тут стандарт С++? Совсем тебе поплохело?
Да тебя колбасит от неких стандартов до "а где же библиотеки С++".
Я должен синхронизироваться с твоими колебаниями, что ле?
Про педалирование темы "стандартов" ответил — ты НЕ понимаешь, откуда растут ноги у текущей ситуации. Легкомысленен в обращении со словом "стандарт".
Про примеры либ на С++ — тоже дал уже достаточно.
Не угомонился еще?
Здравствуйте, vdimas, Вы писали:
V>Это у меня слив? ))
Естественно. Отвечаешь невпопад, включил бредогенератор, приписываешь мне свои фантазии.
V>Слушай, ты бы хотя бы почитал про Lock Concept (BasicLockable, Lockable).
И что я должен вынести из этого чтения? Или это ты просто так забалтываешь?
V>Если ты этого не знал, то изволь любоваться заслуженной рукой у лица.
Ты так и не сказал в какой версии POSIX интерфейс семафора сломали.
Здравствуйте, vdimas, Вы писали:
V>>>>>>>На язык С++ есть целая сетка версий стандартов. MTD>>>>>>И в каком стандарте С++ есть спецификация, например, на алгоритмы криптографии? V>>>>>Какие именно алгоритмы и от каких групп стандартов? ISO/IEC, ANSI, ITU, ГОСТ? MTD>>>>Вообще на любой. Есть такое? V>>>В гугле забанили? V>>>https://www.cryptopp.com/ V>>>https://botan.randombit.net/ MTD>>А причем тут стандарт С++? Совсем тебе поплохело?
V>Да тебя колбасит от неких стандартов до "а где же библиотеки С++". V>Я должен синхронизироваться с твоими колебаниями, что ле?
Ты упорот чтоли?
Вот ты писал:
На язык С++ есть целая сетка версий стандартов.
Затем пишешь:
Какие именно алгоритмы и от каких групп стандартов? ISO/IEC, ANSI, ITU, ГОСТ?
Здравствуйте, MTD, Вы писали:
MTD>Лол, что? Навскидку — Telegram, ICQ.
1% посетителей этого сайта пользуются перечисленным.
Зато браузерами пользуются все и там нет OpenSSL ни в одном из популярных.
MTD>>>1. На некоторых платформах потоков нет! V>>На С++ под такие платформы уже не пишут. MTD>Зачем ты тогда такой аргумент использовал?
Потому что он объясняет, почему std:thread вышли именно тогда, когда вышли.
Слишком много звёзд сошлось в одной точке.
В том числе насчёт аппаратно-программных платформ, на которых сегодня живёт С++.
V>>Верно. Жили же как-то этого, не умерли. MTD>Да и без С++ не умирали, а до этого и без С жили.
Голый С — это тоже гиря на ногах в сравнении с С++.
Даже в сравнении с С++ образца 91-го года (моё с ним первое знакомство).
MTD>В результате, все вместо того чтобы решать проблемы пользователей пилили велосипеды разной степени глючности.
Разной степени уникальности под уникальные сценарии.
Я повидал за эти годы много. Современный стандарт был бы еще лет 15 назад более чем бесполезен и даже вреден.
Хотя, уже в середине 2000-х пришёлся бы кстате.
Просто должен был сдохнуть целый огромный зоопарк embedded-недоплатформ, куда тоже пихали различные диалекты С++.
Сейчас этот зоопарк успешно сдох и произошёл чёткий водораздел: платформы, где С++ не имеет смысла vs платформы, где он может быть реализован полностью. Вот этого бесконечного градиента больше нет. И это ты даже не представляешь, насколько удобно. Но эти же вещи надо понимать... А ты как только с Луны упал и проспал всю историю от конца 90-х.
V>>move-семантике. И все эти вещи пилились в бусте тоже 17 лет. MTD>Чего?
Да вот того. Изначально он нужно было для передачи данных м/у потоками. Это потом уже обобщилось на всё подряд.
Или ты был не в курсе, что эту семантику сугубо в библиотечном виде в Бусте пилили относительно давно?
V>>Кароч, никому не нужны были кальки с уже имеющихся платформенных АПИ, они и без внесения их в стандарт неплохо работали, поэтому и не было раньше никаких std::thread. MTD>Тебе были не нужны, а всем остальным были нужны, поэтому буст тащили чуть менее, чем все.
Без exception_ptr, без function, без promise/future, от thread остаётся лишь обертка в одну строчку над _beginthreadex и пару строчек над pthread_create.
Кому для такой функциональности действительно нужен был boost, тому нечего делать в С++.
V>>На сегодня точно так же не нужны либы, навроде OpenSSL в С++. MTD>Ты опять сам с собой разговариваешь. Я нигде не говорил, что аналог OpenSSL должен быть в стандарте С++. MTD>Либо заканчивай, либо покажи где я такое говорил, иначе придется считать тебя маразматиком и вруном.
"В С есть стандарты де-факто"
Про дотнет ответил "так есть уже" в контексте того, что в дотнете идет "в поставке", а в С++ не идёт.
В С++ тоже идёт "в поставке".
Под виндами CryptoAPI, под линухами openssl, GNU TLS.
А далее простая проверка на вшивость, как грится. Если тебе в этом месте (вдруг) захотелось заикнуться о несовместимости АПИ указанных библиотек, то можешь самостоятельно сделать goto на начало и так по кругу.
Ну и на закуску, в кач-ве примера более одного раза педалировал стандартный std::thread, что-то там показывая (пытаясь) на его примере.
V>>Ну замечание относительно дотнета/C# уж точно бестолковое, что для меня, что для любого читателя. Дотнет чай не вчера вышел. MTD>Чего? Ты разговариваешь, будто под мухоморами.
Т.е. мне надо было целый трактат расписать о том, почему замечания подобного рода совершенно бестолковы и ничего не дают для обсуждения?
Считай тот абзац литературной версией междометия "пфф".
MTD>Чего пример? Что ты несешь? Я тебя уже не понимаю. Изложи кратко свои тезисы, муть сплошная же.
Да всё изложено. Потрачено было время. Но ты слишком легко обходишься с указанными причинами, которые, вообще-то, объективны и все вместе составляют нехилый такой комплекс с другими причинами (которых под тысячу наберется легко), описывающих систему с очень даже ненулевой инерционностью. Ты хоть представляешь себе, во сколько индустрии обошлось бы каждое неверное решение относительно стандарта языка С++ и его библиотек? Это насчёт std::thread в том числе. В стандарт пошёл аж только 4-й вариант, из обкатываемых в Бусте в течении мать его 17-ти лет.
Ну и да. Кросс-платформенных библиотек на С++ во все времена хватало. Как платных, так и бесплатных. Бусте, ACE, IPP и т.д., имя которым — легион.
V>>А как же твой "индустриальный стандарт" OpenSSL? (( MTD>Так он для С/С++ индустриальный стандарт.
Здрасьте, в каком из мест? ))
Не, мы в своих изделиях тоже его юзаем (потому что в том числе серверная сторона), но как-то отчёт себе отдаём относительно его реальной ниши.
MTD>Как только его попросили изложить тезисы и показать цепочку логических рассуждений — куча в штаны и слив. Ну давай, не хворай.
А смысл уже? Интересной беседы не получилось, этого пациента можно смело хоронить, может, в другой раз выйдет.
# Packages needed for development
dev_list="\
libssl-dev
Дальше можно не читать, что ты пишешь — репутацию балабола ты заработал. Мои поздравления.
MTD>>Как только его попросили изложить тезисы и показать цепочку логических рассуждений — куча в штаны и слив. Ну давай, не хворай.
V>А смысл уже? Интересной беседы не получилось, этого пациента можно смело хоронить, может, в другой раз выйдет.
Здравствуйте, MTD, Вы писали:
V>>Я должен синхронизироваться с твоими колебаниями, что ле? MTD>Ты упорот чтоли? MTD>Вот ты писал: MTD>Затем пишешь: MTD>И наконец:
Так а что ж ты себя поскипал-то?
Я их привел по одной причине — это индустриальный стандарт, на С++ нет ничего подобного, что идет вразрез с твоими словами, что все либы есть на С++.
...
Давай больше конкретики
...
V>Индустриальных стандартов много, как и комитетов по стандартизации.
V>Разумеется, С++ такой же индустриальный стандарт.
У тебя какая-то каша в голове. Например, никто их не стандартизировал, просто используют все в индустрии, а на С++ сообщество не осилило сделать ничего такого же уровня.
V>На язык С++ есть целая сетка версий стандартов.
И в каком стандарте С++ есть спецификация, например, на алгоритмы криптографии?
...
1. На С есть библиотеки, де-факто ставшие стандартом в предметной области, на С++ аналогов нет
...
Смотри — в стандарте есть std::thread.
И далее доказательство от противного, почему надо было тащить это в стандарт.
Но я что я ответил несколькими тезисами:
* рассуждения об "индустриальных стандартах" — бессмысленные, являются спекуляциями; Тем более, что для C++ слово "стандарт" не пустозвонство, в отличие от С, где де-факто до сих пор пишут в стиле C90, т.е. на стандарте почти 30-тилетней давности.
* привел названия нескольких популярных опенсорсных библиотек (boost, ACE, Mozilla NSS) оперирующих SSL/TLS + пару ссылок на высококачаствественные, но не опенcорсные либы, но тоже популярные в сценариях, когда не стоит ограничение обойтись непременно опенсорсом.
Попытки аппелировать к тому, что boost и ACE сами используют OpenSSL так же будут являться спекуляцией, бо они довольно-таки качественно прячут подробности относительно именно OpenSSL, т.е. в будущем этот backend (назовём так) может быть заменён на другой.
* показал зависимости библиотеки std::thread, которые де-факто чудовищные, бо опираются как на кучу новых стандартных типов, так и на изменения в самом языке — на поддержку компилятором введенных в язык новых сущностей: exception_ptr, current_exception и move-семантики.
Отсюда я заключил, что аргументация твоя не продуманная, ты пытаешься продавить поверхностность по таким непростым вопросам и тем самым трепешь коллегам нервы. Никакого другого выхлопа от всей этой херни не было.
Здравствуйте, so5team, Вы писали:
S>>>получаем удовольствие от сирости и убогости.
MTD>>А вот это зря, надо расти и становится лучше.
S>Т.е. вы предлагаете нам перестать получать удовольствие от вашей сирости и убогости?
Я даже написал, что нужно делать:
надо расти и становится лучше
Но видимо поциент при чтении моих сообщений, дальше 4 слов прочесть не в состоянии.
Здравствуйте, MTD, Вы писали:
S>>>>получаем удовольствие от сирости и убогости.
MTD>>>А вот это зря, надо расти и становится лучше.
S>>Т.е. вы предлагаете нам перестать получать удовольствие от вашей сирости и убогости?
MTD>Я даже написал, что нужно делать:
MTD>
MTD>надо расти и становится лучше
MTD>Но видимо поциент при чтении моих сообщений, дальше 4 слов прочесть не в состоянии.
Смеяться над больными и убогими -- это нехорошо, вы правы. Нужно расти и становиться лучше, чтобы этого не делать. Но, повторимся, до такой степени самосовершенствования, чтобы перестать смеяться над вами, мы не сможем дорасти.
Ваши попытки остроумия настолько же убоги, как и попытки уйти от обсуждения технических аргументов.
Здравствуйте, so5team, Вы писали:
MTD>>Но видимо поциент при чтении моих сообщений, дальше 4 слов прочесть не в состоянии.
S>Смеяться над больными и убогими -- это нехорошо, вы правы.
Хамло все пытается меня задеть. Продолжай, мне очень, очень важно, что там кто-то в интернете про меня пишет.
S>Ваши попытки остроумия настолько же убоги, как и попытки уйти от обсуждения технических аргументов.
Отчего убоги? Задница у тебя и у пары других существ полыхает мое почтение. А теперь пиши, что ты сюда ходишь совсем не от того, что бомбит
Здравствуйте, MTD, Вы писали:
MTD>Что я тут должен увидеть кроме того, что BoringSSL — форк OpenSSL?
Именно это и должен был увидеть — Хром не использует OpenSSL.
Ссылку на репозиторий BoringSSL я дал, в мастере последний коммит был буквально вчера. Можешь сравнить содержимое репозитория с OpenSSL.
V>>Как ознакомишься с материалом, приходи. MTD>Как перестанешь упарываться и станешь следить за словами приходи.
Смешной ты, аднака. Дважды потребовал от меня сформулировать мою т.з. целиком, но когда я сделал это, ты остановился на комментировании OpenSSL В Хроме.
Вот в этом ты весь. Тебе не нужен обмен информацией, тебе лишь бы посраться и "поймать" кого-нибудь. Но ввиду своей поверхностности, с ловлей тоже бока. Всё вместе — мелочность и дичайшая глупость.
Здравствуйте, push, Вы писали:
P>Хах)) Это можно про любую библиотеку с++ сказать — "а разве нет кросс-платформенных библиотек XXXX?". P>Теоретически как бы всё есть. Теоретически. P>А практически оно в таком виде (или сложность или способы использования), что можно сказать нет.
Можно пример сложностей в какой-нить из либ корутин?
Здравствуйте, push, Вы писали:
P>Ну нравится-не нравится, оно есть. P>Я не пойму какую мысль ты этим пытаешься дать? Что основные программные примитивы невозможно стандартизовать? P>Серьезно? Ну вот во всех языках получается.
Разве модули работы со звуком идут как стандарт языка? Или это всё-таки некие либы сверху?
Здравствуйте, vdimas, Вы писали:
V>Именно это и должен был увидеть — Хром не использует OpenSSL.
А использует форк OpenSSL, а Chromium на котором Opera и еще пучек браузеров используют OpenSSL, а ты говорил никто. Вот такой ты балабол.
MTD>>Как перестанешь упарываться и станешь следить за словами приходи.
V>Смешной ты, аднака.
Только тебе отчего то не смешно — задница дымит любо дорого глядеть, ну ка еще минусов поставил.
Здравствуйте, MTD, Вы писали: MTD>Просто направленность сишных либ показывает, что в С сообществе занимаются решением практических вопросов, а сообщество С++ занято в основном написанием нелепыт тормозных велосипедов (Буст).
Нет никакого "сообщества C++", точно так же как нет "сообщества C#/Java/...". Eсть только конкретные задачи и конкретные начальные условия. Всё остальное — это инсинуации а теоретизирование на пустом фундаменте.
Здравствуйте, push, Вы писали:
P>У тебя просто походу нет опыта работы с большими проектами (исходники больше 1 ГБ) и в больших компаниях (программеров больше 300). P>В таких случаях абсолютно все без исключений приходят к необходимости стандартизации и унификации. Она ставится как цель номер один, иначе проект/компания утонет (более того — это логично, и это уже произошло во всех остальных областях деятельности). Это номер раз почему "везде xml".
Мы используем ХМЛ на плюсах. Что мы делаем не так?
Дальше вы там ещё что-то про ДСЛ упомянули. Это к данной теме o C++ не имеет ВООБЩЕ никакого отношения. И при чём тут ХМЛ вообще?
Ваша предметная область слишком простая, если для её понимания не требуется операционной семантики.
Мне достаточно один контрпример привести с ДСЛ (которого интерпретатор, по всей видимости, даже не на плюсах написан, а на одном из кошерных языков), разработанный конторой с гораздо большим числом разработчиков, которая до сих пор не развалилась.
Здравствуйте, MTD, Вы писали:
V>>А вот ты же рядом. MTD>Ага, я. Можете фан клуб имени меня организовывать.
Включив немного воображения, ты бы догадался, что коллеги имени тебя разве что пепельницу или плевательницу могут организовать.
Т.е. ответить тебе тем же.
У тебя ж ровно один и тот же сценарий:
— толкаем поверхностность
— игнорим дополнения о сути твоего же толкаемого, вместо этого повторяемся с одной и той же поверхностностью
— следом обижаемся на справедливое замечание об игноре аргументов
С такими суровыми защитными реакциями можно потягаться с какой-нить бешеной девочкой в расцвет пубертата. ))
Которой ни то, что слова ни скажи, но даже не вздумай как-то не так посмотреть. Сразу на всю мощь включается примерно такая же беспощадная и бессмысленная защита. ))
Тебя так сильно гнобили в школе, или где?
Здравствуйте, turbocode, Вы писали:
T>Тогда как VCL была очень хорошо структурирована библиотека классов и используя её редко нужно было даже лезть в справку, там действительно был самодокументированный код.
Только из этого VCL изо всех щелей уши паскаля-делфи торчали, на плюсах это было довольно неудобно.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, MTD, Вы писали:
MTD>И в каком стандарте С++ есть спецификация, например, на алгоритмы криптографии?
Чувак, ты бредишь!
Ни в каком стандарте ЯП не должно быть никаких стандартов на криптографию. Потому что это безумие.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
MTD>>И в каком стандарте С++ есть спецификация, например, на алгоритмы криптографии? CC>Чувак, ты бредишь! CC>Ни в каком стандарте ЯП не должно быть никаких стандартов на криптографию. Потому что это безумие.
Я задал риторический вопрос, я нигде не утверждал, что с стандарте ЯП есть/должен быть стандарт на криптоалгоритмы. Отчего ты так возбудился?
Здравствуйте, vdimas, Вы писали:
V>Включив немного воображения, ты бы догадался, что коллеги имени тебя разве что пепельницу или плевательницу могут организовать.
Здравствуйте, vdimas, Вы писали:
MTD>>Только тебе отчего то не смешно — задница дымит любо дорого глядеть
V>Так ты за этим сюда ходишь? V>Это типа каминг аут такой, публичное признание в бессмысленности собственного существования? ))
Из того, что у тебя задымилась задница, не следует что у меня бессмысленное существование. С логикой у тебя совсем туго, хотя это давно понятно по твоим бессмысленным ответам невпопад.
Здравствуйте, MTD, Вы писали:
MTD>Из того, что у тебя задымилась задница
Дефайн "задымилась задница"?
То, что я испытал некоторое чувство досады, от того, что не сразу обнаружил, что общаюсь с троллем — сие факт, но это ж дело житейское.
И чей это в итоге косяк — мой или твой?
MTD>не следует что у меня бессмысленное существование.
Здравствуйте, vdimas, Вы писали:
V>То, что я испытал некоторое чувство досады, от того, что не сразу обнаружил, что общаюсь с троллем — сие факт, но это ж дело житейское.
Я не тролль, просто ты не стал пытаться понять, что я говорю и чисто по ключевым словам возбудился.
MTD>>не следует что у меня бессмысленное существование.
V>Пока что следует именно это.
Прошу, языком логики покажи это. Что снова кучу в штаны наложил? Да, и не в первый раз. Какой ты странный, столько раз уже был пойман на вранье и откровенной глупости и все никак не дойдет, что языком как метлой мести не включая голову глупо.
Здравствуйте, MTD, Вы писали:
V>>То, что я испытал некоторое чувство досады, от того, что не сразу обнаружил, что общаюсь с троллем — сие факт, но это ж дело житейское. MTD>Я не тролль, просто ты не стал пытаться понять, что я говорю и чисто по ключевым словам возбудился.
Ты говорил ерунду и тебе уже многократно на это указывали.
Суть ерунды состоит в поверхностности и грубом обобщении.
"Возбуждается" народ именно на такую грубую поверхностность.
Но это же "возбуждение" сугубо профессионального плана, какие проблемы-то?
Ты-то в ответ чего так возбуждаешься уже за рамками обсуждаемой темы?
Ну и эпитеты навроде "дымящиеся задницы", "наложил в штаны" и прочая атрибутика суровых интернетных ботанов мне никогда не была понятна. Странное вы поколение, как с другой планеты. ))
У русских, оно ж как — только первые два раза, когда человек чихает, ему говорят "будь здоров!", а на третий раз говорят: "да ты з$%бал!". Похоже, ты умудрился вылететь за менталитет общества, в котором живёшь и с которым общаешься, поэтому наглухо не понимаешь ситуацию, когда (и почему) тебе уже не говорят "будь здоров!"
Да и вообще какой-то стрём от тебя идёт. Подобного рода эпитеты, повторюсь, — это ж проявление сурового защитного механизма психики. Для взрослой особи мужского пола то еще палево.
Здравствуйте, MTD, Вы писали:
MTD>>>И в каком стандарте С++ есть спецификация, например, на алгоритмы криптографии? CC>>Чувак, ты бредишь! CC>>Ни в каком стандарте ЯП не должно быть никаких стандартов на криптографию. Потому что это безумие. MTD>Я задал риторический вопрос, я нигде не утверждал, что с стандарте ЯП есть/должен быть стандарт на криптоалгоритмы.
На вопросе не было написано "риторический".
На вопросе было написано "глупый" или "провокационный" в зависимости от системы представлений автора вопроса.
В любом случае, каждый из вариантов плох.
Здравствуйте, MTD, Вы писали:
V>>А откуда ты узнал, что там потоки обиженного? Ты же не читал? )) MTD>Поциент, ваша ранимая натура ни для кого уже не секрет.
Неубедительно.
Т.е. ты прочитал, но за неимением ответа решил состроить независимую мину. Не оригинально.
Здравствуйте, push, Вы писали:
_>>И так первое по теме, что я вижу, это модуль ossaudiodev. Уже смешно, т.к. помнится у меня даже под Линухом была ALSA (а не эта хрень) _>>Больше ничего подходящего не вижу. Я что-то пропустил? Или Питон у нас теперь тоже негодный языка, как и C++? ) Перейдём к другому языку? ))) P>Ну нравится-не нравится, оно есть.
Где есть то? Вот у меня установлен Питон на компьютере (Windows), прямо сейчас. Как мне издать какой-нибудь звук с помощью него, без установки дополнительных библиотек? Кроме варианта типа os.system('start sound.wav') что-то больше ничего не приходит в голову... Но такое и в C++ есть. )))
P>Я не пойму какую мысль ты этим пытаешься дать? Что основные программные примитивы невозможно стандартизовать?
Смотря что называть основными программными примитивами. Работу с аудио, видео, и т.п. я бы вряд ли таким назвал.
P>Серьезно? Ну вот во всех языках получается.
В каких это всех? Вот мы взяли вопрос воспроизведения звука и видим, что в Питоне (один из современных мейнстримовых языков) тоже ничего подобного не наблюдается. Куда смотреть то? )
Здравствуйте, push, Вы писали:
_>>Т.е. ты по сути просто за некую что ли стандартизацию популярных C/C++ библиотек, без переноса их в стандартную библиотеку языка? ) P>Я за стандартизацию основных програмных конструкций. А каким образом это будет выполнено — в виде одной библиотеки или набора — не суть важно. Чтобы я мог закладываться, что они есть в стандартной поставке.
Ну вот стандартная поставка — это как раз сомнительная идея.
P>На данный момент ситуация такая, что в других языках — "вот кирпичи, вот раствор, вот мастерок — строй", а в плюсах — "вот песок, вот глина, вот спички — строй, — а кирпичи? — ну иди на улице поищи, все опытные разработчики находят их на улице".
Поэтому не напрягаясь могут строить разные типы домов, из разных типов кирпичей. )
_>>Сейчас проблем никаких нет, т.к. каждый разработчик (ну или там команда) создаёт свою собственную коллекцию необходимых им библиотек, собранных под нужные им платформы. А вот если собрать все эти возможные варианты со всего мира в единую огромную библиотеку, то мы уже получим проблему, многогигабайтную))) P>В том то и проблема, что каждый на свой лад решает одни и те же типовые задачи (десятки либ в плюсах на каждую типовую задачу, делающие по сути одно и то же) одними и теми же типовыми способами, которые кроме синтаксиса и вкусовщины ничем не отличаются. Это и является показателем, что данный програмный примитив необходим в стандарте.
Под создание собственной коллекции необходимых библиотек я подразумевал их скачивание и сборку, а не написание. )))
Здравствуйте, MTD, Вы писали:
MTD>Ого, сколько жжение в заду заставило накатать. Читать эти потоки бреда обиженного я конечно не буду
Артёмка, отдай MTD его аккаунт
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, so5team, Вы писали:
S>Ну тогда перечитайте, а то есть ощущение, что вы чего-то не поняли. Не мог Страуструп в "Дизайне и эволюции" писать одно, а в "Язык программирования C++" -- другое.
Взял книгу, открыл, читаю. Вижу:
— предисловие автора в к третьему русскому изданию — "Целью этих усилий было описать язык и библиотеку, которые будут исправно служить всем пользователям языка, не предоставляя каких-либо преимуществ одной группе пользователей, компании или стране перед остальными."
— предисловие ко второму изданию — "Как было предсказано в первом издании этой книги, C++ эволюционировал в соответствии с запросами его пользователей. Эта эволюция направлялась запросами пользователей самой разной квалификации, работающих в разных предметных областях. "
— там же — "Главной целью развития и расширения языка за эти шесть лет было стремление сделать C++ языком абстракции данных и языком объектно-ориентированного программирования в целом"
— там же — "C++ является языком общего назначения; его естественной сферой применения является системное программирование в самом общем смысле этого термина. Тем не менее, C++ с успехом используется и в других предметных областях."
И ничего, что это язык "для скорости" и вообще что это какой-то "нишевый" язык.
Так что это как раз вы суть С++ и не поняли. Теперь ваша очередь взять и перечитать.
P>>оО Это я противопоставляю? Вообще-то это вы противопоставили. Я пытаюсь донести, что это не верно. S>Конечно вы...
Нет вы. Перечитайте тему. Это ваши слова, что С++ это нишевый язык с очень узкой нишей. Я показываю, что вы неправы, предоставляя логические выводы, показывая кучу исключений, давая цитаты автора языка.
S>Простите, вы это сейчас серьезно?
Что вас смущает? Принципиальная возможность использовать GC в плюсах? Наличие различных реализаций GC для плюсов? Существование книг с подробной теорией и реализацией GC на плюсах?
S>Вы знаете, что в некоторых прикладных нишах использование STL (т.е. стандартной библиотеки C++) находится под запретом (либо целиком, либо частично)?
Более того, работал под embeded. Но что вы хотели сказать данной фразой? Что создание STL — это катастрофическая ошибка?
P>>Как это исправить? Ну для начала хотя бы перенять опыт других языков. S>Каких?
Мы ходим по кругу, перечитайте тему.
Здравствуйте, vdimas, Вы писали:
V>У остальных уже есть абстракция ostream и фреймворк фильтрации сверху в бусте.
Ну то есть ничего нет. Всё надо писать.
V>Всё прибито гвоздями друг к другу на основе 3-4-х основных интерфейсов. Такие либы сделаны по принципу аналогичных либ из джавы и дотнета и выглядят, мягко говоря, идиотизмом. Ну и эффективность соответствующая.
Ну под 90% задач абсолютно подходят — значит идеальные кандидаты на включении в стандартную поставку.
V>Велосипедить можно по-разному...
Главный вопрос: и что? Как наличие стадартных средств может помешать тому, кто всеми силами хочет велосипедить? Вообще не вижу проблемы.
V>А в языках с хорошей выразительностью велосипедостроительство — это основной вид деятельности.
Для хобби — это так. Но бизнесс с тобой не согласен. Потому и слили плюсы большинство своих областей применения.
V>Т.е. не обязательно выпускать готовые велосипеды, бо всем ты не угодишь.
оно и не нужно
V>Да чего уж там. Ты не угодишь даже половине. ))
да ладно, как минимум 90% будет довольно
V>Но можно выпускать отдельно номенклатуру колёс, отдельно цепей, рам и т.д.
это очень заманчивая мысль, но в данный момент это не сделать просто физически, должен быть хоть какой-то фундамент. Пока же ни колёс, ни цепей, ни рам. Всё, что есть — набор сторонних велосипедов.
V>Именно поэтому развитый базис, позволяющий комбинировать готовые "кирпичики", намного ценнее некоторого конкретного решения, которое практически невозможно на эти кирпичики разобрать.
Браво! Вот только где они, кирпичики? То, что предлагаются стандартом — кот наплакал.
V>Тенденции рынка чистой заказухи все последние 15 лет хреновые
Из того, что я вижу по заказам — это как раз рынок коробочных решений почти умер. А вот заказы от бизнеса всё ещё набирают обороты. Куча компаний только на этом поле и пасётся, не выпуская вообще никаких своих коробочных продуктов.
Здравствуйте, vdimas, Вы писали:
V>Т.е. твой моск, смотрю, пока еще изо всех сил борется с тем фактом, что огромный пласт задач (даже сугубо прикладных) сегодня на С++ решается заметно быстрее и проще, чем даже на C# 7.0.
Я был бы очень рад, если бы это видел на самом деле. Пока что дело обстоит так, что плюсы присутствуют только в узкой нише embeded и ресурсо-критичных задач.
Всё остальное делается заметно геморнее и дольше, чем на остальных языках. Видимо это тщательно скрывается от общественности.
Здравствуйте, vdimas, Вы писали:
V>Разве модули работы со звуком идут как стандарт языка? Или это всё-таки некие либы сверху?
Это идёт либо в стандартных средствах: либо в библиотеке, либо в поставляемом окружении.
Для плюсов — любой из этих вариантов сделал бы счастливыми невероятное количество людей.
Здравствуйте, alex_public, Вы писали:
_>Смотря что называть основными программными примитивами. Работу с аудио, видео, и т.п. я бы вряд ли таким назвал.
А что требуется для большинства задач? Проиграть аудио/видео, замедлить/ускорить/остановить. Это покроет большинство потребностей. Это не реализуемо в принципе на С++? Это невероятно сложно сделать?
Здравствуйте, alex_public, Вы писали:
_>Ну вот стандартная поставка — это как раз сомнительная идея.
Чем? Пока что аргументов, кроме "оно не сможет решить мою узкоспециализированную задачу" и "это очень плохо", я больше не видел.
_>Поэтому не напрягаясь могут строить разные типы домов, из разных типов кирпичей.)
Так а где ж кирпичи-то? Они не предусмотрены производителем.
Здравствуйте, push, Вы писали:
P>Здравствуйте, so5team, Вы писали:
S>>Ну тогда перечитайте, а то есть ощущение, что вы чего-то не поняли. Не мог Страуструп в "Дизайне и эволюции" писать одно, а в "Язык программирования C++" -- другое.
P>Взял книгу, открыл, читаю. Вижу:
Очевидно, не видите. И даже понятно почему.
P>И ничего, что это язык "для скорости" и вообще что это какой-то "нишевый" язык. P>Так что это как раз вы суть С++ и не поняли. Теперь ваша очередь взять и перечитать.
Да уж. Ну держите, из "Дизайн и эволюция языка C++":
Для истории C++ важную роль сыграло составленное мной представление о "подходящем" инструменте для проектов такого масштаба, как большой симулятор, операционная система и аналогичные задачи системного программирования. Вот эти критерии:
* хороший инструмент должен предоставлять средства организации программ, подобные имеющимся в Simula: классы, форму их иерархии, поддержку параллельности и сильный (т.е. статический) контроль типов, основанный на классах. Эти критерии представлялись мне тогда (да и теперь) существенными для поддержки процесса проектирования, а не для реализации программы;
* необходимо, чтобы он генерировал программы, работающие так же быстро, как написанные на BCPL, и обладал способностью BCPL объединять раздельно скомпилированные модули в единую программу. Должно быть простое соглашение о связях, чтобы удалось объединять модули, написанные на разных языках, таких как C, Algol68, Fortran, BCPL, ассемблер и т.д. Иначе программист будет вынужден бороться с ограничениями, присущими какому-то одному языку;
* инструмент должен обеспечивать переносимую реализацию. Мой опыт показал, что "правильная" реализация, остро необходимая мне сейчас, будет готова "не раньше следующего года", да и то на компьютере, которого у меня нет. Отсюда следует, что должно быть несколько источников реализации инструмента (никакой монополист не сможет поддерживать всех пользователей "редких" машин, а так же бедных студентов). Не должно быть так же сложной системы поддержки времени исполнения, которую трудно переносить, и допустима лишь очень ограниченная зависимость инструмента от операционной системы.
Обратите пристальное внимание на второй принцип, и ту часть третьего принципа, которая касается отсутствия сложной системы поддержки времени исполнения (отдельный привет безопасным языкам на базе JVM и .NET). Не говоря уже про явно обозначенную нишу языка (и если вы не верите, что "операционные системы" -- это ниша, для которой критична скорость и ресурсопотребление, то вам нужно a) лечиться и b) идти учиться).
Ну и еще оттуда же, про важность скорости генерируемого кода:
...Я считал принципиальным такой аспект: улучшение структуры не может достигаться за счет падения производительности по сравнению с С. Язык C with Classes не должен был уступать C во времени исполнения, компактности кода и данных. Однажды кто-то продемонстрировал систематическое трехпроцентное падение производительности новой версии по сравнению с С, вызванное наличием временных переменных, которые препроцессор C with Classes использовал в механизме возврата из функций. Недочет был признан неприемлемым и причину быстро устранили...
Другой важной целью работы было стремление избежать ограничений на области использования C with Classes. Идеал (кстати, достигнутый) — C with Classes может применяться везде, где использовался C. Отсюда следовало, что новая версия ни в коем случае не должна была уступать C в эффективности, но эта эффективность не могла достигаться за счет отказа от некоторых, пусть даже уродливых особенностей C. Это соображение (если хотите, принцип) приходилось снова и снова повторять тем людям (как правило, не работавшим постоянно с C with Classes), которые хотели сделать версию безопаснее, введя статический контроль типов а-ля Pascal. Альтернативу такой "безопасности" — вставку проверок в исполняемый код — решили реализовать в отладочных средах. В самом языке нельзя было организовать таких проверок, ибо тогда он безнадежно проиграл бы по скорости и расходу памяти...
И, кстати, говоря, ничего из этого не противоречит вашим цитатам, в частности:
— предисловие автора в к третьему русскому изданию — "Целью этих усилий было описать язык и библиотеку, которые будут исправно служить всем пользователям языка, не предоставляя каких-либо преимуществ одной группе пользователей, компании или стране перед остальными."
Что неудивительно, т.к. речь идет о совершенно разных вещах, а именно: язык C++ предназначен для задач, в которых важна скорость и ресурсоемкость, поэтому он не должен отставать от C в производительности. Но для тех пользователей, которым нужен C++, не должно быть ограничений по применению языка.
При этом, из-за первоначальной направленности C++ на задачи вида "большой симулятор, операционная система и аналогичные задачи системного программирования", очевидно, что C++ нужен далеко не всем. О чем вам вот так вот прямо и было сказано:
Вы не понимаете. С++ изначально создавался только под те ниши, для которых скорость и ресурсопотребление критичны. Но из-за того, что в промежутке между 1985-1995 мощность компьютеров была вообще никакая, скорость и ресурсоемкость была критична практически везде. Потому-то C++ и пихали куда не попадя. Но потом RAM и CPU стало хватать даже для софта, написанного на Ruby, так что надобность в C++ постепенно пришла в норму и C++ просто-напросто вернулся туда, где и должен был быть изначально.
P>Нет вы. Перечитайте тему. Это ваши слова, что С++ это нишевый язык с очень узкой нишей. Я показываю, что вы неправы, предоставляя логические выводы, показывая кучу исключений, давая цитаты автора языка.
Во-первых, вы ничего не показываете, кроме своих заблуждений. Во-вторых, вот ваши слова:
Если бы он создавался для скорости — то как минимум по умолчанию копирования небыло, не было бы и виртуальных функций, исключений, RTTI.
С++ позиционировался как язык общего назначения. Повторюсь, Старутруп сам пишет об этом в предисловии.
в которых вы сами отказываете языку программирования в том, что язык может быть быстрым и при этом оставаться универсальным языком программирования.
S>>Простите, вы это сейчас серьезно?
P>Что вас смущает?
Ваша способность вести осмысленный диалог, в частности.
P>Принципиальная возможность использовать GC в плюсах? Наличие различных реализаций GC для плюсов? Существование книг с подробной теорией и реализацией GC на плюсах?
Применимость всего этого в широкой практике. А не в отдельных, в основном, исследовательских, задачах.
S>>Вы знаете, что в некоторых прикладных нишах использование STL (т.е. стандартной библиотеки C++) находится под запретом (либо целиком, либо частично)?
P>Более того, работал под embeded. Но что вы хотели сказать данной фразой? Что создание STL — это катастрофическая ошибка?
То, что вы противоречите сами себе. Ибо:
Киллер-фича — это как раз стандартные библиотеки и инфраструктура.
уже не работает для ниш, в которых стандартная библиотека языка не применяется. И это не дает вам возможности:
быстро и легко набросать приложение из "стандартных кирпичиков"
P>>>Как это исправить? Ну для начала хотя бы перенять опыт других языков. S>>Каких? P>Мы ходим по кругу, перечитайте тему.
Если вы про вот этот феерический пассаж:
Есть у всех в кого не плюнь: Delphi, C#, Python, Java и т.д. В D вообще есть стандартный пакетный менеджер — считай там всё стандартное.
то простите, по этому поводу все сказано. И если вы подразумеваете, что C++ должен подражать в плане библиотек C#, Python, Java и D, то разговаривать с вами просто не о чем.
Здравствуйте, push, Вы писали:
V>>Разве модули работы со звуком идут как стандарт языка? Или это всё-таки некие либы сверху? P>Это идёт либо в стандартных средствах: либо в библиотеке, либо в поставляемом окружении. P>Для плюсов — любой из этих вариантов сделал бы счастливыми невероятное количество людей.
Для плюсов так и есть.
Как грится, откройте уже документацию.
Здравствуйте, push, Вы писали:
V>>Т.е. твой моск, смотрю, пока еще изо всех сил борется с тем фактом, что огромный пласт задач (даже сугубо прикладных) сегодня на С++ решается заметно быстрее и проще, чем даже на C# 7.0. P>Я был бы очень рад, если бы это видел на самом деле. Пока что дело обстоит так, что плюсы присутствуют только в узкой нише embeded и ресурсо-критичных задач.
Плюсы присутствуют вообще везде.
99.9% программ, которыми ты регулярно пользуешься — они на плюсах писаны.
И в последние годы скорость написания таких программ резко возросла.
P>Всё остальное делается заметно геморнее и дольше, чем на остальных языках. Видимо это тщательно скрывается от общественности.
Похоже, ты пытаешься выставить всё в таком свете, что вообще все программы, которыми ты пользуешься — они просто даны сверху, а не разработаны живыми людьми. ))
Здравствуйте, push, Вы писали:
V>>У остальных уже есть абстракция ostream и фреймворк фильтрации сверху в бусте. P>Ну то есть ничего нет. Всё надо писать.
Или взять любую готовую.
log4j тоже не идёт в поставке Джавы, но является самой используемой либой для логирования на этой платформе.
Я проблемы не вижу, кароч.
V>>Всё прибито гвоздями друг к другу на основе 3-4-х основных интерфейсов. Такие либы сделаны по принципу аналогичных либ из джавы и дотнета и выглядят, мягко говоря, идиотизмом. Ну и эффективность соответствующая. P>Ну под 90% задач абсолютно подходят — значит идеальные кандидаты на включении в стандартную поставку.
По указанным мною причинам — не идеальны.
А значит, достойны лишь существовать в виде сторонних библиотек.
Например, Boost.Log пока не готов для включения в стандарт.
Тем не менее, готов для использования нетребовательными разработчиками, вроде тебя.
Опять проблемы не вижу.
V>>Велосипедить можно по-разному... P>Главный вопрос: и что? Как наличие стадартных средств может помешать тому, кто всеми силами хочет велосипедить? Вообще не вижу проблемы.
Ты не ответил на главный вопрос — зачем?
Ты в любом случае будешь пользоваться бустом, если пишешь под С++.
Другого сценария сегодня нет.
V>>А в языках с хорошей выразительностью велосипедостроительство — это основной вид деятельности. P>Для хобби — это так. Но бизнесс с тобой не согласен.
Бизнес со мной согласен и поэтому пилит коробочное ПО на плюсах.
P>Потому и слили плюсы большинство своих областей применения.
Угу. Слили везде, кроме веба. На котором их и не было никогда. ))
В общем. В реальности ситуация обстоит наоборот. С++ потеснил в клиентской разработке огромный зоопарк технологий, который наблюдался еще в первой половине 90-х. Во второй половине 90-х и в начале 2000-х на клиенте пытались выстрелить джава и дотнет, но так и не выстрелили.
Сегодня С++ является де-факто монополистом на клиенте. Все остальные сдулись.
На серверных технологиях на связке С/С++ писана ВООБЩЕ ВСЯ инфраструктура, и только самый-самый высокоуровневый клей — это PHP/Java/.Net.
Поэтому, все утверждения о том, что плюсы слили — смешны.
Ты запускаешь наглухо плюсовую Ось, пишешь из плюсового браузера, случаешь музычку или смотришь видео через плюсовый плеер, играешь в игрухи, которые 100%-но писаны на плюсовых движках и т.д. до бесконечности. Других технологий для столь же ПОПУЛЯРНЫХ и МАССОВЫХ программ де-факто нет. Ну или напомни, а то я давно о таких не слышал. ))
V>>Т.е. не обязательно выпускать готовые велосипеды, бо всем ты не угодишь. P>оно и не нужно
Верно. Не нужно. Стандарт языка — это стандарт языка. А библиотека — это библиотека.
V>>Да чего уж там. Ты не угодишь даже половине. P>да ладно, как минимум 90% будет довольно
Будет меньше половины.
Иначе альтернативные логгеры давно бы умерли, ведь есть бустовский.
Просто пример. Реализация shared_ptr в Бусте хороша, поэтому альтернативные реализации умерли, а эта пошла в стандарт.
С библиотекой логгирования этого пока не произошло и это слишком очевидный индикатор. Игнорировать такой индикатор — напрашиваться на остракизм.
V>>Но можно выпускать отдельно номенклатуру колёс, отдельно цепей, рам и т.д. P>это очень заманчивая мысль, но в данный момент это не сделать просто физически
Именно так реализован логгер в Бусте, если что.
Поэтому, народ часто делает СВОЙ логгер из запчастей бустовского.
P>должен быть хоть какой-то фундамент.
Нахрена заводу по производству оконных рам знать, какой будет фундамент в будущем доме?
Это задача инженера конкретного проекта — произвести расчёты и подобрать соотв. технологию реализации фундамента.
P>Пока же ни колёс, ни цепей, ни рам. Всё, что есть — набор сторонних велосипедов.
Ложь.
V>>Именно поэтому развитый базис, позволяющий комбинировать готовые "кирпичики", намного ценнее некоторого конкретного решения, которое практически невозможно на эти кирпичики разобрать. P>Браво! Вот только где они, кирпичики? То, что предлагаются стандартом — кот наплакал.
Похоже, я начинаю догадываться, что происходит.
Ты забыл значение слова "стандарт". ))
Стандарт — это как ГОСТ.
Он определяет самые общие правила.
Но он не диктует, каким должен быть твой дом и уж тем более не даёт тебе готовых элементов дома.
Он лишь определяет некие нормы и правила.
А ты хочешь от "стандарта" странного.
V>>Тенденции рынка чистой заказухи все последние 15 лет хреновые P>Из того, что я вижу по заказам — это как раз рынок коробочных решений почти умер.
Статистику тебе дали — ты её игноришь по принципу "ничего не хочу знать".
P>А вот заказы от бизнеса всё ещё набирают обороты.
Согласно сухой статистике — падают год от года.
P>Куча компаний только на этом поле и пасётся, не выпуская вообще никаких своих коробочных продуктов.
И эта куча довольно быстро сжимается в последние годы.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, push, Вы писали:
P>>Потому и слили плюсы большинство своих областей применения.
V>Угу. Слили везде, кроме веба. На котором их и не было никогда. ))
Если у тебя такая четкая позиция, то обьясни(не в конектсте спора), почему серверный софт повсеместно пишется на Java или .NET. Только из-за сборки мусора?
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>Если у тебя такая четкая позиция, то обьясни(не в конектсте спора), почему серверный софт повсеместно пишется на Java или .NET. Только из-за сборки мусора?
Из-за плохо сформулированных или постоянно изменяющихся требований.
На этих средах удобно трансформировать программы, а такая трансформация является важной частью жизни подобных систем.
1С аналогично, кстате.
Но "движок" всех перечисленных систем тоже нейтивный.
Дотнет и 1С писаны на плюсах, джава на С (по историческим причинам, скорее, бо её пилят с 91-го года).
Здравствуйте, push, Вы писали:
P>А что требуется для большинства задач? Проиграть аудио/видео, замедлить/ускорить/остановить. Это покроет большинство потребностей. Это не реализуемо в принципе на С++?
Это ты действительно спрашиваешь, когда 99% подобных программ писаны на плюсах?
P>Это невероятно сложно сделать?
Раз на других языках такое не пишут, значит сложно.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, lpd, Вы писали:
lpd>>Если у тебя такая четкая позиция, то обьясни(не в конектсте спора), почему серверный софт повсеместно пишется на Java или .NET. Только из-за сборки мусора?
V>Из-за плохо сформулированных или постоянно изменяющихся требований. V>На этих средах удобно трансформировать программы, а такая трансформация является важной частью жизни подобных систем.
Когда я здесь ранее задавал этот вопрос, мне ответили про систему сборки и инфраструктуру(+сборку мусора). Не уверен, что это был точный ответ.
Однако, что ты подразумеваешь под трансформацией программы? Системы сборки или reflection?
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, push, Вы писали:
_>>Ну вот стандартная поставка — это как раз сомнительная идея. P>Чем? Пока что аргументов, кроме "оно не сможет решить мою узкоспециализированную задачу" и "это очень плохо", я больше не видел.
От тебя вообще никаких аргументов, кроме дайте мне кнопку "сделай мне заехорошо".
Или в литературном варианте "горшочек вари".
Во-первых, кто именно должен предоставить тебе такую функциональность.
Во-вторых, а зачем тогда нужен ты в этой схеме?
P>Так а где ж кирпичи-то? Они не предусмотрены производителем.
Производителем цемента?
Ты когда цемент покупаешь при строительстве дома, ругаешься с водителем миксера, что он тебе кирпичей к цементу не подвёз? ))
Здравствуйте, lpd, Вы писали:
lpd>Когда я здесь ранее задавал этот вопрос, мне ответили про систему сборки и инфраструктуру(+сборку мусора). Не уверен, что это был точный ответ. lpd>Однако, что ты подразумеваешь под трансформацией программы?
Постоянное изменение кода на всех уровнях, от общей архитектуры до конкретных бизнес-алгоритмов.
lpd>Системы сборки или reflection?
Если ты про сборку мусора — то да, она хороша при постоянной трансформации архитектуры, т.к. не надо фиксировать, кто кем владеет.
Reflection тоже позволяет автоматизировать часть ручных задач, требуемых ПОСЛЕ трансформации. Т.е., даже если Reflection автоматизирует ту часть трудоёмкости, которая при однократной реализации кажется смехотворной, в случае постоянного изменения кода этот инструмент уже начинает выглядеть натуральной киллер-фичей.
Хотя, тому же C# не хватает развитых ср-в compile-time рефлексии, в итоге ошибки в коде вокруг рефлексии надо отлавливать уже в runtime. (в последних стандартах чуть-чуть зашевелились в этом направлении)
Не зря в плюсах уже который год разрабатывают нечто аналогичное. Но т.к. там вся мощь рефлексии может быть доступна лишь на этапе компиляции, то получается аналог Nemerle. ))
Здравствуйте, push, Вы писали:
_>>Смотря что называть основными программными примитивами. Работу с аудио, видео, и т.п. я бы вряд ли таким назвал. P>А что требуется для большинства задач? Проиграть аудио/видео, замедлить/ускорить/остановить. Это покроет большинство потребностей. Это не реализуемо в принципе на С++? Это невероятно сложно сделать?
Вообще то это мягко говоря сложно, хотя бы потому что есть сотни разных нюансов реализации. Начнём с того, что указанный тобой процесс в реальности делится 3 отдельных процесса, для каждого из которых частенько используют отдельные библиотеки. А именно:
1. Парсинг форматов медиа-файлов. С одной стороны это задача достаточно тривиальная и однозначная, а с другой этих форматов такое огромное количество, что совершенно непонятно какие же всё же включать в стандарт. Тем более, что многие из них разрабатываются как отдельные библиотеки.
2. Декодирование сжатых потоов. Тут естественно тоже имеется огромное число кодеков, но это ещё цветочки, т.к. у каждого из них есть множество разных реализации: тупая, на ассемблере с simd, с ускорением на GPU, с ускорением на аппаратном декодере (типа Intel Quick Sync) и т.п. Причём естественно ещё не известно какое оборудование есть на компьютере пользователя.
3. Вывод декодированного потока на экран/колонки. Тут у нас имеется не меньший зоопарк API. Например если мы возьмём вопрос рендеринга видео под Винду, то как минимум сразу же автоматом идут DirextX, OpenGL, DirectShow, да и даже банальный GDI (не эффективный, но работающий везде). Но и это ещё не всё, перечисленные подходы тоже разделяются, т.к. в первых двух можно использовать различные шейдеры, а в DirectShow разные рендеры (VMR7, VMR9, EVR и т.д.).
И ты вот реально хочешь засунуть весь этот стек сложных технологий в стандартную библиотеку C++ с API вида playfile? )))
Вообще конечно существуют попытки объединить всё вышеперечисленное в одну библиотеку: это ffmpeg и её форк libav. Они написаны на C, так что являются родными для C++ и частенько используются теми, кому не требуется особая эффективность. И кстати при этом эти библиотеки используются в огромном количестве других языков и платформ, как реальный исполнитель задач. Но даже на этом страшненьком и не самом эффективном монстре банальное проигрывание файла займёт не одну строчку кода.
Здравствуйте, push, Вы писали:
_>>Поэтому не напрягаясь могут строить разные типы домов, из разных типов кирпичей.) P>Так а где ж кирпичи-то? Они не предусмотрены производителем.
А кого интересно ты считаешь производителем в мире C++? )))
Здравствуйте, so5team, Вы писали:
S>Обратите внимание на кавычки вокруг "малолетний дебил" и знак копирайта. Это устойчивое выражение господина Дмитрия "Гоблина" Пучкова...
Извините, но это уже какое-то запредельное лицемерие.
Здравствуйте, vdimas, Вы писали:
V>От тебя вообще никаких аргументов, кроме дайте мне кнопку "сделай мне заехорошо". V>Или в литературном варианте "горшочек вари".
Это называется прогресс. В идеале проблема должна уже быть решена. Если проблема не решена, софт должен определить наличие проблемы и решить её. Если это невозможно — должна быть кнопочка "решить проблему" которую я нажму при проблеме. Если это невозможно — должна быть библиотека, с помощью которой я могу создать такую кнопочку. Если её нет — должные быть средства для создания такой библиотеки.
Вот пока что ничего кроме иррационального страха существования такой библиотеки я не увидел.
V>Во-вторых, а зачем тогда нужен ты в этой схеме?
Я буду создавать "магические кнопочки". Чем высокоуровнневее задача — тем интереснее. Обязанность копаться на самом низком уровне, среди мульярда сторонних либ удручает, особенно знаешь как может быть удобно на самом деле.
Здравствуйте, alex_public, Вы писали:
_>И ты вот реально хочешь засунуть весь этот стек сложных технологий в стандартную библиотеку C++ с API вида playfile? )))
Да, вся кастомизация кастомизации не нужна — выбрать самый простой вариант (один), остальное оставить на откуп сторонним либам. Мы либо можем воспроизвести звук либо нет. В будущем можно развивать, если этого не будет хватать.
Я не изучал вопрос детально, но разве нет в ОС какого-либо API для вот такого простого случая? Должен быть. Вот заюзать его.
Здравствуйте, so5team, Вы писали:
S>... Да уж. Ну держите, из "Дизайн и эволюция языка C++"... S>...Не говоря уже про явно обозначенную нишу языка (и если вы не верите, что "операционные системы" -- это ниша, для которой критична скорость и ресурсопотребление, то вам нужно a) лечиться и b) идти учиться)... S> и т.д. и т.п.
Перечитайте ещё раз о предмете разговора и о ходе ваших мыслей. На моё сообщение, что С++ профукал большинство из областей применения был ваш детский ответ из разряда "а нам оно и не надо было", аргументировав что С++ — это нишевый язык. Я показал, что это совершенно не так, он то как раз язык общего назначения. В ответ вы скатились в демагогию, а мне это не интересно. Есть аргументы по существу — я слушаю, нет — лучше вам изучить С++ более детально. И ещё хоть какой-нибудь нишевый язык, да хоть Erlang к примеру, чтобы понимать отличия языка общего назначения от нишевого.
P>>Принципиальная возможность использовать GC в плюсах? Наличие различных реализаций GC для плюсов? Существование книг с подробной теорией и реализацией GC на плюсах? S>Применимость всего этого в широкой практике. А не в отдельных, в основном, исследовательских, задачах.
Да нормальная применимость, попробуйте сами. Если вы о том, что GC в плюсах не обрёл огромной применимости — то это как раз подтверждает мои слова что GC абсолютно не киллер-фича и опровергает ваши.
S>уже не работает для ниш, в которых стандартная библиотека языка не применяется. И это не дает вам возможности: S>
быстро и легко набросать приложение из "стандартных кирпичиков"
Я опять спрашиваю — вы к чему ведёте, что создание STL — это была ошибка?
Как раз ваши слова ещё раз подтверждают, что стандартные средства С++ очень скудны. Они не покрывают очень критический к ресурсам embeded. Более того туда, куда не пролазит STL как правило не пролазит и С++. Там только С, а плюсов ничтожно мало, ибо когда всё нужно писать для такой платформы с нуля — то обычная сишка из-за простоты рвёт плюсы. А вот если дополнить стандартную инфраструктуру плюсов либой для критических систем — то опять всё получается просто и удобно. Опять можно собирать приложение из "стандартных кирпичиков".
S>Если вы про вот этот феерический пассаж: S>
Есть у всех в кого не плюнь: Delphi, C#, Python, Java и т.д. В D вообще есть стандартный пакетный менеджер — считай там всё стандартное.
S>то простите, по этому поводу все сказано. И если вы подразумеваете, что C++ должен подражать в плане библиотек C#, Python, Java и D, то разговаривать с вами просто не о чем.
Хахаха)) Вот он, плюсовый снобизм)) Видимо вы кроме плюсов не работали с другими языками.
Я подразумеваю, что С++ надо развивать как в плане языка, так и особенно в плане инфраструктуры. И если ментейнеры настолько немощи, что не способны это сделать (а как видно не способны) — то пусть хотя бы перенимают опыт других языков.
Так вам понятно? Или опять будем уходить в демагогию, что "у языка XXX есть минус — ты хочешь перенести этот минус в С++"?
Здравствуйте, vdimas, Вы писали:
V>Или взять любую готовую. V>Я проблемы не вижу, кароч.
Тоесть любая подойдёт. Вот, включить в стандарт и не париться.
V>По указанным мною причинам — не идеальны. V>А значит, достойны лишь существовать в виде сторонних библиотек.
Все либы не идеальны. По указанному тобой критерию даже STL не должна существовать в стандарте.
Но текущее положение дел таково, что чем больше новых либ включают с STL — тем более разработчики довольны.
V>Ты не ответил на главный вопрос — зачем?
Для удобства. Зачем о чём-то париться, если можно вообще не забивать себе этим мозги.
V>Поэтому, все утверждения о том, что плюсы слили — смешны. V>Ты запускаешь наглухо плюсовую Ось, пишешь из плюсового браузера, случаешь музычку или смотришь видео через плюсовый плеер, играешь в игрухи, которые 100%-но писаны на плюсовых движках и т.д. до бесконечности.
Вообще-то не до бесконечности — это всё единичный софт (а в игрухах денег не заработаешь).
Я сейчас даже не могу ни одного аргумента найти, чтобы человек начал пользовать плюсы в текущем виде.
Драйвера/реверсинг/системные хаки/переписываение с Java/C# — всё это требует большого опыта и специфических навыков.
Можно конечно попробовать в embeded — но вакансий там кот наплакал.
Всё остальное на плюсах не заказывают по озвученным мною причинам.
Но если ты считаешь, что
V>Бизнес со мной согласен и поэтому пилит коробочное ПО на плюсах. V>В общем. В реальности ситуация обстоит наоборот. С++ потеснил в клиентской разработке огромный зоопарк технологий, который ... V>Сегодня С++ является де-факто монополистом на клиенте. Все остальные сдулись. V>На серверных технологиях на связке С/С++ писана ВООБЩЕ ВСЯ инфраструктура, и только самый-самый высокоуровневый клей — это PHP/Java/.Net.
то мне сказать нечего — как только попаду в твою реальность, продолжим.
В текущей реальности плюсовиков требуется меньше чем разработчиков на любом другом языке.
V>Верно. Не нужно. Стандарт языка — это стандарт языка. А библиотека — это библиотека.
Мне не понятен твой страх перед стандартом.
V>Будет меньше половины. V>Иначе альтернативные логгеры давно бы умерли, ведь есть бустовский.
Как раз бустовский никто и не юзает)))
V>Просто пример. Реализация shared_ptr в Бусте хороша, поэтому альтернативные реализации умерли, а эта пошла в стандарт. V>С библиотекой логгирования этого пока не произошло и это слишком очевидный индикатор.
Не-а, не хороша, а потому что самая простая без мульёна стратегий, как того хотелось адептам метапрограммирования. А лог не вошёл потому, что развития небыло.
V>Именно так реализован логгер в Бусте, если что. V>Поэтому, народ часто делает СВОЙ логгер из запчастей бустовского.
Хахаха) бустовский логер вообще никто не юзает. Я ради прикола в двух компаниях показывал как его юзать. Но кроме "вау, скинь файлы на Confluence" больше никаких телодвижений небыло. И все продолжали юзать каждый свой логгер. Ибо бустовская реализация такой простой задачи, когда это поделие ещё надо и допиливать (ну извини, "собирать") — это полная хрень.
V>Это задача инженера конкретного проекта — произвести расчёты и подобрать соотв. технологию реализации фундамента.
И делать это каждый раз при типовом проекте? Зачем?
P>>Пока же ни колёс, ни цепей, ни рам. Всё, что есть — набор сторонних велосипедов. V>Ложь.
Да нет, как раз правда, открой стандарт и посмотри, что там предлагают использовать.
V>Ты забыл значение слова "стандарт". )) V>Он определяет самые общие правила. V>Он лишь определяет некие нормы и правила.
Нет, он определяет чем ты можешь пользоваться для конкретного результата.
V>А ты хочешь от "стандарта" странного.
Да нет, хочу стандартный вещей. Вариант — ищи сторонние либы или пиши сам — он не серьезен уже в наше время, всё это осталось в 90х. В современном мире софт собирается из кирпичиков, и лишь критически важные места могут писаться отдельно. И кто не может собрать за приемлемое время и бюджет — уходит с рынка, как С++ в любой из областей где у него есть конкурент.
Здравствуйте, vdimas, Вы писали:
V>Плюсы присутствуют вообще везде. V>99.9% программ, которыми ты регулярно пользуешься — они на плюсах писаны. V>И в последние годы скорость написания таких программ резко возросла.
Это всё какой-то детский аргумент.
Ты имеешь ввиду ОС, браузер, базу данных и т.п.? Это всё единичный софт.
От того, что ими пользуются все — потребность в с++ на рынке не возникает.
Здравствуйте, vdimas, Вы писали:
V>Для плюсов так и есть. V>Как грится, откройте уже документацию.
Ну что за детский сад?
Открывают стандарт, ищу что же мне использовать для одной из самых распространённых возможностей, к примеру, чтобы передать данные через сеть.
И где? Нету.
И что взамен? Ну — вы же можете использовать API и сторонние либы?
Серьезно? В 2017 году?
Здравствуйте, push, Вы писали:
P>В идеале проблема должна уже быть решена.
Тогда ты не нужен, как программист.
P>должна быть библиотека, с помощью которой я могу создать такую кнопочку.
Это есть. (1)
P>Если её нет — должные быть средства для создания такой библиотеки.
И это тоже. (2)
P>Вот пока что ничего кроме иррационального страха существования такой библиотеки я не увидел.
Пока что ты демонстрировал иррациональный страх каждый раз, когда нужно было что-то попрограммировать самому.
Просто ты так странно рассуждаешь, будто разработчики стандартной библиотеки — это какие-то не люди, а боги, которым выполнить действия (1) и (2) раз плюнуть, а для тебя они являются неподъемными.
V>>Во-вторых, а зачем тогда нужен ты в этой схеме? P>Я буду создавать "магические кнопочки".
Не будешь бо не нужен.
Их будет создавать прикладной специалист, далёкий от программирования.
P>Чем высокоуровнневее задача — тем интереснее.
Чем высокоуровнневее задача, тем больше надо быть спецом в предметной области, а ты в ней не разбираешься — тебе же разбираться в тонкостях неохота. Это же общая такая черта характера, конкретно программирование тут не при чём. Просто в даном случае ты стремишься занять паразитическую нишу именно через программирование, то бишь ни хрена не делать но получать большую ЗП. А я тебе показываю, чем это заканчивается — тем, что более умные люди пишут что-то типа 1C, которую конфигурят уже профессиональные бухгалтера по большей части. А паразит-дельфист, пишущий свои программы исключительно из готовых компонент, в этой схеме исчезает. Он или становится настоящим программистом, или переходит в одинэсники и становится настоящим бухгалтером.
Ведь это сейчас ты можешь отмазаться, мол, дайте мне подробное ТЗ, мол, мне как программисту и так работы хватает. А в твоей гипотетической ситуации "написанности всего" ситуация будет резко иная.
И мы на всех парах движемся к такой ситуации.
Именно поэтому рынок заказухи с каждым годом сужается, а потребность в программистах, способных решать проблемы с 0-ля (именно способных, бо ты не способен без горшочка по собственым же словам) растёт.
P>Обязанность копаться на самом низком уровне, среди мульярда сторонних либ удручает, особенно знаешь как может быть удобно на самом деле.
Мде... Обсуждаемая нами проблема ни в коем случае не низкоуровневая. ))
Платформенное юзерлевельное АПИ — это и есть самый высокий уровень абстракции от железяки, на которой пашет платформа.
Блин, дорасти до своих лет и до сих пор не знать, что из себя представляет низкий уровень...
Здравствуйте, alex_public, Вы писали:
_>>>Поэтому не напрягаясь могут строить разные типы домов, из разных типов кирпичей.) P>>Так а где ж кирпичи-то? Они не предусмотрены производителем. _>А кого интересно ты считаешь производителем в мире C++? )))
Рептилоидов из параллельной вселенной.В нашей вселенной весь нейтивный код даётся сверху уже готовым. И хотя нейтивного кода существует на Земле примерно в 50 раз больше, чем дотнетного, и даже по заверениям дотнетчиков разработка единицы нейтивного кода занимает занимает больше времени, в нашей реальности его трудоёмкость строго равна 0-лю.
Здравствуйте, push, Вы писали:
V>>Поэтому, все утверждения о том, что плюсы слили — смешны. V>>Ты запускаешь наглухо плюсовую Ось, пишешь из плюсового браузера, случаешь музычку или смотришь видео через плюсовый плеер, играешь в игрухи, которые 100%-но писаны на плюсовых движках и т.д. до бесконечности. P>Вообще-то не до бесконечности — это всё единичный софт (а в игрухах денег не заработаешь).
Да какой еще единичный, если весь востребованный софт именно таков.
Это переписанная на дотнет VisualStudio — весьма узкопрофильный инструмент, то бишь единичный. ))
А нейтивные проги как раз используются массово.
P>Я сейчас даже не могу ни одного аргумента найти, чтобы человек начал пользовать плюсы в текущем виде.
А я не могу найти массово используемых программ, написанных на дотнете.
Не подскажешь, случаем?
P>Драйвера/реверсинг/системные хаки/переписываение с Java/C# — всё это требует большого опыта и специфических навыков.
Чего-чего? )))
P>Можно конечно попробовать в embeded — но вакансий там кот наплакал.
Там вакансий сегодня больше, чем в заказухе.
P>Всё остальное на плюсах не заказывают по озвученным мною причинам.
Ты пока перечислил ровно ноль из "всего остального".
V>>Бизнес со мной согласен и поэтому пилит коробочное ПО на плюсах. V>>В общем. В реальности ситуация обстоит наоборот. С++ потеснил в клиентской разработке огромный зоопарк технологий, который ... V>>Сегодня С++ является де-факто монополистом на клиенте. Все остальные сдулись. V>>На серверных технологиях на связке С/С++ писана ВООБЩЕ ВСЯ инфраструктура, и только самый-самый высокоуровневый клей — это PHP/Java/.Net. P>то мне сказать нечего — как только попаду в твою реальность, продолжим.
Да не сможешь ты тут ничего сказать, бо это объективная реальность.
Любой активный пользователь компа сходу назовёт десятки-сотни популярных нейтивных прог и ни одной дотнетной.
Любой админ линухового серверсайда может назвать тысячи нейтивных прог и ни одной дотнетной/джавовской.
P>В текущей реальности плюсовиков требуется меньше чем разработчиков на любом другом языке.
Согласно статистике — больше.
Относительно C# — примерно в 6 раз больше существует нейтивных программистов, чем дотнетчиков.
Уже проходили это исследование.
V>>Верно. Не нужно. Стандарт языка — это стандарт языка. А библиотека — это библиотека. P>Мне не понятен твой страх перед стандартом.
Мне не понятен твой страх перед понятием "библиотека".
Что с тобой не так?
Почему использование библиотек тебя напрягает?
V>>Будет меньше половины. V>>Иначе альтернативные логгеры давно бы умерли, ведь есть бустовский. P>Как раз бустовский никто и не юзает)))
Юзают аж бегом.
Но не больше альтернатив.
V>>Просто пример. Реализация shared_ptr в Бусте хороша, поэтому альтернативные реализации умерли, а эта пошла в стандарт. V>>С библиотекой логгирования этого пока не произошло и это слишком очевидный индикатор. P>Не-а, не хороша, а потому что самая простая без мульёна стратегий
Да уж нет уж. Стратегии там были. И сама бустовская реализация переписывалась. Приседания вокруг weak_ptr вовсе не тривиальные.
P>А лог не вошёл потому, что развития небыло.
Потому что заказа от индустрии не было.
Потому что специфичные вещи всё-равно не покроешь либой.
А некий высокоуровневый общий каркас логгера сегодня можно построить за вечер из того, что уже есть (а есть все требуемые "запчасти").
V>>Именно так реализован логгер в Бусте, если что. V>>Поэтому, народ часто делает СВОЙ логгер из запчастей бустовского. P>Хахаха) бустовский логер вообще никто не юзает.
Ты просто не в теме.
P>Я ради прикола в двух компаниях показывал как его юзать.
В двух...
Бустовский логгер можно юзать десятками способов. Это просто набор запчастей и концептов.
P>Но кроме "вау, скинь файлы на Confluence" больше никаких телодвижений небыло. И все продолжали юзать каждый свой логгер. Ибо бустовская реализация такой простой задачи, когда это поделие ещё надо и допиливать (ну извини, "собирать") — это полная хрень.
Это среда вокруг тебя, сформировавшая твой способ мышления — полная хрень.
V>>Это задача инженера конкретного проекта — произвести расчёты и подобрать соотв. технологию реализации фундамента. P>И делать это каждый раз при типовом проекте? Зачем?
Типовой проект делать не надо, он уже сделан.
Ему только эмблему сменить надо. ))
P>>>Пока же ни колёс, ни цепей, ни рам. Всё, что есть — набор сторонних велосипедов. V>>Ложь. P>Да нет, как раз правда, открой стандарт и посмотри, что там предлагают использовать.
Я же говорю — ложь. ))
Подскажи мне, как мне по-научному называть твою фобию перед библиотеками помимо STL?
V>>Ты забыл значение слова "стандарт". )) V>>Он определяет самые общие правила. V>>Он лишь определяет некие нормы и правила. P>Нет, он определяет чем ты можешь пользоваться для конкретного результата.
Не неткай, бо ты не понимаешь смысла слов.
Стандарт описывает ср-ва языка, но ни в коем случае не ограничивает в способах применения этих ср-в. Ограничения тут выдумываешь ты, т.е. врёшь.
P>Да нет, хочу стандартный вещей.
Хоти.
P>Вариант — ищи сторонние либы или пиши сам — он не серьезен уже в наше время
Да без проблем, вон из профессии, гоу писать на HTML.
Ой, блин, а ведь там тоже минимум пару десятков сторонних либ в проект включать придётся.
И куда тебе бедному податься? ))
P>В современном мире софт собирается из кирпичиков
Но ты же отрицаешь существование кирпичиков.
P>и лишь критически важные места могут писаться отдельно.
Так что насчёт кирпичиков?
P>И кто не может собрать за приемлемое время и бюджет — уходит с рынка, как С++ в любой из областей где у него есть конкурент.
Все конкуренты С++ на клиенте и сервере уже де-факто сдулись.
Вот где весь этот зоопарк технологий, который был в 90-е?
Умерли все.
А дотнет нишу С++ так и не занял. Дотнет занял часть ниши VB/Дельфи/FoxPro и прочей херни.
Т.е. обрати внимание — занял не всю эту нишу, а лишь часть её.
Почти все проги, изначально писанные на всей этой херне, но ставшие популярными, были переписаны затем на С++.
Здравствуйте, push, Вы писали:
P>Одним словом — Демагогия
P>был ваш детский ответ
P>Хахаха)) Вот он, плюсовый снобизм)) Видимо вы кроме плюсов не работали с другими языками.
P>Так вам понятно? Или опять будем уходить в демагогию, что "у языка XXX есть минус — ты хочешь перенести этот минус в С++"?
Молодой человек, с подобной аргументацией уровня "детский сад, младшая ясельная группа" ведите дискуссии в соответствующей аудитории.
Здравствуйте, Somescout, Вы писали: S>Ну, скажем так — аргументы у него слабоваты местами, но посмотреть на раздувшееся эго местной C++-элиты довльно забавно.
Его аргументы не "слабоваты", а просто "не в ту степь". Типа:
— Мне не нравится ваш автомобильный завод, потому что на нем негде сфотографироваться с собачкой!
— Так все фотографируются в соседнем парке, завод не для этого!
— А вот в соседнем цирке есть специальная комнатка для фотосессий.
— Так то цирк, а у нас — завод!
— Нет, это у вас просто завод плохой!
Наблюдать за этим иногда забавно, да. Но уже скучно, 101-ый "срыватель покровов с С++" на моей памяти. Сам такой был.
Здравствуйте, push, Вы писали:
_>>И ты вот реально хочешь засунуть весь этот стек сложных технологий в стандартную библиотеку C++ с API вида playfile? ))) P>Да, вся кастомизация кастомизации не нужна — выбрать самый простой вариант (один), остальное оставить на откуп сторонним либам. Мы либо можем воспроизвести звук либо нет. В будущем можно развивать, если этого не будет хватать.
Ну даже не знаю. Теоретически можно взять ffmpeg, максимально её обрезать (там есть детальная конфигурация при сборке), добавить немного кода (подобная функция play на ffmpeg будет занимать пару экранов) и получится что-то подобное. Но я что-то не слышал о сильной востребованности подобного решения, не говоря уже о включение его в стандарт.
P>Я не изучал вопрос детально, но разве нет в ОС какого-либо API для вот такого простого случая? Должен быть. Вот заюзать его.
Чтобы воспроизводить по нормальному, в своём приложение, конечно же нет. А вот если удовлетворяет некий системный плеер (у которого своё окно, контролы и т.п.), то допустим в винде есть такая штука как MCI. В других ОС не помню, имеется ли что-то подобное или нет. Но в любом случае оно и на винде не пользуется особой популярность у программистов. )))
Здравствуйте, push, Вы писали:
P>Я не изучал вопрос детально, но разве нет в ОС какого-либо API для вот такого простого случая? Должен быть. Вот заюзать его.
Windows Media Player отродясь идёт как ActiveX, для того самого простого случая этого более чем достаточно.
Можно проигрывать и аудио и видео и настраивать, какой юзеру доступен контроль над происходящим.
Здравствуйте, Went, Вы писали:
W>Наблюдать за этим иногда забавно, да. Но уже скучно, 101-ый "срыватель покровов с С++" на моей памяти. Сам такой был.
Если он "101-ый срыватель покровов", то может с С++ действительно что-то не так? Я бы, к примеру, тоже не отказался от стандартной библиотеки уровня NETFramework. Сейчас может ситуация получше, но когда мне приходилось использовать CPP, особенно на разных платформах, то искать библиотеки непонятной степени забагованности для достаточно тривиальных операций не доставляло удовольствия. Про синтаксис C++ я вообще молчу: те же copy constructors, где достаточно сделать небольшую опечатку чтобы получить некорректное поведение без синтаксической ошибки, например — неужели так не хотелось вводить новые ключевые слова? Зато производители всякого рода валидаторов для CPP без работы никогда не останутся.
Здравствуйте, Somescout, Вы писали:
S>Если он "101-ый срыватель покровов", то может с С++ действительно что-то не так?
Что именно?
S>Я бы, к примеру, тоже не отказался от стандартной библиотеки уровня NETFramework.
А оплачивать сей банкет вы откажитесь или согласитесь? Кто должен заплатить за разработку такой библиотеки?
S>Про синтаксис C++ я вообще молчу
Ну зачем же себя сдерживать?
S>те же copy constructors, где достаточно сделать небольшую опечатку чтобы получить некорректное поведение без синтаксической ошибки, например
Да, "например" бы здесь очень не помешал. Где именно можно сделать небольшую опечатку?
Обсуждалось 100500 раз, но есть ряд граждан из тех, кому ссы в глаза, а ему божья роса.
S>>те же copy constructors, где достаточно сделать небольшую опечатку чтобы получить некорректное поведение без синтаксической ошибки, например
S>Да, "например" бы здесь очень не помешал. Где именно можно сделать небольшую опечатку?
Раньше с auto_ptr было много косяков, когда у кого-то сил не хватило & нажать. Сейчас можно таким же образом из С++ сделать Питон копируя вектора по 100500 байт на каждый чих, ну и потеря владения во всяких обертках по прежнему актуальна.
Здравствуйте, landerhigh, Вы писали:
S>>Если он "101-ый срыватель покровов", то может с С++ действительно что-то не так?
L>Ага, хоронят уже... много лет, короче
А он разве утверждал, что его хоронят? Проблемы у С++ есть, их хватает (с пеной у рта это может отрицать либо тот кто плюсы плохо знает, либо оголтелый фанатик), при этом уверен, что например меня он будет до пенсии точно кормить.
Здравствуйте, landerhigh, Вы писали:
L>Ну, сначала хоронили, теперь жалуются, что библиотеки "сделать зашибись" в стандарте нет... 100500 серия мыльной оперы, в общемю
А при чем тут библиотека "сделать зашибись" и объективная скудность стандартной библиотеки. Еще скажи, что никогда на проекте не работал, где бы не было с пяток своих строк
Здравствуйте, MTD, Вы писали:
MTD>А при чем тут библиотека "сделать зашибись" и объективная скудность стандартной библиотеки. Еще скажи, что никогда на проекте не работал, где бы не было с пяток своих строк
Я сам писал свою строку. Но под четкие весьма спепцифические требования и для решения одной очень конкретной проблемы.
И что?
Здравствуйте, landerhigh, Вы писали:
L>Ага, хоронят уже... много лет, короче
Да как бы и не безуспешно: из некоторых областей CPP вытесняется, в некоторые его просто не пустили, несмотря на всю производительность.
Но серьёзно, вы действительно считаете что хорошая стандартная библиотека, вроде NETFramework или Java была бы лишней? Когда при написании небольшого приложения не нужно раздумывать какую из библиотек взять, насколько она сырая, как она будет с остальными взаимодействовать? (Офф: столкнулся с забавной ситуацией, когда оказалось что в поставке SDK есть две библиотеки реализующие shared_ptr<>, и та которая в <memory> роняет приложение через пару минут работы, зато нестандартная работает корректно — вот зачем так делать?).
Здравствуйте, Somescout, Вы писали:
S>Но серьёзно, вы действительно считаете что хорошая стандартная библиотека, вроде NETFramework или Java была бы лишней?
Я не так давно писал софт под PLC. Какую стандартную библиотеку от NET или Java можешь порекомендовать?
S>Когда при написании небольшого приложения не нужно раздумывать какую из библиотек взять, насколько она сырая, как она будет с остальными взаимодействовать? (Офф: столкнулся с забавной ситуацией, когда оказалось что в поставке SDK есть две библиотеки реализующие shared_ptr<>, и та которая в <memory> роняет приложение через пару минут работы, зато нестандартная работает корректно — вот зачем так делать?).
Здравствуйте, landerhigh, Вы писали:
L>Я не так давно писал софт под PLC. Какую стандартную библиотеку от NET или Java можешь порекомендовать?
То есть, если писать будут под микроконтроллер с 32 байтами памяти, нужно выкинуть из C++ возможность работы с динамической памятью?
L>А это уже руки.sys
Ну, извиняйте — SDK по-идее написан "профессионалами" CPP. Если уж они так косячат...
Здравствуйте, Somescout, Вы писали:
L>>Я не так давно писал софт под PLC. Какую стандартную библиотеку от NET или Java можешь порекомендовать? S>То есть, если писать будут под микроконтроллер с 32 байтами памяти, нужно выкинуть из C++ возможность работы с динамической памятью?
Ты не уходи от ответа (особенно если не знаешь, на каких CPU строятся промышленные PLC), а ответь на вопрос — какая библиотека, из тех что есть для NET или JAVA, мне сильно помогла бы при разработке софта для PLC?
Здравствуйте, Somescout, Вы писали:
S>То есть вы согласны, что её не хватает, но просто не можете промолчать?
Не согласен. Вопрос был совершенно конкретный: кто-то должен оплачивать "банкет", т.е. разработку этой самой большой стандартной библиотеки. Вы готовы взять на себя часть расходов?
S>>Ну зачем же себя сдерживать?
S>Не знаю, боюсь нарваться на открытое хамство фанатиков CPP, наверное. Вы вот, чувствуется, едва сдерживайтесь.
Могли бы вы показать, где в обращении к вам было проявлено хамство? Если же его не было, то что не позволило вам ответить на заданные вопросы?
Здравствуйте, Somescout, Вы писали:
S>Если он "101-ый срыватель покровов", то может с С++ действительно что-то не так? Я бы, к примеру, тоже не отказался от стандартной библиотеки уровня NETFramework.
Мне стандартной библиотеки хватает за глаза. Добавили регексы и еще много вкусного в стандарт? Замечательно, буст вычеркнули, работаем дальше. Все, лично мне, больше говорить нечего. На дворе 17-ый год, даже вижуал новый тащит часть этого стандарта, а я до сих пор сижу под 13-ым, который кроет только часть 11-го стандарта, и мне отлично. С++ настолько офигенный язык, что даже старого стандарта мне хватает за глаза. А когда закончу текущий проект и буду переходить на 17-ый стандарт, то это вообще будет праздник, лучший, чем Новый Год.
S>Сейчас может ситуация получше, но когда мне приходилось использовать CPP, особенно на разных платформах, то искать библиотеки непонятной степени забагованности для достаточно тривиальных операций не доставляло удовольствия.
В моей работе это все — крошки. Много сложней, например, было, имплементировать блокирующий UI на Apple-платформах не влезая в мультипоточность. Но эту задачу никакая стандартная библиотека не покроет.
S>Про синтаксис C++ я вообще молчу: те же copy constructors, где достаточно сделать небольшую опечатку чтобы получить некорректное поведение без синтаксической ошибки, например — неужели так не хотелось вводить новые ключевые слова? Зато производители всякого рода валидаторов для CPP без работы никогда не останутся.
А мне синтаксис С++ норм. Вот ваще тащусь уже 20 лет без малого. Причем некоторый код, который даже я писал 3 года назад, я прочитаю не сразу. А про вариадики так вообще говорить нечего. И все равно тащусь. А кто не тащится — тот или неосилянт или просто тащится от чего-то другого. Я не против, пускай тащатся от .NET, а я буду на С++ бабки рубить.
Здравствуйте, landerhigh, Вы писали:
L>Ты не уходи от ответа (особенно если не знаешь, на каких CPU строятся промышленные PLC), а ответь на вопрос — какая библиотека, из тех что есть для NET или JAVA, мне сильно помогла бы при разработке софта для PLC?
И сам же при этом уходишь от ответа. Ещё раз: с какого перепугу стандартная библиотека должна ограничиваться устройством наименьшими возможностями?
> особенно если не знаешь, на каких CPU строятся промышленные PLC
Понятия не имею и гуглить не собираюсь — если вы хотели что-то продемонстрировать, надо было демонстрировать, а не бросать многозначительные фразы.
Здравствуйте, Went, Вы писали:
W>Мне стандартной библиотеки хватает за глаза.
Рад за вас.
W>В моей работе это все — крошки.
Отлично. Дальше что?
W>А мне синтаксис С++ норм.
А мне нет.
Здравствуйте, Somescout, Вы писали:
L>>Ты не уходи от ответа (особенно если не знаешь, на каких CPU строятся промышленные PLC), а ответь на вопрос — какая библиотека, из тех что есть для NET или JAVA, мне сильно помогла бы при разработке софта для PLC? S>И сам же при этом уходишь от ответа. Ещё раз: с какого перепугу стандартная библиотека должна ограничиваться устройством наименьшими возможностями?
Но серьёзно, вы действительно считаете что хорошая стандартная библиотека, вроде NETFramework или Java была бы лишней?
Твои слова?
Вот я и пытаюсь услышать, что же такого афигенно жизенно-нужного есть в NETFramework, что мне бы так пригодилось в разработке софта для PLC?
>> особенно если не знаешь, на каких CPU строятся промышленные PLC S>Понятия не имею и гуглить не собираюсь — если вы хотели что-то продемонстрировать, надо было демонстрировать, а не бросать многозначительные фразы.
Ты просто там глупость про микроконтроллер сморозил.
Вы, ребята, одну вещь понять не можете. Для плюсах есть отличная стандартная библиотека. А то, что в ней нет HTTPConnector'а означает лишь то, что на плюсах решают несколько другой спектр задач.
Здравствуйте, landerhigh, Вы писали:
L>Вот я и пытаюсь услышать, что же такого афигенно жизенно-нужного есть в NETFramework, что мне бы так пригодилось в разработке софта для PLC?
Я, в свою очередь, пытаюсь от вас услышать, действительно ли вы хотите свести весь C++ к разработке софта для PLC. То есть ваш вопрос изначально подразумевает, что ничего другого на C++ делать не предполагается. Если да, и C++ ни для чего другого больше не пригоден — то само собой нормальная стандартная библиотека там не требуется.
L>Ты просто там глупость про микроконтроллер сморозил.
Я не знаю специфику вашей работы и мне на неё настолько плевать, что я не полезу искать что вы имели в виду.
L>Вы, ребята, одну вещь понять не можете. Для плюсах есть отличная стандартная библиотека. А то, что в ней нет HTTPConnector'а означает лишь то, что на плюсах решают несколько другой спектр задач.
То есть раз она вас устраивает — все остальные должны быть довольны по умолчанию? Повторюсь, "посмотреть на раздувшееся эго местной C++-элиты довльно забавно".
Здравствуйте, Somescout, Вы писали: S>Отлично. Дальше что?
Замечательно, вы поняли мой посыл. Вам хочется стандартную библиотеку уровня NetFramework? Отлично. Дальше что?
Здравствуйте, Went, Вы писали:
W>Вот ваще тащусь уже 20 лет без малого.
В принципе в данной теме теме не было никакого конструктива именно из-за этого. Вместо конструктивный возражений только "Твоя попаболь доставляет куда сильнее.". А все потому, что "ваще тащусь", а где "ваще тащусь" там мозг отдыхает.
W>Причем некоторый код, который даже я писал 3 года назад, я прочитаю не сразу. А про вариадики так вообще говорить нечего. И все равно тащусь.
Показательно.
W>А кто не тащится — тот или неосилянт
Причем некоторый код, который даже я писал 3 года назад, я прочитаю не сразу. А про вариадики так вообще говорить нечего.
Здравствуйте, Somescout, Вы писали:
S>То есть раз она вас устраивает — все остальные должны быть довольны по умолчанию?
Нет, конечно. Но всем остальным, как минимум, надо бы реально смотреть на то, как язык C++ развивается, где и как C++ используется. Поскольку желание "хочу, чтобы как в .NET", оно, мягко говоря, демонстрирует непонимание важных вещей. Как минимум. А то и желание притащить C++ туда, где от него нет пользы в принципе.
S>Повторюсь, "посмотреть на раздувшееся эго местной C++-элиты довльно забавно".
Может быть то, что вам кажется как "эго", на самом деле является опытом и взвешенным взглядом на происходящее?
Здравствуйте, MTD, Вы писали:
MTD>В принципе в данной теме теме не было никакого конструктива именно из-за этого. Вместо конструктивный возражений только "Твоя попаболь доставляет куда сильнее.". А все потому, что "ваще тащусь", а где "ваще тащусь" там мозг отдыхает.
Тащусь от языка, на котором отдыхает мозг
Здравствуйте, Somescout, Вы писали:
L>>Ты просто там глупость про микроконтроллер сморозил. S>Я не знаю специфику вашей работы и мне на неё настолько плевать, что я не полезу искать что вы имели в виду.
Иными словами, ты имеешь мнение о разработке в области, о которой ровным счетом ничего не знаешь. Симптоматично
L>>Вы, ребята, одну вещь понять не можете. Для плюсах есть отличная стандартная библиотека. А то, что в ней нет HTTPConnector'а означает лишь то, что на плюсах решают несколько другой спектр задач.
S>То есть раз она вас устраивает — все остальные должны быть довольны по умолчанию? Повторюсь, "посмотреть на раздувшееся эго местной C++-элиты довльно забавно".
Для всех остальных писателей опердней, без фреймворков уже ни на что не способных, уже есть другие языки с какими хочешь фреймворками.
Насчет "эго" — я что-то не припомню, чтобы кто-то из плюсовиков лез в ваш малеьнкий мирок с указаниями, какие должны быть фреймворки. Смотри в зеркало, в общем.
Здравствуйте, landerhigh, Вы писали:
L>Иными словами, ты имеешь мнение о разработке в области, о которой ровным счетом ничего не знаешь. Симптоматично
И как, сможете даже процитировать, где я высказывал мнение о вашей области разработки, кроме как "мне плевать"? Или вы на это и обиделись? Ну, извините.
S>>То есть раз она вас устраивает — все остальные должны быть довольны по умолчанию? Повторюсь, "посмотреть на раздувшееся эго местной C++-элиты довльно забавно".
L>Для всех остальных писателей опердней, без фреймворков уже ни на что не способных, уже есть другие языки с какими хочешь фреймворками.
Это опять к вопросу о эго (без кавычек). Нет, вы правда не задумываетесь о том что пишите?
L>Насчет "эго" — я что-то не припомню, чтобы кто-то из плюсовиков лез в ваш малеьнкий мирок с указаниями, какие должны быть фреймворки. Смотри в зеркало, в общем.
В смысле теперь вы ещё пытаетесь указывать, что писать на форуме, а что нет.
Здравствуйте, Went, Вы писали:
S>>Отлично. Дальше что? W>Замечательно, вы поняли мой посыл. Вам хочется стандартную библиотеку уровня NetFramework? Отлично. Дальше что?
Очень просто — я высказал своё мнение, вы выдали классическое УМВР (которое я спокойно игнорирую). Дальше это.
Здравствуйте, Somescout, Вы писали: S>Очень просто — я высказал своё мнение, вы выдали классическое УМВР (которое я спокойно игнорирую).
Если бы игнорировали, не писали бы в ответ.
Здравствуйте, vdimas, Вы писали:
V>Мне не понятен твой страх перед понятием "библиотека". V>Что с тобой не так? V>Почему использование библиотек тебя напрягает?
Вообще не напрягает. Но мне неудобно на каждый чих шариться в нете ища нужную либу, потом лопатить мануалы как её собрать, потом лопатить мануалы как её собрать так чтобы нужные вещи работали. Это всё ненужное, это всё можно сделать гораздо удобнее. Текущее положение дел — атавизм.
P>>А лог не вошёл потому, что развития небыло. V>Потому что заказа от индустрии не было.
Неправда. Просто неправда. Заказы есть и очень много. Достаточно посмотреть количество холиваров и визга в нете после принятия каждого стандарта.
А аргумент, что все, кто не поддерживает моё мнение — не умеют программировать на плюсах, честно говоря не состоятельный.
V>Потому что специфичные вещи всё-равно не покроешь либой.
И что? Вот от тебя постоянно звучит этот аргумент. И что с того, что не покроешь специфичные вещи? Я тебя удивлю, но STL тоже не покрывает специфичные вещи. И что?
V>А некий высокоуровневый общий каркас логгера сегодня можно построить за вечер из того, что уже есть (а есть все требуемые "запчасти").
Ну ок, можно за вечер собрать логгер на основе буста (имея опыт работы с ним). И что? Все берут уже готовую удобную либу, либо sdplog если нужна скорость (да-да, бустовский log не быстрый). Смысл от такого конструктора, когда для общего случая берут готовый, для скорости тоже берут готовый либо пишут свой. А для очень специфичного случая бустовский всё равно нужно допиливать столько, что имеет смысл сделать полностью свой.
V>Это среда вокруг тебя, сформировавшая твой способ мышления — полная хрень.
Ну да, кроме тебя никто не умеет в плюсы)))
V>Типовой проект делать не надо, он уже сделан. V>Ему только эмблему сменить надо. ))
Типовой дом уже построен — только цвет надо сменить Но почему-то люди продолжают строить ещё типовые дома.
Ты видимо не работал в больших софтверных компаниях, через мои руки одних только редакторов изображений прошло 4 штуки. И как-то не хотят заказчики пользоваться перекрашеным готовым софтом, все хотят софт, заточенный под свои нужды.
P>Да нет, как раз правда, открой стандарт и посмотри, что там предлагают использовать. V>Подскажи мне, как мне по-научному называть твою фобию перед библиотеками помимо STL?
Ну ведь опять ты всё понимаешь и начинается демагогия. Стандарт абсолютно ничего не предлагает для работы практически в любой сфере. Сторонние библиотеки — это так, фигня сбоку, всё на свой страх и риск.
P>>Да нет, хочу стандартный вещей. V>Хоти.
Спор ради спора?)))
P>>В современном мире софт собирается из кирпичиков V>Но ты же отрицаешь существование кирпичиков.
Демагогия. Я отрицаю существование стандартных кирпичиков. Ты отрицаешь, что стандартные кирпичики невозможны, а если и возможны — то это очень ужасно и принесёт один вред, и что никто вообще не хочет их.
Я показал, что они возможны, они уже есть в с++, они есть и на других стройках, планируется добавлять в плюсы всё новые и новые кирпичики, и никакого вреда это не принесло ни с++, ни остальным языкам. А наоборот все очень довольны, так как это облегчает и ускоряет разработку. Но ты старательно игноришь этот факт, изо всех сил переводя раговор вообще в левое русло, ударяясь в крайности и частности и личности, а то и вообще фантазируя. Ну троль чистой воды)
P>>и лишь критически важные места могут писаться отдельно. V>Так что насчёт кирпичиков?
"- но ведь лепку нельзя выполнить кирпичиками!"
"- конечно нельзя, лепку в любом случае надо делать вручную"
"- вот видишь — кирпичи для стройки отстой!"
Здравствуйте, vdimas, Вы писали:
P>>Вот пока что ничего кроме иррационального страха существования такой библиотеки я не увидел. V>Пока что ты демонстрировал иррациональный страх каждый раз, когда нужно было что-то попрограммировать самому.
Что-то ты такое себе нафантазировал. Боишься, что тебя заменит стандартная библиотека?
V>Просто ты так странно рассуждаешь, будто разработчики стандартной библиотеки — это какие-то не люди, а боги, которым выполнить действия (1) и (2) раз плюнуть, а для тебя они являются неподъемными.
Опять нафантазировал. Если для разработчиков стандартной библиотеки её дополнение — неподъемная задача, то пусть обращаются — за адекватную сумму я с удовольствием дополню любыми библиотеками. Но опять же ты увидишь разговор в сторону. Спор ради спора?
V>Не будешь бо не нужен. V>Их будет создавать прикладной специалист, далёкий от программирования.
У тебя страх смены предметной области? Это естественный процесс в современном мире, пора начинать адаптироваться — это не так страшно как кажется.
V>Чем высокоуровнневее задача, тем больше надо быть спецом в предметной области, а ты в ней не разбираешься — тебе же разбираться в тонкостях неохота. Это же общая такая черта характера, конкретно программирование тут не при чём. Просто в даном случае ты стремишься занять паразитическую нишу именно через программирование, то бишь ни хрена не делать но получать большую ЗП. А я тебе показываю, чем это заканчивается — тем, что более умные люди пишут что-то типа 1C, которую конфигурят уже профессиональные бухгалтера по большей части. А паразит-дельфист, пишущий свои программы исключительно из готовых компонент, в этой схеме исчезает. Он или становится настоящим программистом, или переходит в одинэсники и становится настоящим бухгалтером.
И поехала демагогия из всех щелей!
И т.д. и т.п. походу ты скатился в демагогию полностью.
Здравствуйте, landerhigh, Вы писали:
L>Ты не уходи от ответа (особенно если не знаешь, на каких CPU строятся промышленные PLC), а ответь на вопрос — какая библиотека, из тех что есть для NET или JAVA, мне сильно помогла бы при разработке софта для PLC?
Здравствуйте, Went, Вы писали:
W>Здравствуйте, Somescout, Вы писали: S>>Очень просто — я высказал своё мнение, вы выдали классическое УМВР (которое я спокойно игнорирую). W>Если бы игнорировали, не писали бы в ответ.
Как вы могли заметить, игноровал я ваш УМВР, а не ответы.
Здравствуйте, push, Вы писали:
_>>А что такого ужасного в API или сторонних библиотеках? ) P>Удобней использовать языковые средства, а если их нет — то стандартную инфраструктуру, вместо копания в API и сторонних либах.
Мне как-то безразлично какую библиотеку использовать, из поставки компилятора или скаченную из сети.
Здравствуйте, push, Вы писали:
P>Ну ок, можно за вечер собрать логгер на основе буста (имея опыт работы с ним). И что? Все берут уже готовую удобную либу, либо sdplog если нужна скорость
sdplog недостаточно быстрый
P>да-да, бустовский log не быстрый
От форматтера зависит, а он там не навязывается.
Сделай свой шустрый накопитель форматируемой строки и будет тебе самый быстрый в мире логгер.
Бустовский логгер — это всего лишь набор концептов-кубиков, из которых через систему typedef можно собрать собственную систему. Один из предлагаемых таких примеров на основе абстракции ostream — это всего лишь пример, и прямое использование этой связки, действительно, не популярно. Потому что форматтер на основе ostream не самый быстрый.
P>Смысл от такого конструктора, когда для общего случая берут готовый
Да не берут, бог с тобой.
Система логгирования обычно плотно завязана на инфраструктуру конкретного приложения, т.е. даже на банальный способ получения экземпляра общего логгера или протягивания локального для потока экземпляра безблокировочного эдакого log-source в случае асинхронного логгера. Поэтому, даже если взят "готовый логгер", то ты должен будешь нарисовать некоторую инфраструктуру вокруг него. Простейшая система асинхронного логгирования требует инициализации и соединения 3-х участников схемы с дальнейшим протягиванием зависимостей (явно, либо через контекст потока).
В общем. Похоже о логгерах у тебя весьма смутное представление.
P>А для очень специфичного случая бустовский всё равно нужно допиливать столько, что имеет смысл сделать полностью свой.
Зависит от степени повторяемости решения. Если ты своё решение используешь в десятках проектов, то имеет смысл в него вложиться. А если задача разовая, то общий каркас, даваемый бустом, очень даже потянет. Прилепи в этот каркас свой любимый шустрый форматтер (чужой или имеющийся свой) и получи готовую систему. А если у тебя до сих пор нет любимого шустрого форматтера (чужого, или своего), то "какой ты нафик танкист?" (С) Зачем тебе тогда С++?
V>>Это среда вокруг тебя, сформировавшая твой способ мышления — полная хрень. P> Ну да, кроме тебя никто не умеет в плюсы)))
Я говорил о среде, сформировавшей твои взгляды.
Разумеется, в хардкорной среде плюсовиков тоже часто обсуждаются недостатки инструмента или конкретных либ. Просто тематика этих обсуждений настолько далека от всего того, что ты говоришь, что я чистой совестью тебе озвучиваю — ты не в теме. Проблема чаще совсем в другом. А о чём ты там возмущаешься — это растереть и забыть.
Здравствуйте, push, Вы писали:
V>>Не будешь бо не нужен. V>>Их будет создавать прикладной специалист, далёкий от программирования. P>У тебя страх смены предметной области? Это естественный процесс в современном мире, пора начинать адаптироваться — это не так страшно как кажется.
Так я как раз нахожусь ровно там, где нужен программист.
И я хорошо понимаю, что мне, как программисту, надо от стандарта и ОБЯЗАТЕЛЬНЫХ в рантайме базовых либ.
А ты пытаешься найти такой "баланс сил", при котором ты не нужен. ))
V>>Чем высокоуровнневее задача, тем больше надо быть спецом в предметной области, а ты в ней не разбираешься — тебе же разбираться в тонкостях неохота. Это же общая такая черта характера, конкретно программирование тут не при чём. Просто в даном случае ты стремишься занять паразитическую нишу именно через программирование, то бишь ни хрена не делать но получать большую ЗП. А я тебе показываю, чем это заканчивается — тем, что более умные люди пишут что-то типа 1C, которую конфигурят уже профессиональные бухгалтера по большей части. А паразит-дельфист, пишущий свои программы исключительно из готовых компонент, в этой схеме исчезает. Он или становится настоящим программистом, или переходит в одинэсники и становится настоящим бухгалтером. P> И поехала демагогия из всех щелей!
Это медицинский факт и чудовищная статистика реально произошедшего с ~4-мя сотнями тысяч дельфистов на просторах СНГ.
P>И т.д. и т.п. походу ты скатился в демагогию полностью.
Здравствуйте, vdimas, Вы писали:
V>Так я как раз нахожусь ровно там, где нужен программист. V>И я хорошо понимаю, что мне, как программисту, надо от стандарта и ОБЯЗАТЕЛЬНЫХ в рантайме базовых либ.
Да понял я. Ты походу даже половины STL никогда не использовал. Ясен пень, что когда человек чем-то не пользуется — то оно ему и не надо. Потому ты и против новых либ.
А я думаю, что ж не получается объяснить то человеку очевидные вещи.
А всё оказывается просто. Ведь как объяснить — если человек дальше носа и не заглядывает в профессиональном плане?
Здравствуйте, vdimas, Вы писали:
P>>Смысл от такого конструктора, когда для общего случая берут готовый V>Да не берут, бог с тобой. V>Система логгирования обычно плотно завязана на инфраструктуру конкретного приложения, т.е. даже на банальный способ получения экземпляра общего логгера или протягивания локального ....
Я всё понял) Ты походу просто не имеешь достаточного опыта и не видел как оно должно быть. Видимо тебя без присмотра оставили на проекте и ты нагородил такого, что теперь считаешь, что логгирование — это сложно. Ну что я могу сказать — полистай хотя бы опенсорсные проекты для общего развития. Говнокода там много, но иногда попадаются нормальные проекты.
P>>А для очень специфичного случая бустовский всё равно нужно допиливать столько, что имеет смысл сделать полностью свой. V>Зависит от степени повторяемости решения. Если ты своё решение используешь в десятках проектов, то имеет смысл в него вложиться. А если задача разовая, то общий каркас, даваемый бустом, очень даже потянет. Прилепи в этот каркас свой любимый шустрый форматтер (чужой или имеющийся свой) и получи готовую систему. А если у тебя до сих пор нет любимого шустрого форматтера (чужого, или своего), то "какой ты нафик танкист?" (С) Зачем тебе тогда С++?
Во первых, пока ты доведёш буст до вменяемого состояния (начиная из подьема логгеров от конф. файлов) — я уже накидаю каркас половины приложения. Во вторых, почитай за самые основы — особенно что за зверь такой "переиспользование кода" — для чего оно нужно как этим пользоваться. Я не вижу смысла тебе что-то рассказывать, когда ты даже основ не знаешь, не понимаешь принципов разработки.
Здравствуйте, Слава, Вы писали:
С>Так она вроде для промышленных применений и создавалась как раз. Для автомобилей, например.
Промышленное применение и автомобильное есть две большие разницы.
А стандартов, призванных углубить, упрочнить и обезопасить создавалось дофига. Только стоит копнуть... лучше даже и не начинать.
Здравствуйте, push, Вы писали:
V>>Так я как раз нахожусь ровно там, где нужен программист. V>>И я хорошо понимаю, что мне, как программисту, надо от стандарта и ОБЯЗАТЕЛЬНЫХ в рантайме базовых либ. P>Да понял я. Ты походу даже половины STL никогда не использовал.
Увы, рантайм-либа одна на весь STL для самых актуальных на сегодня компиляторов.
P>Ясен пень, что когда человек чем-то не пользуется — то оно ему и не надо. Потому ты и против новых либ.
Я как раз не против новых либ, а очень даже за.
Я против пихать всё в одну либу, как ты настаиваешь.
А как только (если) либ становится больше одной, то уже малость однофигственно — входит ли эта либа в стандарт языка, в платформу или просто популярна (как тут выразился один из коллег — "промышленный стандарт де-факто").
P>А я думаю, что ж не получается объяснить то человеку очевидные вещи.
Поверхностность она такая, угу.
Не заметил еще, что ты в каждый момент времени согласен рассматривать лишь один из аргументов против, но никогда не совокупность их?
Отсюда возникает то самое хождение по-кругу, бо тебе надо напоминать те вещи, которые ты рад сразу же забыть, спустя буквально пару сообщений. ))
P>А всё оказывается просто. Ведь как объяснить — если человек дальше носа и не заглядывает в профессиональном плане?
Тоже верно. Начни хотя бы на пол-шишечки заглядывать дальше носа. И увидишь, что на сегодняшний момент для С/С++ есть прорва либ под любые направления. Проникнись тем, что столь плотного покрытия либами буквально произвольных направлений на сегодня не наблюдается ни для одного другого существующего языка, бо каждый другой язык — обязательно нишевый. И только С/С++ универсальные.
Здравствуйте, push, Вы писали:
V>>Система логгирования обычно плотно завязана на инфраструктуру конкретного приложения, т.е. даже на банальный способ получения экземпляра общего логгера или протягивания локального .... P>Я всё понял) Ты походу просто не имеешь достаточного опыта и не видел как оно должно быть.
Жесть.
Лучший способ защиты — это нападение?
Ты хоть понял, что тебе было сказано? Или оно не натянулось на твой личный опыт?
P>Видимо тебя без присмотра оставили на проекте и ты нагородил такого, что теперь считаешь, что логгирование — это сложно. Ну что я могу сказать — полистай хотя бы опенсорсные проекты для общего развития. Говнокода там много, но иногда попадаются нормальные проекты.
Да листаем мы опенсорсные проекты. Даже лучшие из них. В нашей области они сливают по эффективности примерно в 10 раз. Как раз лаборатория Интел замерами занимается. ))
Во многих опенсорсных проектах не считается зазорным получать, например, экземпляр логгера по имени из глобального синхронизируемого контейнера. Более того, унутре или прямо в публичном АПИ эти логгеры оперируют каким-нить shared_ptr, т.е. каждое получение экземпляра логгера и его освобождение дополнительно дёргает систему подсчёта ссылок на тяжеловесных атомарных interlocked-операциях, что в отсутствии конфликтов по эффективности равно двойной блокировке. Ну т.е. в наилучшем сценарии. А так-то при плотном многопоточном логгировании вся многопоточная приложуха начинает тормозить аккурат на логгере, бо все потоки на ём сталкиваются. А потом выскакивают некоторые особо шумные деятели и с пеной у рта доказывают, что "ваш С++ тормозит". )) В этом месте разрешается ржать в голос, кста, бо С++ уж точно тут не причём. А вот разработчики навроде тебя — очень даже причём. Вредят карме языка.
P>Во первых, пока ты доведёш буст до вменяемого состояния (начиная из подьема логгеров от конф. файлов) — я уже накидаю каркас половины приложения.
Так ты бустовскую библиотеку логгирования не смотрел еще? ))
P>Во вторых, почитай за самые основы — особенно что за зверь такой "переиспользование кода" — для чего оно нужно как этим пользоваться.
Ну так переиспользуй, какие проблемы?
Тем С++ и хорош, что позволяет совмещать запчасти от совершенно разных библиотек.
Бери форматтер от одной либы, вывод в консоль от другой, ротацию файла от третьей и чтение конфигов от 4-й.
Это нормально и займёт недолго.
А свой "каркас половины приложения", выполненный за это же время (пару часов на свою либу логгирования, которую ты можешь переиспользовать в десятках проектов) ты можешь смело выкинуть, бо это не каркас, а так — игрушки/эксперименты, это менее 0.01% от всей трудоёмкости среднего проекта. Ну и, повторюсь, если тебе логгер нужен более одного раза, то можно один раз ему уделить, таки, внимание. Не зря даже в дотнете нет единой системы логгирования. Их там несколько встроенных подсистем логгирования и еще несколько популярных либ сверху. ))
P>Я не вижу смысла тебе что-то рассказывать, когда ты даже основ не знаешь, не понимаешь принципов разработки.
Ты и не можешь мне ничего рассказать. По всем конкретным аргументам ты слился, тебе ответить нечего. Поэтому, перешёл к абстрактным.
Но ты же за слова не отвечаешь, верно? Т.е. не готов сравнить хотя бы даже разные способы получения экземпляра логгера (по причине чего ты сейчас налил столько бессмысленной воды)? И уж тем более не готов обсуждать схему асинхронного логгирования, я правильно тебя понимаю? Т.е., судя по тону первого абзаца в твоём посте, такой схеме нет места в твоей реальности, верно? ))
Здравствуйте, vdimas, Вы писали:
V>Жесть. V>Лучший способ защиты — это нападение? V>Ты хоть понял, что тебе было сказано? Или оно не натянулось на твой личный опыт?
Видишь ли, по всем твоим коментам можно сделать только один вывод — либо ты троль, либо не в теме.
V>Так ты бустовскую библиотеку логгирования не смотрел еще? ))
Да походу ты не смотрел. Чтобы довести её до юзабельного состояния (а не proof of concept) нужно поприседать. Более того, судя по другим бустовским либам — никто её в самом бусте дорабатывать дальше не будет.
V>Ну так переиспользуй, какие проблемы? V>Тем С++ и хорош, что позволяет совмещать запчасти от совершенно разных библиотек. V>Бери форматтер от одной либы, вывод в консоль от другой, ротацию файла от третьей и чтение конфигов от 4-й. V>Это нормально и займёт недолго. V>Ну и, повторюсь, если тебе логгер нужен более одного раза, то можно один раз ему уделить, таки, внимание.
Во-первых, нечего переиспользовать, с таким подходом нужно (именно нужно, а не можно) дописывать как ты дальше правильно и подмечаешь.
Во-вторых, то что тебе нужно дописывать самые базовые вещи — это и есть проблема плюсов.
V>Ты и не можешь мне ничего рассказать. По всем конкретным аргументам ты слился, тебе ответить нечего. Поэтому, перешёл к абстрактным.
OMG, у тебя ещё не было конкретных аргументов, все "аргументы" не в кассу. Обсуждать твои, не относящиеся к теме проблемы разработки вообще не интересно, учитывая что таких проблем у остальных не возникает.
Здравствуйте, vdimas, Вы писали:
V>Увы, рантайм-либа одна на весь STL для самых актуальных на сегодня компиляторов.
Ну я так и понял.
А в чём собственно проблема?
V>Я как раз не против новых либ, а очень даже за.
О как, но доказывал мне обратное.
V>Я против пихать всё в одну либу, как ты настаиваешь. V>А как только (если) либ становится больше одной, то уже малость однофигственно — входит ли эта либа в стандарт языка, в платформу или просто популярна (как тут выразился один из коллег — "промышленный стандарт де-факто").
Почему против пихания всё в одну — из-за деплоя?
Ну, я не настаиваю, чтобы всё обязательно было в одной либе. Я настаиваю, чтобы оно всё было описано в стандарте. А уж каким образом — одной, или сотней либ — уже не так важно.
Не предоставлять из коробки базовый функционал, не говоря уже про удобство использования — это нонсенс в наше время.
V>Не заметил еще, что ты в каждый момент времени согласен рассматривать лишь один из аргументов против, но никогда не совокупность их? V>Отсюда возникает то самое хождение по-кругу, бо тебе надо напоминать те вещи, которые ты рад сразу же забыть, спустя буквально пару сообщений. ))
У тебя все аргументы не по теме. Вот комент, на который отвечаю — один из тех, которые чудом оказались по теме.
Здравствуйте, push, Вы писали:
P>Видишь ли, по всем твоим коментам можно сделать только один вывод — либо ты троль, либо не в теме.
Либо ты не в состоянии воспринимать инфу от коллег.
V>>Так ты бустовскую библиотеку логгирования не смотрел еще? )) P>Да походу ты не смотрел. Чтобы довести её до юзабельного состояния (а не proof of concept) нужно поприседать.
Но я говорил о вполне конкретных вещах, а ты опять отвечаешь какой-то херней.
V>>Ну так переиспользуй, какие проблемы? V>>Тем С++ и хорош, что позволяет совмещать запчасти от совершенно разных библиотек. V>>Бери форматтер от одной либы, вывод в консоль от другой, ротацию файла от третьей и чтение конфигов от 4-й. V>>Это нормально и займёт недолго. V>>Ну и, повторюсь, если тебе логгер нужен более одного раза, то можно один раз ему уделить, таки, внимание. P>Во-первых, нечего переиспользовать
Странно. Другим есть.
P>с таким подходом нужно (именно нужно, а не можно) дописывать как ты дальше правильно и подмечаешь.
Под конкретную специфику? — несомненно.
Это верно для любого языка, если ты прямо отказываешься от третьестороннего готового логгера.
Тогда ты его собираешь сам из различных "запчастей".
P>Во-вторых, то что тебе нужно дописывать самые базовые вещи — это и есть проблема плюсов.
В других языках дописывать надо больше в твоём сценарии.
Похоже, тебе просто не нравится твоя работа.
V>>Ты и не можешь мне ничего рассказать. По всем конкретным аргументам ты слился, тебе ответить нечего. Поэтому, перешёл к абстрактным. P>OMG, у тебя ещё не было конкретных аргументов, все "аргументы" не в кассу.
Это не тебе решать, в кассу или нет.
Были предъявлены вполне конкретные технические аргументы и были заданы вопросы по существу.
Просто они тебе не удобны и ты предпочитаешь повторять самого себя, хотя тебе уже оппонировали.
Это даже не трольство, а просто глупость, роспись в нубстве.
P>Обсуждать твои, не относящиеся к теме проблемы разработки вообще не интересно, учитывая что таких проблем у остальных не возникает.
"Не возникают" или "не были обнаружены" — сильно разные вещи.
Анализировать предметную область, ставить задачи ты не можешь.
Мог бы — не занимался всей этой ерундой.
Потому что, по-сути, ты даже сформулировать свои претензии толком не в состоянии.
Стоит перейти к обсуждению конкретики — ты сразу сливаешь.
Наверно поэтому тебя тянет на рассуждения "об общем и прекрасном".
Скучно.
Здравствуйте, push, Вы писали:
V>>Я как раз не против новых либ, а очень даже за. P>О как, но доказывал мне обратное.
Покажи где?
Я был против пихать логгер прямо в STL.
Бо это идиотизм, разумеется.
V>>А как только (если) либ становится больше одной, то уже малость однофигственно — входит ли эта либа в стандарт языка, в платформу или просто популярна (как тут выразился один из коллег — "промышленный стандарт де-факто"). P>Почему против пихания всё в одну — из-за деплоя?
А зачем вообще динамические библиотеки существуют?
Почему бы не оформить вообще всё в одну библиотеку?
Что там у нас насчёт coupling и сohesion в нашем IT?
P>Ну, я не настаиваю, чтобы всё обязательно было в одной либе. Я настаиваю, чтобы оно всё было описано в стандарте. А уж каким образом — одной, или сотней либ — уже не так важно.
А в каком языке логгер описан в его стандарте?
P>Не предоставлять из коробки базовый функционал, не говоря уже про удобство использования — это нонсенс в наше время.
Ну так примеры будут или балабол?
V>>Не заметил еще, что ты в каждый момент времени согласен рассматривать лишь один из аргументов против, но никогда не совокупность их? V>>Отсюда возникает то самое хождение по-кругу, бо тебе надо напоминать те вещи, которые ты рад сразу же забыть, спустя буквально пару сообщений. )) P>У тебя все аргументы не по теме.
Аргументы по теме, просто тебе они не нравятся, т.е. ты слабый оппонент.
Здравствуйте, vdimas, Вы писали:
P>>Видишь ли, по всем твоим коментам можно сделать только один вывод — либо ты троль, либо не в теме. V>Либо ты не в состоянии воспринимать инфу от коллег.
Держки — http://lurkmore.to/_/1830#mws_bPiNHEO узнаёшь себя?))))
V>>>Так ты бустовскую библиотеку логгирования не смотрел еще? )) P>>Да походу ты не смотрел. Чтобы довести её до юзабельного состояния (а не proof of concept) нужно поприседать. V>Но я говорил о вполне конкретных вещах, а ты опять отвечаешь какой-то херней.
Во-во, всякую хню от тебя только и слышно. Сначала ляпнуть чушь, а потом всячески уводить тему в сторону.
P>>с таким подходом нужно (именно нужно, а не можно) дописывать как ты дальше правильно и подмечаешь. V>Под конкретную специфику? — несомненно. V>Это верно для любого языка, если ты прямо отказываешься от третьестороннего готового логгера. V>Тогда ты его собираешь сам из различных "запчастей".
OMG, я уже понял твоё мнение, что написать стандартную библиотеку чего-либо невозможно в принципе. Но вот если не добавлять её в стандарт — то магическим образом написать получается. А также — всё уже в плюсах написано и ничего писать не надо, но если рассматривать конкретный проект — всё надо писать заново.
Другими словами твои "аргументы" это либо тролинг либо шиза. Но как вариант я рассматриваю вопиющий непрофессионализм.
Остаётся только угарать над С++ комьюнити — топикстартер получается прав на 100%.
P>>Во-вторых, то что тебе нужно дописывать самые базовые вещи — это и есть проблема плюсов. V>В других языках дописывать надо больше в твоём сценарии. V>Похоже, тебе просто не нравится твоя работа.
В других языках всё в шоколаде по сравнению с плюсами в их области применения.
Критика плюсов в их текущем состоянии просто незбежна.
P>>OMG, у тебя ещё не было конкретных аргументов, все "аргументы" не в кассу. V>Это не тебе решать, в кассу или нет.
V>"Не возникают" или "не были обнаружены" — сильно разные вещи.
Да-да, я уже понял, что плюсы доступны только посвящнным — остальные по обпределению не умеют)
V>Потому что, по-сути, ты даже сформулировать свои претензии толком не в состоянии.
Серьезно? Ну перечитай мой первый комент. Что тут формулировать?
Основная проблема — отсутствие стандартной инфраструктуры языка и невероятно медленное (ну просто микроскопическое) развитие.
Но критику комента ты по сути не можешь сформулировать толком. Всё время получается ровно два варианта:
1) мне оно не надо/я этим не пользуюсь — значит никому не надо/никто не пользуется
2) невозможно написать стандартную библиотеку чего либо в принципе
Здрасте, приехали. Ты всю тему доказываешь, что невозможно что-либо добавить в стандартную библиотеку, так как невозможно написать стандартную библиотеку чего-либо в принципе.
V>А зачем вообще динамические библиотеки существуют? V>Почему бы не оформить вообще всё в одну библиотеку? V>Что там у нас насчёт coupling и сohesion в нашем IT?
Ну, я не против, чтобы поставлялись наборы библиотек. Хотя с другой стороны — те же редистры, фреймворки ставятся пачками. Если в системе больше 1 приложения — то оно всё будет нужно. Для embeded софта по хорошему вообще своя либа нужна.
V>А в каком языке логгер описан в его стандарте?
В любом есть в стандартных средствах.
P>>Не предоставлять из коробки базовый функционал, не говоря уже про удобство использования — это нонсенс в наше время. V>Ну так примеры будут или балабол?
Здравствуйте, push, Вы писали:
V>>А в каком языке логгер описан в его стандарте? P>В любом есть в стандартных средствах.
Т.е., привести пример не можешь, ЧТД.
P>>>Не предоставлять из коробки базовый функционал, не говоря уже про удобство использования — это нонсенс в наше время. V>>Ну так примеры будут или балабол? P>К примеру, возьми любой язык из большой тройки.
VS2012
MTD>Будто STL не такая. Те же аллокации на каждый чих, например, возможность перевести число в строку в выделенный буфер только в С++17 добавили. Мапе дать буфер и сказать его использовать из коробке тоже нельзя.
Здравствуйте, Timonn24, Вы писали:
T>inline string to_string(int _Val) T> { // convert int to string T> char _Buf[2 * _MAX_INT_DIG];
T> _CSTD _TOSTRING(_Buf, "%d", _Val); T> return (string(_Buf)); T> }
T>VS2012
MTD>>Будто STL не такая. Те же аллокации на каждый чих, например, возможность перевести число в строку в выделенный буфер только в С++17 добавили. Мапе дать буфер и сказать его использовать из коробке тоже нельзя.
То что ты начал изучать С++ похвально. Осталось научится правильно задавать вопросы, если что-то не понятно. Конкретно в твоем примере нет возможности создать строку in place, если не разобрался что делает код или неизвестен какой-либо термин — спрашивай, постараюсь помочь.
Здравствуйте, push, Вы писали:
P>В других языках всё в шоколаде по сравнению с плюсами в их области применения.
Вот именно что "в области их применения", т.е. в некоей узкой нише. ))
А С/С++ позиционируется немножко наоборот — эти языки "оставляют широко раскрытой дверь" для частностей платформ, для которых именно на этих языках пишут все остальные узконишевые языки/платформы.
Ты вот там рядом спрашивал, а почему же алгоритмы и контейнеры включить в стандарт можно, а логгер нельзя? Ответ очевиден — потому что алгоритмы и контейнеры слабо зависят (или не зависят вовсе) от конкретных платформ, поверх которых работает С++.
И про thread я тоже уже отвечал более чем доступно — пока не умерли своей смертью кучи экзотических платформ, куда пихали С++, реализовать некую универсальную функциональность над потоками в рамках стандарта было объективно сложно. Например, это не имело смысла еще в середине нулевых, когда в ходу было сразу несколько диалектов EC++. Потому что в ходу еще полно было платформ с вычурной реализацией многозадачности, например, сугубо кооперативной моделью с отсутствующими атомарными операциями (load/store/cas/swap). Или, того хуже, различные потоки могли обмениваться данными только через "трубу", т.е. через очередь байт. Многопоточных-то моделей де-факто было изобретено много. Ты смотрел когда-нибудь на потоковую модель первых (тех самых легендартных) поколений компьютеров Cray? Вот будет время — посмотри. Как ты там собрался реализовывать ТАКУЮ модель в стандарте языка С++?
Повторюсь, на сегодня ситуация такова, что весь этот туман более-менее рассосался. Т.е. нижележащие платформы разделились на два непересекаемых подмножества: на которых использование С++ не имеет смысла (типа Arduino/AVR, PIC, x51, Forth-процессоры, оптические, параллельные массивы навроде GPU, ИИ-процессоры и т.д.) и на которых возможна его реализация в современном (как минимум) стандарте (т.е. "универсальные" навроде MIPS/Alpha/Alchemy, x86/x64, IA64, ARM32/ARM64 и т.д.).
Итого, сегодня нет такого бесконечного градиента платформ, одно существование которых делало внесение неких платформенно-зависимых вещей в стандарт чистой воды профанацией.
И это же является ответом насчёт копирования файлов с колбэком о прогрессе — потому что такой функциональности нет не то, что в большинстве платформ, а строго наоборот — эта функциональность уникальна лишь для одного сочетания программной платформы и файловой системы. Потому что по-хорошему для этой функциональности надо рассматривать CopyFileTransacted/MoveFileTransacted, чтобы при отмене операции всё именно что отменялось, а не оставляло после себя коровьи лепешки по всему диску.
Ну а логгер в стандарте — это вообще гимн идиотизму. ))
Скажи, среди кучи имеющихся современных библиотек логгирования ты так и не смог выбрать себе подходящую?
А если смог, то не составило бы тебе труда предложить какую-нибудь из них в кач-ве кандидата в стандарт и объяснить почему именно её?
P>Критика плюсов в их текущем состоянии просто незбежна.
Критика критике рознь.
Каждый раз, когда я пытаюсь перевести твою критику в конструктивное русло, ты устраиваешь клоунаду, опять и снова улетая в облака абстракций, т.е. наглухо теряя связь с реальностью.
Ты не ответил ты пока ни на один конкретный вопрос. Двойка тебе по итогам обсуждения.
V>>"Не возникают" или "не были обнаружены" — сильно разные вещи. P>Да-да, я уже понял, что плюсы доступны только посвящнным — остальные по обпределению не умеют)
"Остальные" — это не только ты и тебе подобные. Согласно современной статистике на C/C++ пишет примерно в 5 раз больше программистов, чем на C#. Так вот, даже среди программистов на C# настольо упоротых и плохо понимающих, откуда у современного положения вещей растут ноги — их резкое меньшинство, разумеется. Упоротых всегда резкое меньшинство, ес-но, просто они самые громкие и создают информационного шума больше всех. Как раз RSDN в этом смысле — лакмусовая бумажка. Достаточно тут собраться одновременно упоротым в количестве 3-4 человек, и сразу получается как в том анекдоте про украинцев — уже партизанский отряд, уже они на голубом глазу начинают вещать от имени "всей индустрии".
Боюсь, ты плохо представляешь себе, как подобная троица смотрится в глазах десятков тысяч остальных читателей RSDN.
(да, обычно их 3-е активных каждый божий раз, когда поднимаются срачи, прямо число заколдованное, ы-ы-ы, иногда подключается на полшишечки 4-й, поэтому я обычно пользуюсь выражением "три с половиной человека" для описания этого странного феномена)
V>>Потому что, по-сути, ты даже сформулировать свои претензии толком не в состоянии. P>Серьезно? Ну перечитай мой первый комент. Что тут формулировать?
Это тебе стоило бы перечитать ответы, данные тебе. Потому что эти ответы связаны с тем, что ты писал. Потому что и контраргументы и уточняющие вопросы в наличии. А твои ответы — не связаны от слова никак. Ты как с 0-ля каждый раз пишешь, отсюда ноль продвижения и ходьба по-кругу.
Вот смог бы ты ответить на контраргументы и уточняющие вопросы, тогда, глядишь, постепенно и обозначилась бы осмысленная формулировка твоих претензий. Ну а нет, так нет.
P>Основная проблема — отсутствие стандартной инфраструктуры языка и невероятно медленное (ну просто микроскопическое) развитие.
"Стандартная инфраструктура языка" — сильно разное понятие с т.з. программистов на разных языках. Например, для Джавы, где интероп отсутствует как таковой, "стандартная инфраструктура" представляется эдакой вещью в себе, где "за МКАД-ом жизни нет". Если не напишешь на С/С++ для Джавы вспомогательную для интеропа функциональность — вот и нет никакой инфраструктуры.
И на дотнете ситуация не сильно ушла в сторону. Более-менее интероп прямо ср-вами языка возможен только OLE-совместимых АПИ: ф-ий, интерфейсов и лейаута типов данных (структур). Шаг вправо-влево и начинаются сложности — оперируешь через IntPtr как адресом и начинаешь ручками отсчитывать смещения (часто двигаясь по графу) для доступа к данным. Т.е. система типов умывает руки, программист начинает работать вместо компилятора. Такого кошмара даже программисты голого С не видят уже 40 лет. Опять рука-лицо.
В этом смысле "инфраструктура языка С++" — это сплав выразительных ср-в самого языка с легкостью доступа на самый низкий уровень платформы, поверх которой он работает (т.е. система типов продолжает работать и все выразительные ср-ва тоже). И с такой постановкой вопроса, заметь, индустрия не спорит. Но ты пытаешься. ))
P>Но критику комента ты по сути не можешь сформулировать толком. Всё время получается ровно два варианта: P>1) мне оно не надо/я этим не пользуюсь — значит никому не надо/никто не пользуется
Брехня. Было сказано об отсутствии необходимости прописывать логгер в стандарте и было 100 раз объяснено — почему. Просто ты игноришь неудобные тебе аргументы.
P>2) невозможно написать стандартную библиотеку чего либо в принципе
И это брехня. Вернее, это твои слова, которые ты всё время пытаешься приписать оппонентам. Похоже, спорить с реальными оппонентами тебе тяжело, зато выдумать себе чучело и "победить" его — вот тут доо-о-о...
Здравствуйте, vdimas, Вы писали:
V>на которых использование С++ не имеет смысла (типа Arduino/AVR)
На AVR использование плюсов как раз имеет очень много бенефитов. Как тебе реализация КА через шаблонную магию, например? Алгоритмы те же прекрасно работают. Динамической памяти нет, ну и хрен с ней.
Раскрою свои соображения насчёт логгера (бо меня утомило твоё хождение по-кругу, наводящие вопросы ты игноришь, к сути мы так никогда не доберёмся, очевидно).
================
Любая реализация чего-либо должна начинаться с концепции.
Например, когда концепции работы с потоками более-менее оформились в тех самых "платформах общего назначения", т.е. когда были набиты все шишки (на семафорах, например, которые были признаны небезопасными для прямого использования), т.е. когда были обкатаны хорошие и плохие практики, тогда и родилась реализация этой концепции.
Или, например, вопрос версионности ПО. MS изобрела офигенную штуку для преодоления "dll hell" — это технология "side by side" — SxS.
К сожалению, остальные платформы еще не созрели, у них еще происходит тот самый "dll hell" — абсолютно все unix-платформы, где пытаются с этим бороться менее продвинутыми ср-вами, например через вербальные соглашения о т.н. "semantic versions". С высоты птичьего полёта — это ха-ха три раза, но индустрия пока спасается тем что есть, как грится.
Так вот. Я не могу, разумеется, спорить с тем, что в области логгирования рано или поздно может родиться некая общепризнанная концепция. Пусть она будет сложна, многопланова, но она должна в любом случае созреть. А сейчас, блин, вовсю еще идут жаркие споры о том (прости хосподя), какой уровень логгирования должен быть более verbosity — DEBUG или TRACE, и вообще, насколько обосновано обозначать уровни логгирования в виде упорядоченного множества?
Т.е. пока мест индустрия "ищет себя" в этом плане. В некоторых логгерах и даже платформенных АПИ происходят компромиссы, например, где уровень логгирования кодируется через битовые поля: часть полей отвечают за упорядочивание множества уровней логгирования (вернее, их групп), а часть битовых полей отводится под неупорядоченное мн-во уровней логгирования внутри группы (например, уровни DEBUG и TRACE могут представляться эдакими независимыми "битовыми флагами" внутри своей "группы").
Кароч, в этой предметной области стоит только ногтём подцепить и хорошо видно, что в плане концепций еще даже конь не валялся.
А раз у индустрии на данный момент нет общепризнанной концепции/модели некоей функциональности, то не может быть и заказа на реализацию того, чего нет.
Здравствуйте, vdimas, Вы писали:
V>Или, например, вопрос версионности ПО. MS изобрела офигенную штуку для преодоления "dll hell" — это технология "side by side" — SxS. V>К сожалению, остальные платформы еще не созрели, у них еще происходит тот самый "dll hell" — абсолютно все unix-платформы, где пытаются с этим бороться менее продвинутыми ср-вами, например через вербальные соглашения о т.н. "semantic versions". С высоты птичьего полёта — это ха-ха три раза, но индустрия пока спасается тем что есть, как грится.
Ты всерьез про манифесты? Посмотри на NixOS с менеджером пакетов Nix. SxS рядом не валялся. Этом, можно сказать, динамически загружаемые библиотеки как статически слинкованные. Проблема не решается, появляется проблема хаоса из очень мало отличающихся версий либ. Один ад заменили другим адом.
Здравствуйте, landerhigh, Вы писали:
V>>на которых использование С++ не имеет смысла (типа Arduino/AVR) L>На AVR использование плюсов как раз имеет очень много бенефитов. Как тебе реализация КА через шаблонную магию, например? Алгоритмы те же прекрасно работают. Динамической памяти нет, ну и хрен с ней.
Да там помимо отсутствия new, есть еще куча приколов:
1. Стек данных и стек возврата независимы;
2. Стек возвратов аппаратный, стек данных — сугубо эмулируемый программный.
Т.е., реализация той самой "раскрутки стека" будет тяжелым мероприятием в том смысле, что подготовить десткрипторы фреймов стеков перед вызовом каждой ф-ии — это хана производительности. Итого RAII не имеет смысла, как и new.
А если взять PIC или x51, то там тоже в наличии лишь стеки возвратов, причём, глубиной всего 8. ))
В некоторых архитектурах стеки можно переключать (т.н. банки стеков).
Например, обработчик прерываний может переключиться на свой банк стеков.
Прикладная программа в этой схеме располагает глубиной стека аж 7, бо еще один уровень надо оставлять для обработчика прерываний. ))
Кароч, там куда ни ткни — овчинка выделки не стоит.
Здравствуйте, vdimas, Вы писали:
V>1. Стек данных и стек возврата независимы; V>2. Стек возвратов аппаратный, стек данных — сугубо эмулируемый программный.
Это всего лишь особенности.
V>Т.е., реализация той самый "раскрутки стека" будет тяжелым мероприятием в том смысле, что подготовить десткрипторы фреймов стеков перед вызовом каждой ф-ии — это хана производительности. Итого RAII не имеет смысла, как и new.
Какой смысл о RAII вообще начинать говорить, если динамической памяти нет?
V>А если взять PIC или
Зачем их брать, если для них компилятора плюсов даже нет?
Здравствуйте, fin_81, Вы писали: V>>Или, например, вопрос версионности ПО. MS изобрела офигенную штуку для преодоления "dll hell" — это технология "side by side" — SxS. V>>К сожалению, остальные платформы еще не созрели, у них еще происходит тот самый "dll hell" — абсолютно все unix-платформы, где пытаются с этим бороться менее продвинутыми ср-вами, например через вербальные соглашения о т.н. "semantic versions". С высоты птичьего полёта — это ха-ха три раза, но индустрия пока спасается тем что есть, как грится. _>Ты всерьез про манифесты?
Я про версионность с токенами.
В манифесте опционально указаны другие зависимости, тоже с токенами.
И/или своя "полная" версия.
Что такое "токен"? Он был введен для определения бинарной совместимости.
Например, бинарник версии "3.0" с токеном "А" удовлетворит затребованную зависимость "2.0 A", но её не удовлетворит другой бинарник "2.0 B".
Ведь именно поэтому в Linux невозможно сосуществование бинарников от разных сборок, что эти бинарники несовместимы (конфликтуют), хотя у них одинаковые или совместимые версии. Если бы ввести SxS в Linux, то можно было бы на одной системе иметь пакеты от разных сборок без всяких конфликтов, как это происходит в Windows.
_>Посмотри на NixOS с менеджером пакетов Nix.
Те же самые проблемы, которые решаются через ональную огороженность от других сборок линухов и даже от собственных сборок (разумеется!), которые имеют другую версию. ))
Трэш и угар, как по мне, но индустрия этим живёт сегодня.
_>SxS рядом не валялся.
Мде?
_>Этом, можно сказать, динамически загружаемые библиотеки как статически слинкованные.
Да это вообще не важно. Смотри в суть вещей. В линухах до сих пор ниасили link-time code generation, поэтому запросто, например, могут позволять себе подставлять статические библиотеки для динамических зависимостей. Рука-лицо, не? ))
_>Проблема не решается, появляется проблема хаоса из очень мало отличающихся версий либ. Один ад заменили другим адом.
Ну ты бы копнул SxS, там немного совсем.
Это не пакетный менеджер ни в одном из мест.
Это скромная такая, малюсенькая подсистема управления зависимостями.
ЛЮБОЙ адекватный виндовый пакетный менеджер должен сидеть поверх этой базы.
Здравствуйте, landerhigh, Вы писали:
L>Какой смысл о RAII вообще начинать говорить, если динамической памяти нет?
Как это нет? Память есть.
Зависит от конкретной аппаратной конфигурации.
Где-то 128 байт встроенного ОЗУ, где-то килобайты встроенного, а где-то можно подключить "большое" внешнее ОЗУ.
Т.е., вполне себе используют менеджеры памяти, когда это необходимо.
У меня был когда-то самописный даже для 512-ти байт ОЗУ, бо сами данные порой имеют динамическую природу.
V>>А если взять PIC или L>Зачем их брать, если для них компилятора плюсов даже нет?
Ну вот я их и взял, чтобы показать, почему там не плюсов. ))
Но С там есть.
Здравствуйте, vdimas, Вы писали:
V>Как это нет? Память есть.
Динамической в том смысле, в котором она присутствует на "больших" компах, там нет. И, что характерно, обычно и не надо.
V>Зависит от конкретной аппаратной конфигурации. V>Где-то 128 байт встроенного ОЗУ, где-то килобайты встроенного,
V>а где-то можно подключить "большое" внешнее ОЗУ.
Это ж не ОЗУ в прямом смысле этого слова.
V>Т.е., вполне себе используют менеджеры памяти, когда это необходимо. V>У меня был когда-то самописный даже для 512-ти байт ОЗУ, бо сами данные порой имеют динамическую природу.
Подобные "менеджеры памяти" иногда приходится и при разработки для полноценных PC изобретать
V>>>А если взять PIC или L>>Зачем их брать, если для них компилятора плюсов даже нет? V>Ну вот я их и взял, чтобы показать, почему там не плюсов. ))
Здравствуйте, vdimas, Вы писали:
V>... V>Что такое "токен"? Он был введен для определения бинарной совместимости. V>Например, бинарник версии "3.0" с токеном "А" удовлетворит затребованную зависимость "2.0 A", но её не удовлетворит другой бинарник "2.0 B".
Затребует приложение "2.0 С", которого нет. Что получит приложение: "длл-хелл" или "хаос версий"?
V>Ведь именно поэтому в Linux невозможно сосуществование бинарников от разных сборок, что эти бинарники несовместимы (конфликтуют), хотя у них одинаковые или совместимые версии. Если бы ввести SxS в Linux, то можно было бы на одной системе иметь пакеты от разных сборок без всяких конфликтов, как это происходит в Windows.
SxS можно эмулировать для glibc посредством символьных ссылок, LD_PRELOAD, LD_LIBRARY_PATH и других интересных переменных среды, вплоть до подмены загрузчика (ld.so) прямо из командной строки.
Только нужен ли этот комбинаторный взрыв для получения более-менее детерминированной системы?
Для винды, где пакетный менеджер — это кнопка "загрузить" на сайте vasya-pupkin.narod.ru, устанавливающий без согласия пользователя сд-эжектор от тындекса, без комбинаторного взрыва никак.
_>>Посмотри на NixOS с менеджером пакетов Nix.
V>Те же самые проблемы, которые решаются через ональную огороженность от других сборок линухов и даже от собственных сборок (разумеется!), которые имеют другую версию. )) V>Трэш и угар, как по мне, но индустрия этим живёт сегодня.
Вот именно, "индустрия" живет.
_>>SxS рядом не валялся.
V>Мде?
Мде.
_>>Этом, можно сказать, динамически загружаемые библиотеки как статически слинкованные.
V>Да это вообще не важно. Смотри в суть вещей. В линухах до сих пор ниасили link-time code generation, поэтому запросто, например, могут позволять себе подставлять статические библиотеки для динамических зависимостей. Рука-лицо, не? ))
_>>Проблема не решается, появляется проблема хаоса из очень мало отличающихся версий либ. Один ад заменили другим адом.
V>Ну ты бы копнул SxS, там немного совсем. V>Это не пакетный менеджер ни в одном из мест. V>Это скромная такая, малюсенькая подсистема управления зависимостями. V>ЛЮБОЙ адекватный виндовый пакетный менеджер должен сидеть поверх этой базы.
Вот именно, sxs — это не пакетный менеджер, это какой-то костыль, с попыткой разрулить зависимости.
Лучше бы сделали нормальный пакетный менеджер.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
L>>Какой смысл о RAII вообще начинать говорить, если динамической памяти нет? EP>RAII же не только про память — даже в языках со встроенным GC таки вводят RAII-like скобки: using, try-with-resources, with.
Так исключений обычно тоже нет.
Вот автоматический вызов деструктора при выходе из скопа все же есть.
Здравствуйте, landerhigh, Вы писали:
L>Динамической в том смысле, в котором она присутствует на "больших" компах, там нет. И, что характерно, обычно и не надо.
Есть просто некий объем памяти.
А статически ей будут пользоваться или динамически, зависит сугубо от ПО.
V>>Где-то 128 байт встроенного ОЗУ, где-то килобайты встроенного, V>>а где-то можно подключить "большое" внешнее ОЗУ. L>Это ж не ОЗУ в прямом смысле этого слова.
Именно что ОЗУ в прямом смысле.
Разве что обычно подключают статическое ОЗУ, а не динамическое, чтобы не возиться с контроллером памяти.
В общем, у всех линеек и архитектур микроконтроллеров есть версии исполнения с внешними шинами адреса и данных.
V>>Т.е., вполне себе используют менеджеры памяти, когда это необходимо. V>>У меня был когда-то самописный даже для 512-ти байт ОЗУ, бо сами данные порой имеют динамическую природу. L>Подобные "менеджеры памяти" иногда приходится и при разработки для полноценных PC изобретать
Ну я и говорю, что это сугубо софтовый аспект — как распоряжаться имеющейся памятью.
V>>>>А если взять PIC или L>>>Зачем их брать, если для них компилятора плюсов даже нет? V>>Ну вот я их и взял, чтобы показать, почему там не плюсов. )) L>Есть мнение, что их там нет вовсе не поэтому
Наблюдая за развитием плюсов, особенно за попытками притащить его в embedded, я могу дать руку на отсечение, что именно поэтому. ))
Потому что плюсы тянут за собой кучу требований.
В итоге, популярные когда-то различные компиляторы С++ для embedded-платформ придумывали всякие ограничения:
— то исключения нельзя бросать;
— то отсутствует тип данных указателя на ф-ию или на мембер структуры/класса;
— нельзя множественное наследование (теряется фишка многих трюков на шаблонах);
— некоторые отказались от шаблонов;
— и т.д.
Например, для 8051 компиляторы С++ были и есть, даже более одного (на слуху от IAR, там даже шаблоны есть, вроде бы), но там настолько урезано всё остальное, что оно толком не взлетело.
Здравствуйте, vdimas, Вы писали:
V>Есть просто некий объем памяти. V>А статически ей будут пользоваться или динамически, зависит сугубо от ПО.
Это уже философия.
На практике микроконтроллер нужен как некий КА. Шлагбаум там открывать. Или закрывать. Памяти нужно очень мало.
V>Наблюдая за развитием плюсов, особенно за попытками притащить его в embedded, я могу дать руку на отсечение, что именно поэтому. ))
А мне кажется, что больше из-за засилия там умудренных сединой старцев, дальше сей ничего не видевших и как следствие отсутствие заметной востребованности в оном.
V>Потому что плюсы тянут за собой кучу требований. V>В итоге, популярные когда-то различные компиляторы С++ для embedded-платформ придумывали всякие ограничения: V>- то исключения нельзя бросать; V>- то отсутствует тип данных указателя на ф-ию или на мембер структуры/класса; V>- нельзя множественное наследование (теряется фишка многих трюков на шаблонах); V>- некоторые отказались от шаблонов; V>- и т.д.
Кое-что напомнило... тут вроде как недавно платформу Tizen обсуждали. Где конструкторы ниасилили
Здравствуйте, fin_81, Вы писали:
V>>Что такое "токен"? Он был введен для определения бинарной совместимости. V>>Например, бинарник версии "3.0" с токеном "А" удовлетворит затребованную зависимость "2.0 A", но её не удовлетворит другой бинарник "2.0 B". _>Затребует приложение "2.0 С", которого нет. Что получит приложение: "длл-хелл" или "хаос версий"?
Получит примерно то же, что получит твой бинарник на NixOS, когда захочет версию glibc.so.7.1, а в наличии будет только glib.so.6.2.
V>>Ведь именно поэтому в Linux невозможно сосуществование бинарников от разных сборок, что эти бинарники несовместимы (конфликтуют), хотя у них одинаковые или совместимые версии. Если бы ввести SxS в Linux, то можно было бы на одной системе иметь пакеты от разных сборок без всяких конфликтов, как это происходит в Windows. _>SxS можно эмулировать для glibc посредством символьных ссылок
Нельзя и не спорь. Я плотно с этим возился одно время.
_>вплоть до подмены загрузчика (ld.so) прямо из командной строки.
Дудки, ls.so надо подменять ВСЕЙ системе, потому что версионные зависимости должны распространяться транзитивно м/у процессами, но сами эти процессы (каждый из них) не должны этой фигней заниматься. Задача любого бинарника — дать загрузчику получить инфу о своей версии и о версии зависимостей.
А учитывая, что загрузчик — это "сердце" любой операционки... В общем, ты понял. ))
_>Только нужен ли этот комбинаторный взрыв для получения более-менее детерминированной системы?
Откуда там комбинаторный взрыв?
На сегодня поддерживаемый в SxS версий бинарников для различных поколений Windows больше, чем популярных ныне семейств совместимых сборок Linux. А если ограничиться LSB (а ограничиться придётся, потому что ни в какой версии не пропишешь, какие пути корневой FS считать "правильными" и как их интерпретировать), то там остаётся 3-4 конфигурации, где 95% объема бинарников "схлопнется" в общую часть, бо де-факто бинарно совместима м/у сборками.
_>Для винды, где пакетный менеджер — это кнопка "загрузить" на сайте vasya-pupkin.narod.ru, устанавливающий без согласия пользователя сд-эжектор от тындекса, без комбинаторного взрыва никак.
Что-то облом холиварить.
Платные ОСи давно переняли моду линухов — распространяют ПО через авторизованные репозитории — "магазины приложений".
V>>Те же самые проблемы, которые решаются через ональную огороженность от других сборок линухов и даже от собственных сборок (разумеется!), которые имеют другую версию. )) V>>Трэш и угар, как по мне, но индустрия этим живёт сегодня. _>Вот именно, "индустрия" живет.
Это не отменяет трэша и угара.
На одной только несовместимости поколений RHEL 5.x/6.x/7.x индустрия теряет многие миллионы ежегодно.
V>>Ну ты бы копнул SxS, там немного совсем. V>>Это не пакетный менеджер ни в одном из мест. V>>Это скромная такая, малюсенькая подсистема управления зависимостями. V>>ЛЮБОЙ адекватный виндовый пакетный менеджер должен сидеть поверх этой базы. _>Вот именно, sxs — это не пакетный менеджер, это какой-то костыль, с попыткой разрулить зависимости.
Почему добавление к номеру версии всего одного поля (самого важного за всю историю существования версионирования как такового) провоцирует такую попоболь? ))
Это опять холиварным ветром надуло, что ле?
_>Лучше бы сделали нормальный пакетный менеджер.
"Нормальный пакетный менеджер" с колокольни Linux — это такой, где есть исключительно бесплатное ПО и который заточен под нужны исключительно разработчика ПО. Потому что для однократно настраиваемой машинки-лошадки (скажем, платёжного или справочного терминала) никакие пакетные менеджеры не нужны, разумеется. В общем, не зря пакетные менеджеры в линухах являются всего-лишь третьесторонними тулзами, а не частью системы, угу. Даже в Gentoo. ))
Здравствуйте, vdimas, Вы писали:
_>>Затребует приложение "2.0 С", которого нет. Что получит приложение: "длл-хелл" или "хаос версий"?
V>Получит примерно то же, что получит твой бинарник на NixOS, когда захочет версию glibc.so.7.1, а в наличии будет только glib.so.6.2.
Дело в том, что ты просто не установишь это приложение, не удовлетворив зависимость.
И зависимость будет не от версии, а от хеша (sha1) полного скрипта сборки этого пакета /nix/store/<sha1>-glibc-2.24/<выхлоп>.
То есть в системе может быть установлено сколько угодно версий (включая одних и тех же версий) glibc с разными ключами конфигурации под капризы каждого приложения и могут работать одновременно.
V>>>Ведь именно поэтому в Linux невозможно сосуществование бинарников от разных сборок, что эти бинарники несовместимы (конфликтуют), хотя у них одинаковые или совместимые версии. Если бы ввести SxS в Linux, то можно было бы на одной системе иметь пакеты от разных сборок без всяких конфликтов, как это происходит в Windows. _>>SxS можно эмулировать для glibc посредством символьных ссылок
V>Нельзя и не спорь. Я плотно с этим возился одно время.
Вот в NixOS разруливают, вплоть до того что стоят разные glibc одинаковой версии для бутстрапа gcc разных стадий бутстрапа, для рабочих программ, и спорить не хотят, просто работают.
_>>вплоть до подмены загрузчика (ld.so) прямо из командной строки.
V>Дудки, ls.so надо подменять ВСЕЙ системе, потому что версионные зависимости должны распространяться транзитивно м/у процессами, но сами эти процессы (каждый из них) не должны этой фигней заниматься. Задача любого бинарника — дать загрузчику получить инфу о своей версии и о версии зависимостей.
Вот установил ты новую версию glibc (2.25 -> 2.26), а система работает, демоны не падают, сериал в видеоплеере не прервался, новые файрфоксы запускаются, как это происходит?
V>А учитывая, что загрузчик — это "сердце" любой операционки... В общем, ты понял. ))
Альтернативные миры, альтернативные теории, альтернативные религии. Мультивселенная!
_>>Только нужен ли этот комбинаторный взрыв для получения более-менее детерминированной системы?
V>Откуда там комбинаторный взрыв? V>На сегодня поддерживаемый в SxS версий бинарников для различных поколений Windows больше, чем популярных ныне семейств совместимых сборок Linux. А если ограничиться LSB (а ограничиться придётся, потому что ни в какой версии не пропишешь, какие пути корневой FS считать "правильными" и как их интерпретировать), то там остаётся 3-4 конфигурации, где 95% объема бинарников "схлопнется" в общую часть, бо де-факто бинарно совместима м/у сборками.
LSB такой LSB. Никто его не придерживается и не придерживался. Так посматривали в его сторону и с высокой колокольни. Тем более корпорации, особенно красношапка со своим системд. А системд — это уже как бы стандарт.
_>>Для винды, где пакетный менеджер — это кнопка "загрузить" на сайте vasya-pupkin.narod.ru, устанавливающий без согласия пользователя сд-эжектор от тындекса, без комбинаторного взрыва никак.
V>Что-то облом холиварить.
Взаимно. Альтернативные миры как-то неконструктивны.
Здравствуйте, landerhigh, Вы писали:
L>Это уже философия. L>На практике микроконтроллер нужен как некий КА. Шлагбаум там открывать. Или закрывать. Памяти нужно очень мало.
Ну, у меня была сложная система транкинговой связи с динамически организующейся сетью ретрансляторов на 8048 (это еще в 10 раз хуже, чем 8051).
Или программируемая система музыкальных звонков в школу на PIC и вообще много всяких приблуд на нём же.
Кароч, динамики хватало, это от самой задачи зависит.
V>>Наблюдая за развитием плюсов, особенно за попытками притащить его в embedded, я могу дать руку на отсечение, что именно поэтому. )) L>А мне кажется, что больше из-за засилия там умудренных сединой старцев, дальше сей ничего не видевших и как следствие отсутствие заметной востребованности в оном.
Но не старцы решают, что надо людям.
Например, еще в стандарте move не было, а в Бусте уже программно реализовали.
L>Кое-что напомнило... тут вроде как недавно платформу Tizen обсуждали. Где конструкторы ниасилили
Почему ниасилили? Компилятором не запрещено, просто внутренний стандарт на разработку не разрешает.
Просто пример из головы:
class MyClass
{
MyClass::MyClass(Arg1 arg1, int * arg2)
try
: field1_(arg1), field2_(arg2)
{} catch (...) {
// do we need to delete arg2 here???
}
Arg1 field1_;
std::shared_ptr<int> field2_;
};
У-у-упс ))
И это при том, что try/catch для списка инициализации народ обычно ленится использовать.
Но даже когда не ленится, то вот тебе пример нежданчика.
В общем, всякие диалекты С++ для микроконтроллеров вовсе не по причине старцев стали не нужны. А потому что народу не особо нужно, с тех пор как MIPS и ARM стали стоить в деньгах сравнимо с AVR/PIC/8051. Т.е., смысл пропал надрываться с новыми технологиями под старые архитектуры. Тем архитектурам сегодня оставили, действительно, роль "программируемого автомата". Но это же производители железа должны были созреть до такой ситуации, верно? Мы же, которые программисты, мы же не в вакууме программисты, а над вполне осязаемым железом в конце всех концов. Поэтому, стандарты на ПО, считай, прямым образом управляются ситуацией в области железа.
=============
Тем более, что тот же Саттер далеко еще не старец, а очень даже живого ума человек.
В течение 10 лет Герб был организатором и секретарем комитета по стандартизации ISO C++.
Здравствуйте, fin_81, Вы писали:
V>>Получит примерно то же, что получит твой бинарник на NixOS, когда захочет версию glibc.so.7.1, а в наличии будет только glib.so.6.2. _>Дело в том, что ты просто не установишь это приложение, не удовлетворив зависимость.
А кто мне запретит?
На что спорим, что установлю?
Причём, более чем одним способом. ))
_>И зависимость будет не от версии, а от хеша (sha1)
На безрыбье и сам раком встанешь.
Если пакеты в линухах подписывать не принято, то некий токен надо формировать от "чего-то еще".
Но смысл там тот же, что и в SxS, получается. Отличия только в источнике этого токена.
И отсюда проблема в безопасности.
Потому что подменить токен подписанному пакету в SxS я не смогу, даже обладая правами администратора, а вот обладая теми же правами в NixOS запросто можно ручками "поселить" в системе еще один пакет, который как раз навернётся при попытке его использования. Или можно подменить имеющийся пакет на другой, с тем же sha1.
Здравствуйте, vdimas, Вы писали:
V>>>Получит примерно то же, что получит твой бинарник на NixOS, когда захочет версию glibc.so.7.1, а в наличии будет только glib.so.6.2. _>>Дело в том, что ты просто не установишь это приложение, не удовлетворив зависимость.
V>А кто мне запретит? V>На что спорим, что установлю? V>Причём, более чем одним способом. ))
Твоя "система", твой "мир", твое определение понятия "установить", можешь даже манифест написать.
Здравствуйте, fin_81, Вы писали:
_>>>Дело в том, что ты просто не установишь это приложение, не удовлетворив зависимость. V>>А кто мне запретит? _>Твоя "система", твой "мир"
Именно так в Linux. Что бы там ни делала любая тулзина, навроде Nix, всё это можно повторить ручками.
_>твое определение понятия "установить", можешь даже манифест написать.
А вот подменить PTK у подписанного бинарника в Window — никак.
Здравствуйте, vdimas, Вы писали:
_>>Твоя "система", твой "мир" V>Именно так в Linux. Что бы там ни делала любая тулзина, навроде Nix, всё это можно повторить ручками.
Как ты "установишь" приложение в NixOS, если в там нет LSB? Нет там стандартных /lib, /bin и тп директорий.
Можно сказать, там каждый пакет — это своеобразный контейнер, самодостаточный с зависимостями от других пакетов.
Установишь(скопируешь) ты исполнимый файл, попытаешься запустить, а он тебе скажет, что это невалидный бинарник, тк не сможет найти загрузчик ld.so. Тебе придется установить еще одну "систему с LSB", чтобы ты мог собрать и запустить приложение в обход nix. Nix (со своим libc и загрузчиком) может установлен и работать параллельно c уже установленным debian, fedora, macos.
_>>твое определение понятия "установить", можешь даже манифест написать. V>А вот подменить PTK у подписанного бинарника в Window — никак.
Кажись, кто-то изобрел серебряную пулю в виде "подписи" и свято верит. Аминь?
Здравствуйте, fin_81, Вы писали:
_>>>Твоя "система", твой "мир" V>>Именно так в Linux. Что бы там ни делала любая тулзина, навроде Nix, всё это можно повторить ручками. _>Как ты "установишь" приложение в NixOS, если в там нет LSB? Нет там стандартных /lib, /bin и тп директорий.
И?
_>Можно сказать, там каждый пакет — это своеобразный контейнер, самодостаточный с зависимостями от других пакетов.
Эх, молодёжь... ))
В своё время я для входа в очередной chroot много чего делал ручками. Вернее, писал нужный скрипт.
Это сейчас на технологию обратили внимания, стало модно. Вон докер — это лишь обслуживающая нашлёпка на chroot и весь твой Nix тоже.
_>Установишь(скопируешь) ты исполнимый файл, попытаешься запустить, а он тебе скажет, что это невалидный бинарник, тк не сможет найти загрузчик ld.so.
Ну ты людей-то за идиотов не держи и сам не подставляйся. ))
А то вдруг я подумаю, что это твой настоящий ход мыслей.
Здравствуйте, vdimas, Вы писали:
_>>Можно сказать, там каждый пакет — это своеобразный контейнер, самодостаточный с зависимостями от других пакетов.
V>Эх, молодёжь... )) V>В своё время я для входа в очередной chroot много чего делал ручками. Вернее, писал нужный скрипт. V>Это сейчас на технологию обратили внимания, стало модно. Вон докер — это лишь обслуживающая нашлёпка на chroot и весь твой Nix тоже.
Прикинь, это не chroot, вся файловая система доступна.
В общем, тебя не интересует "внешний мир". Тебе интереснее отображать "внешний мир" на свой "внутренний", отрицая все что не отображается.
Chroot головного мозга.
Звиняйте за неадекватность вашей модели. Конец.
Здравствуйте, fin_81, Вы писали:
V>>Это сейчас на технологию обратили внимания, стало модно. Вон докер — это лишь обслуживающая нашлёпка на chroot и весь твой Nix тоже. _>Прикинь, это не chroot, вся файловая система доступна.
Здравствуйте, vdimas, Вы писали:
V>Ты всегда начинаешь хамить, когда твой собственный аргумент работает против тебя?
Попробую вернуть в конструктивное русло, раз ты провоцируешь, при этом сам уходишь от конструктива.
Первым хамить начал ты, когда я показал на сомнительность "аргумента" SxS. При этом я предложил более "аргументный аргумент" в виде Nix, указав что такой подход тоже не серебряная пуля, со своими недостатками.
Потом, ты даже в глаза не видел Nix, ни разу не писал для него пакета, но рассуждаешь аргументами в виде "chroot".
И chroot можно отключить для демона сборки. Chroot нужен для того, чтобы во время сборки гарантировать, что зависимости были только те, что указаны в сценарии, так сказать, гарантировать чистоту сборки. Установленные пакеты имеют прямые ссылки в виде: бинарник с загрузчиком /nix/store/хеш/lib/ld-linux.so, также для libc — /nix/store/хеш/lib/libc.so. По этому ты не сможешь запустить сторонний бинарник в обход nix, потому что нет там libc в стандартном месте (/lib/ld-linux.so). Можно запустить только статически слинкованный, которые напрямую дергает сисколы. Для сторонних бинарей есть пакет (точнее его придется использовать и расширить своим nix-пакетом), который настраивает стандартное окружение, чтобы можно было запустить, где используется chroot.
Но ты имеешь свое мнение, и при этом указываешь на то, что это мнение единственно правильное.
Здравствуйте, fin_81, Вы писали:
_>Попробую вернуть в конструктивное русло, раз ты провоцируешь, при этом сам уходишь от конструктива. _>Первым хамить начал ты, когда я показал на сомнительность "аргумента" SxS.
Хамить — это хамить.
А не соглашаться с тобой — моё демократическое право.
_>И chroot можно отключить для демона сборки. Chroot нужен для того, чтобы во время сборки гарантировать, что зависимости были только те, что указаны в сценарии, так сказать, гарантировать чистоту сборки. Установленные пакеты имеют прямые ссылки в виде: бинарник с загрузчиком /nix/store/хеш/lib/ld-linux.so, также для libc — /nix/store/хеш/lib/libc.so. По этому ты не сможешь запустить сторонний бинарник в обход nix, потому что нет там libc в стандартном месте (/lib/ld-linux.so).
Ты опять говоришь не о том.
Еще раз, по-русски.
В системе Nix можно "ручками" (самописным скриптом каким-нить) соблюсти все эти якобы "тонкости".
Насчёт "сторонних бинарников" — я тебе уже отвечал.
Среди всех сборок линухов не так много разнообразия, гораздо меньше, чем общая сумма всех несовместимых версий.
Поэтому, у тебя всегда будет очень даже счётное кол-во тех же, допустим, "одноименных с точностью до версии" glibc, установленных в твоём Nix (3-4 штуки от силы). Поэтому, нет абсолютно никаких проблем соорудить себе систему, в которой такие бинарники бы подготавливались бы для Nix и "инжектировались" в неё уже готовыми, подменяя, скажем, критические сборки.
_>Но ты имеешь свое мнение, и при этом указываешь на то, что это мнение единственно правильное.
Я тебе уже указывал на то, что ты плохо понимаешь, о чём рассуждаешь.
Невнимателен, не используешь воображение. Боишься представить, как оно всё в принципе может быть устроено (там элементарно, вообще-то).
Здравствуйте, vdimas, Вы писали:
_>>Попробую вернуть в конструктивное русло, раз ты провоцируешь, при этом сам уходишь от конструктива. _>>Первым хамить начал ты, когда я показал на сомнительность "аргумента" SxS.
V>Хамить — это хамить. V>А не соглашаться с тобой — моё демократическое право.
Хамство — это, так сказать, "доминация" над собеседником, что ты и демонстрируешь, настаивая на единственно правильном своем мнении, при этом не видел предмет обсуждения.
V>Ты опять говоришь не о том. V>...
И опять ты говоришь о том, что не видел, но мнение имеешь. То "chroot", то скрипты... Что еще?
Ты бы хотя писал перед своим сообщением — "не читал, но осуждаю".
Конструктив с тобой невозможен.
Здравствуйте, fin_81, Вы писали:
_>И опять ты говоришь о том, что не видел, но мнение имеешь. То "chroot", то скрипты... Что еще?
Так я тебе объяснять что ле должен про "разрыв первого рода", когда бинарники в твоём Nix получаются отдельно, а их "регистрация" в системе отдельно? Ты ведь так и не объяснил, в чём должна заключаться невозможность подделки всего того, что делает сама Nix. )) Мне-то казалось, что повторенного более одного раза напоминания про невозможную к подделке подпись самих бинарников в виндах должно было быть достаточно, ы? Ты сам разве не увидел еще принципиальной разницы этих двух подходов? Там ведь всё глубже получается, если копнуть. В проприетарном ПО сам разработчик является владельцем приватного ключа подписи, т.е. у меня доступа к "исходнику" этой подписи нет. А с открытым ПО что делать, ы?
Здравствуйте, vdimas, Вы писали:
V>Так я тебе объяснять что ле должен про "разрыв первого рода", когда бинарники в твоём Nix получаются отдельно, а их "регистрация" в системе отдельно? Ты ведь так и не объяснил, в чём должна заключаться невозможность подделки всего того, что делает сама Nix. )) Мне-то казалось, что повторенного более одного раза напоминания про невозможную к подделке подпись самих бинарников в виндах должно было быть достаточно, ы? Ты сам разве не увидел еще принципиальной разницы этих двух подходов? Там ведь всё глубже получается, если копнуть. В проприетарном ПО сам разработчик является владельцем приватного ключа подписи, т.е. у меня доступа к "исходнику" этой подписи нет. А с открытым ПО что делать, ы?
Тебе надо знать все дерево хешей, чтобы подменить. Если я поменяю ключи сборки gcc, libc или другого пакета, потому что я маньяк-оптимизатор и люблю свои ключи оптимизации под конкретное железо, то всю дерево зависимостей поменяет хеши. Полная пересборка всей системы, точнее, всего графа зависимостей. А ключей может быть много, тем более сценариев сборки пакетов, что приведет к "хаосу версий"(с)сам придумал. Про эту багофичу я сразу сказал. Получаем уникальную систему, и другой бинарник из другой nixos не запустится простым копированием, потому что не найдет нужные зависимости. Придется хачить/патчит бинарник, и это может сделать только сама система (nix).
Естественно можно ничего не менять, и пользоваться доверенными собранными системами от дистра. И работать от рута ("админ" в винде — это не рут), подменять бинарники на свои, писать напрямую в память процессов, но тут ты ссзб. И даже в этом случае, ты можешь сам пересобрать пакеты с проверкой повторяемости сборки.
Повторю, SxS — это костыль с попыткой разрулить зависимости, "длл-хелл" и "хаос версий" в одном флаконе.
Здравствуйте, vdimas, Вы писали:
V>В этом месте ты мне делаешь смешно уже 5-й раз.
Смайл ты поставил только два раза, не сходится. Опять попытка "доминации" над собеседником, но опять предмет обсуждения не видел.
В nixos уже есть готовые сценарии для автоматического патча сторонних бинарников, или настройки стандартного окружения. И после патча получаешь уникальную программу под свою уникальную систему. И "третья заинтересованная сторона" может только гадать эти хеши в попыткам подменить. То есть разаработчик/мейнтейнер отвечает за корректность сборки, при этом не знает какой конкретно бинарь получиться у конкретного пользователя. Пользователь получает свою уникальную систему. Не нужны "третьи заинтересованные стороны" в виде центров раздающих направо и налево сертификаты.
Но ты смеешься над неизвестно чем, даже не можешь описать над чем. "Конструктивненько" "доминируешь".
Здравствуйте, fin_81, Вы писали:
V>>В этом месте ты мне делаешь смешно уже 5-й раз. _>Но ты смеешься над неизвестно чем, даже не можешь описать над чем. "Конструктивненько" "доминируешь".
А зачем ты скипнул свой абзац в ответе?
Там хорошо видно, что именно меня улыбает.
Здравствуйте, vdimas, Вы писали:
V>А зачем ты скипнул свой абзац в ответе? V>Там хорошо видно, что именно меня улыбает.
Что скипнул? То что придется что-то делать ментейнеру для описания зависимостей, а пользователю мирится с тем что неустановленные программы не работают?
В SxS также придется описать зависимости, а пользователю придется мириться с гигабайтами версий. И все равно окажется что нужных версий не оказалось, и мы получаем длл-хелл, то есть проблему не решили. Для этого нужно вес комбинаторный взрыв хранить. Что привело к тому, что SxS хранить хардлинки на одну и ту же версию под разными именами. То есть откровенный самообман. Но тут тебе не смешно, ты это продвигаешь как серебряную пулю.
Здравствуйте, fin_81, Вы писали:
_>В SxS также придется описать зависимости, а пользователю придется мириться с гигабайтами версий. И все равно окажется что нужных версий не оказалось, и мы получаем длл-хелл, то есть проблему не решили. Для этого нужно вес комбинаторный взрыв хранить. Что привело к тому, что SxS хранить хардлинки на одну и ту же версию под разными именами. То есть откровенный самообман. Но тут тебе не смешно, ты это продвигаешь как серебряную пулю.
Ты опять подменяешь тему и я тебе уже указывал, что ты возражаешь не на то, на что пишешь свой ответ. Я тебе говорил о ненадёжности системы Nix в случае злонамеренных действий. А ты говоришь исключительно о "позитивных" возможностях системы. Т.е. симулируешь спор по таким вопросам, по которым спора нет.
Вот и получается, что я должен совсем уж на пальцах с тобой изъясняться. Например, о том, что "взломать" подписанные сборки в виндах можно только через ядерные руткиты. Потому что не взломать, а тупо подменить собой часть ядра операционки. А в твоих Nix-ах достаточно будет юзерлевельного привилегированного доступа. Просто я не сразу понял, что ты нихрена не понял из того, что тебе говорят. Мне казалось ты просто дурочку ломаешь, ан нет, не ломаешь. Уж лучше бы ломал, а то чистой воды залёт получается. ))
Здравствуйте, vdimas, Вы писали:
V>... Например, о том, что "взломать" подписанные сборки в виндах можно только через ядерные руткиты ...
С каких пор sxs.dll грузится как процесс ядра? Почему привилегированный пользователь не может его подменить? Почему привилегированный пользователь не может просто удалить директории с sxs? Что за альтернативная реальность?
Вообщем, всё это у меня вызывает отвращение. Это даже не "неконструктив", это первородный хоас. Спасибо за внимание.
Здравствуйте, fin_81, Вы писали:
V>>... Например, о том, что "взломать" подписанные сборки в виндах можно только через ядерные руткиты ... _>С каких пор sxs.dll грузится как процесс ядра?
sxs.dll — это не загрузчик, а всего-лишь утилита по организации кеша — регистрации и удаления из него сборок.
_>Почему привилегированный пользователь не может его подменить?
Потому что сам sxs.dll тоже подписан, а подпись подделать невозможно.
_>Почему привилегированный пользователь не может просто удалить директории с sxs? Что за альтернативная реальность?
Удалить может, но не может подделать.
_>Вообщем, всё это у меня вызывает отвращение.
Отвращение к знаниям?
За тот срок, сколько мы общаемся по этой теме, можно было уже раз 10 досконально изучить материал и перестать так жестоко подставляться.
Отвечу только на это, т.к. это смешит меня с начала.
V>... V>Потому что сам sxs.dll тоже подписан, а подпись подделать невозможно. V>...
Подпись — серебряная пуля.
Кем подписан, "третьей заинтересованной стороной"?
Ты еще скажи, что uefi и secure boot спасет отца русской демократии, ключи которго раздаются/утекли кому попало, и не даст загрузить неподписанные бинаркники в память.
Здравствуйте, fin_81, Вы писали:
V>>... V>>Потому что сам sxs.dll тоже подписан, а подпись подделать невозможно. V>>... _>Подпись — серебряная пуля.
Это плохой вопрос. Потому что намекает на то, что VPN, SSH, SSL и прочее pgp-мыло и даже подписанные электронные отчёты в налоговую нафик никому не сдались.
Подпись — это подпись. Удостоверяет некую сторону.
В данном случае — некоего конкретного разработчика ПО, владельца этой подписи.
_>Ты еще скажи, что uefi и secure boot спасет отца русской демократии, ключи которго раздаются/утекли кому попало, и не даст загрузить неподписанные бинаркники в память.
Да нет же, давай откажемся от электронных подписей вовсе! Именно по причине того, что ключи secure boot от некоей материнки утекли.
А кто мешает тебе скачать новую прошивку от производителя материнки с неутекшими ключами, ы?
Здравствуйте, vdimas, Вы писали:
_>>Подпись — серебряная пуля.
V>Это плохой вопрос. Потому что намекает на то, что VPN, SSH, SSL и прочее pgp-мыло и даже подписанные электронные отчёты в налоговую нафик никому не сдались.
Как получают электронные подписи для отчетности в РФ — это полная профанация, сделано для галочки.
Про все остальное — это инструменты, которыми надо уметь пользоваться, чтобы получить продукт.
_>>Кем подписан, "третьей заинтересованной стороной"?
V>Подпись — это подпись. Удостоверяет некую сторону. V>В данном случае — некоего конкретного разработчика ПО, владельца этой подписи.
Подпись на подписи подписью погоняет.
Какую пропишу/зарегистрирую в системе от привилегированного пользователя, как "правильную" подпись/бинарь, такая и будет "правда".
Но для винды — это хорошо, в случае линукса — это плохо.
_>>Ты еще скажи, что uefi и secure boot спасет отца русской демократии, ключи которго раздаются/утекли кому попало, и не даст загрузить неподписанные бинаркники в память.
V>Да нет же, давай откажемся от электронных подписей вовсе! Именно по причине того, что ключи secure boot от некоей материнки утекли. V>А кто мешает тебе скачать новую прошивку от производителя материнки с неутекшими ключами, ы?
Дело в том, что ключи эти не от производителей материнок, телефонов и тп. А от самой "заинтересованной третьей стороны", от MS.
То есть в secure boot нужен механизм с отзывом, временем жизни сертификатов и тп.
Но secure boot придуман не для secure, а для банального вендорлок.
Здравствуйте, fin_81, Вы писали:
_>Какую пропишу/зарегистрирую в системе от привилегированного пользователя, как "правильную" подпись/бинарь, такая и будет "правда".
Для твоего Nix это именно так. Я тебе сразу об этом же сказал.
_>Но для винды — это хорошо, в случае линукса — это плохо.
Это когда код ничей. В этом есть и плюсы и минусы, ес-но.
Для разработчика плюс, для конечного пользователя — минус.
_>Дело в том, что ключи эти не от производителей материнок, телефонов и тп. А от самой "заинтересованной третьей стороны", от MS.
Ну ты различай ключи шифрования, сертификаты, подписи, и как они соотносятся.
Утекшие ключи не имеют к сертификатам никакого отношения.
Имея один подписанный ключ шифрования невозможно по нему восстановить сертификат (приватную его часть) и заверить им же другой ключ.
_>То есть в secure boot нужен механизм с отзывом, временем жизни сертификатов и тп.
Не надо на ходу придумывать что там нужно, а что не нужно. ))
Уже давно придумали.
_>Но secure boot придуман не для secure, а для банального вендорлок.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, fin_81, Вы писали:
_>>Какую пропишу/зарегистрирую в системе от привилегированного пользователя, как "правильную" подпись/бинарь, такая и будет "правда".
V>Для твоего Nix это именно так. Я тебе сразу об этом же сказал.
В винде точно так же. Иначе ты бы не смог обновить систему. Потому что у новых бинарей будут "неправильные" подписи.
_>>Но для винды — это хорошо, в случае линукса — это плохо.
V>Это когда код ничей. В этом есть и плюсы и минусы, ес-но. V>Для разработчика плюс, для конечного пользователя — минус.
В смысле код ничей? Код конкретного разработчика или сообщества, для которого можно посчитать конкретный хеш на определенный момент времени и пространства, собран конкретным пользователем под конкретное окружение, в соответствии конкретным сценарием и получен конкретный бинарь. Можно повторить и проверить идентичность сборки при одинаковых условиях, или сделать выводы что кто-то ведет себя совсем не детерминировано.
_>>Дело в том, что ключи эти не от производителей материнок, телефонов и тп. А от самой "заинтересованной третьей стороны", от MS.
V>Ну ты различай ключи шифрования, сертификаты, подписи, и как они соотносятся. V>Утекшие ключи не имеют к сертификатам никакого отношения. V>Имея один подписанный ключ шифрования невозможно по нему восстановить сертификат (приватную его часть) и заверить им же другой ключ.
Утекли приватные ключи, которыми можно подписать загрузчик.
И они не могли быть вечно секретными (это моя аксиома).
_>>То есть в secure boot нужен механизм с отзывом, временем жизни сертификатов и тп.
V>Не надо на ходу придумывать что там нужно, а что не нужно. )) V>Уже давно придумали.
Ты еще скажи, что он реализован в secure boot в полном объеме с удостоверяющими центрами в интерент.
Также у x509 есть некоторые проблемы. А они не могли не быть (это тоже моя аксиома).
Хотя стоп, говорят, в intel me реализован сетевой стек.
_>>Но secure boot придуман не для secure, а для банального вендорлок. V>Для защиты устройства от подмены ПО.
Почти не смешно.
Здравствуйте, fin_81, Вы писали:
V>>Для твоего Nix это именно так. Я тебе сразу об этом же сказал. _>В винде точно так же. Иначе ты бы не смог обновить систему. Потому что у новых бинарей будут "неправильные" подписи.
Подписи как раз будут правильные: http://www.rsdn.org/forum/flame.comp/6964456.1
Я ведь как раз с бинарной совместимости начал.
Можно обновить библиотеку низкого уровня без того, чтобы пересобирать вообще весь софт на машине, как это потребуется на твоей nix. ))
V>>Это когда код ничей. В этом есть и плюсы и минусы, ес-но. V>>Для разработчика плюс, для конечного пользователя — минус. _>В смысле код ничей?
Да так, ничей. Невозможно идентифицировать, кто именно его собирал и что он с ним делал.
_>Код конкретного разработчика или сообщества, для которого можно посчитать конкретный хеш на определенный момент времени и пространства, собран конкретным пользователем под конкретное окружение, в соответствии конкретным сценарием и получен конкретный бинарь.
Слишком много слов для простого "собран непонятно кем из непонятно каких сырцов".
_>Можно повторить и проверить идентичность сборки при одинаковых условиях, или сделать выводы что кто-то ведет себя совсем не детерминировано.
Если хеш хранится отдельно от бинаря, то нет ему доверия.
А насчёт "проверить и сделать выводы" — смишно.
Это бухгалтер или секретарша на своём офисном компе будут проверять?
V>>Имея один подписанный ключ шифрования невозможно по нему восстановить сертификат (приватную его часть) и заверить им же другой ключ. _>Утекли приватные ключи, которыми можно подписать загрузчик.
Ключ не живёт в вакууме. Обнови прошивку материнки (знания о публичной части ключа или сертификате, его подписавшем) и этот ключ больше не будет приниматься при старте.
_>И они не могли быть вечно секретными (это моя аксиома).
Разумеется, любая защита не является абсолютной. Но стандарт X.509 даёт очень хороший размен телодвижений (де-факто совсем небольших) на получаемую степень защиты (де-факто огромную).
V>>Не надо на ходу придумывать что там нужно, а что не нужно. )) V>>Уже давно придумали. _>Ты еще скажи, что он реализован в secure boot в полном объеме с удостоверяющими центрами в интерент.
Любая система, построенная на основе X.509, всегда сидит поверх в некоего доверенного артефакта. Т.е. любая доверительная система должна с чего-то начинаться. Поэтому, твой "удостоверяющий центр" в интернете ничем не лучше какого-нить своего локального удостоверяющего центра (с его рутовым артефактом/артефактами). И для целей совсем суровой безопасности интернетный центр намного хуже локального, разумеется. Это как оно работает в реальной жизни.
_>Также у x509 есть некоторые проблемы. А они не могли не быть (это тоже моя аксиома).
Если под "некоторыми проблемами" ты подразумеваешь отсутствие абсолютной защищённости, то ты тем самым отвергаешь сам смысл защиты как таковой. Потому что любая система защиты не абсолютна. Но она может гарантировать какую-нить чудовищную трудоёмкость по её обходу, что может делать мероприятия по обходу защиты бессмысленными. Что и требуется.
Здравствуйте, vdimas, Вы писали:
V>Я ведь как раз с бинарной совместимости начал. V>Можно обновить библиотеку низкого уровня без того, чтобы пересобирать вообще весь софт на машине, как это потребуется на твоей nix. ))
Бинарная совместимость и можно поменять любой бинарий, главное подпись была "правильной". Но "подменить нельзя".
Ты подменил "бинарную совместимость" на "правильно подписать".
Почти не смешно.
V>Слишком много слов для простого "собран непонятно кем из непонятно каких сырцов".
Без комментариев.
Так и запишем, "правильно подписан" — это гарантия того, что подписал понятно кто понятно какой бинарь, собранный из понятно каких исходников.
V>Если хеш хранится отдельно от бинаря, то нет ему доверия. V>А насчёт "проверить и сделать выводы" — смишно. V>Это бухгалтер или секретарша на своём офисном компе будут проверять?
Жесть.
Хеш, бинарь, вместе, доверие, секретарша...
Это не возможно как-то коментировать.
V>>>Имея один подписанный ключ шифрования невозможно по нему восстановить сертификат (приватную его часть) и заверить им же другой ключ. _>>Утекли приватные ключи, которыми можно подписать загрузчик.
V>Ключ не живёт в вакууме. Обнови прошивку материнки (знания о публичной части ключа или сертификате, его подписавшем) и этот ключ больше не будет приниматься при старте.
Ну обнови прошивку в своем компе, планшете, смартфоне. Как нет обновления? Есть решение — купить новый, там-то точно новый secure boot с "правильными" ключами, и всего за 99999 рублей.
_>>И они не могли быть вечно секретными (это моя аксиома).
V>Разумеется, любая защита не является абсолютной. Но стандарт X.509 даёт очень хороший размен телодвижений (де-факто совсем небольших) на получаемую степень защиты (де-факто огромную).
"Де-факто".
Ты еще скажи есть результаты экспериментов с доверительным интервалом 5 сигма.
V>>>Не надо на ходу придумывать что там нужно, а что не нужно. )) V>>>Уже давно придумали. _>>Ты еще скажи, что он реализован в secure boot в полном объеме с удостоверяющими центрами в интерент.
V>Любая система, построенная на основе X.509, всегда сидит поверх в некоего доверенного артефакта. Т.е. любая доверительная система должна с чего-то начинаться. Поэтому, твой "удостоверяющий центр" в интернете ничем не лучше какого-нить своего локального удостоверяющего центра (с его рутовым артефактом/артефактами). И для целей совсем суровой безопасности интернетный центр намного хуже локального, разумеется. Это как оно работает в реальной жизни.
Конечный пользователь может управлять "доверенными артефактами", или он навязывается "третьей стороной".
Когда я отключаю secure boot и гружу мой загрузчик, вместо загрузчика подписанного "третьей стороной", про которого в интернете говорят, что у него утекли какие важные ключи... Это какая "степень защиты" и "доверия"?
_>>Также у x509 есть некоторые проблемы. А они не могли не быть (это тоже моя аксиома).
V>Если под "некоторыми проблемами" ты подразумеваешь отсутствие абсолютной защищённости, то ты тем самым отвергаешь сам смысл защиты как таковой. Потому что любая система защиты не абсолютна. Но она может гарантировать какую-нить чудовищную трудоёмкость по её обходу, что может делать мероприятия по обходу защиты бессмысленными. Что и требуется.
Трудоемкость обхода — скомпрометировать коневой сертификат, что уже сделано.
Про какое еще доверие вообще речь?
Это 60-е годы прошлого века. Создатели Java тогда в детский сад ходили (те, кто уже родился).
