Здравствуйте, Mazay, Вы писали:
KP>>>Ну разве что только те, кто так и не открыл для себя shared_ptr и unique_ptr
IT>>И сколько ещё всяких разных подпорок и затычек нужно для себя открыть?
M>Сейчас добавились умные указатели (shared, unique, weak и intrusive) и rvalue-ссылки.
Мне нравится слово "сейчас"
Здравствуйте, D. Mon, Вы писали:
DM>Есть пока некоторые больные места в его реализациях (вроде GC), но если на них сильно не наступать, то очень годный язык уже сегодня, а по сочетанию понятности-выразительности-скорости, пожалуй, круче всех.
В D проблема с конкурентностью — о ней никто не думал, потому получилась yet another native Java с общим хипом. Отсюда и проблемы с GC, которые неустранимы по дизайну.
Если на это пофиг, то стоит посмотреть на Go.
Пока из языков, которые избежали этого, есть только Rust.
Здравствуйте, Cyberax, Вы писали:
C>Я тут пишу клиент для Amazon S3 на Rust, причём у меня задача сделать его офигительно параллельным. Пока получается очень неплохо, по сравнению с предыдущей версией на С++.
А тебя не утомляет каждый раз переписывать код, после того как в очередной версии все внезапно поменяли? Или ты сидишь на ветке из Git?
Да, а вот теперь реально интересующий меня вопрос. Ты что используешь в качестве сетевого уровня? Текущая версия из Rust, мягко говоря, не завершена.
Здравствуйте, Cyberax, Вы писали:
C>Я тут пишу клиент для Amazon S3 на Rust, причём у меня задача сделать его офигительно параллельным. Пока получается очень неплохо, по сравнению с предыдущей версией на С++.
Попытался я его попробовать. Скачал инсталлятор с их сайта, запустил, поставил... А бинарник их не запускается, т.к. нет какой-то там библиотеки от mingw. Т.е. они и не осилили опцию "-static" mingw и не сподобились положить нужную библиотеку в инсталлятор. Теперь даже и не охота качать исходники их и компилировать самому при таком отношение к пользователям...
C>С++1x тоже очень неплох, но сейчас слишком не хватает нормальной параллельности. Если на неё пофиг, то всё вполне ОК.
А что подразумевается под нормальной параллельностью? Мне правда интересно. )
KP>>D — вроде хороший, но не менее экзотический и уже, похоже что, без перспектив, в отличие от... C>Его сразу в морг.
Здравствуйте, IT, Вы писали:
IT>Это хорошо. А второй, который shared?
shared_ptr/weak_ptr естественно добавляет по мелочи относительно голых указателей, но их соответственно и употребляют взамен не голых указателей, а тоже нетривиальных велосипедов не попадающих под RAII. Так что никакого провала в производительности при переходе с древнего велосипедного C++ на современный нет. А безопасность при этом становится гарантированной компилятором, как и в управляемых языках. Только эффективнее. )))
Здравствуйте, kaa.python, Вы писали:
KP>Не совсем. Что на JVM, что на .NET типичный подход выглядит как-то так: "главное задача, памяти бесконечно много, не хватает мощности — поставим на кластер". Умный это подход или глупый, в общем случае, – мне судить сложно. С точки зрения системного C++ разработчика – подход глупый, но, бизнес, вроде как устраивает.
Это не на JVM или .Net, а во вполне определенных областях. Как правило тормозные монстры до того как их сделали на джаве или нете, были еще более тормозными и глючными в своем плюсовом детстве.
KP>Ну и в целом, большинство JVM и .NET смутно представляют себе то, как работает их код на железе, что тоже не слабо сказывается на его качестве. Этот нюанс прослеживается что на форуме, что в личной беседе.
Проблема опять же не в джаве и дотнете, а именно в том, что большинство не понимает как код ложится на железо. Если человек в дотнете сравнивает все значения через .ToString(), то как правило в С/С++ он делал в сто раз больше строчек кода что бы в итоге вызвать чтото навроде strcmp или memcmp. До смешного доходит — bool конвертируется в строку и сравнивается с "True". Имел возможность сравнивать С++ код таких разрабов — там вообще туши свет, десятки килобайт кода просто что бы сравнить два объекта
Собтсвенно это большинство, которое не понимает, как код ложится на железо, примерно одинаковое по квалификации везде, и доля этого большинства везде в мейнстриме примерно одинаковая. Вот скажем в обработке звука или геймдеве таких героев очень мало, а в мейнстриме — пожалуйста.
Здравствуйте, MTD, Вы писали:
MTD>Если отбросить эмоции, то Java/.Net разработчики не задумываются о ресурсах/алгоритмах. Мне прямо говорили: "В бизнес-приложениях алгоритмы не нужны, у нас все в базу упирается".
Эти бизнес-приложения в до-менеджед период писались точно так же — "В бизнес-приложениях алгоритмы не нужны, у нас все в базу упирается", при чем на самом что ни есть православном С++.
Лично я уходил на дотнет из за наличия инструментов, с помощью которых можно навести порядок в коде. Для С++ их и по сей день нет. Потому древний код, который никто не знает, как должен работать, привести в порядок крайне тяжело. В дотнете, джаве — очень просто, т.к. средства автоматического рефакторинга, тесты всяких сортов, анализаторы кода и тд и тд берут на себя примерно 90% той работы, которую на С++ надо делать руками.
Теоретически, на С++ чтото даже есть, но это сильно условно, т.к. благодаря тем техникам, что уже по факту укоренились в С++, ни один тул не может ничего гарантировать, даже простое переименование метода местами даёт проблемы.
Здравствуйте, kaa.python, Вы писали:
KP>Т.е. с утверждением: "главное задача, памяти бесконечно много, не хватает мощности — поставим на кластер" ты согласен?
DM>>Жизнь слишком коротка, чтобы учить С++.
KP>Не такой уж он и сложный
Не сложный но занимает время. Для промышленной разработки много С++-а как такового не надо. Совсем несложно посидеть с компилятором чтобы заучить разные фишки. Гараздо сложнее делать свой проект который кому-то будет приносить пользу (и возможно тебе деньги). Поэтому те кто делают свои проекты и те же люди с Шаровары вызывают у меня намного больше симпатии. Для меня они — профессионалы а не любители стандарта С++ и Александреску.
IT>>Это стандартные домыслы, с ними нет смысла спорить.
KP>Это не стандартные домыслы. Это утверждение, которое очень часто приводится в дискуссиях как довод в пользу управляемых языков.
IT>>ЗЫ. А ты сам с "Дураков, пишущих на плюсах не меньше, а может быть даже больше..." тоже получается согласен?
KP>Распределение дураков везде приблизительно одинаковое, сложно с этим спорить, да и зачем... Но вот дурак и разработчик не думающий об алгоритмах и ресурсах это совсем разные вещи.
То есть ты хочешь сказать что ты как С++ программист будешь использовать std::set<> чтобы, например, сделать проверку уже какой-то обработанной "штуки" в то время как тупые дотнетчики будут использовать обычный массив и линейный поиск? Внизу там кто-то выразил подобную мысль. Если же твой ответ "нет," то можно узнать что такого ужасного делают в своем коде джависты и дотнетчики чего бы С++ программисты никогда бы не сделали? Конкретные примеры а не голословность одну, плиз.
Имхо ты загнул тут. Чтобы писать на Джаве или Шарпе неэффективный код, это надо постораться. А вот в плюсах пожалуйста! Верни к примеру тяжелый контейнер из функции или создай неявно какой-нибудь временной объект. Такого уродского кода как на плюсах мне не приходилось поддерживать. Впрочем я не виню язык — сам язык мне нравится. Я виню конкретные руки которые, не исключенно, могут вот так разглогольствовать на форумах.
A>За последние 10 лет, я не помню случая когда мне понадобилось использовать хитрый алгоритм или структуру данных.
А какие сложные алгоритмы и структуры данных ты хочешь использовать? Все стандартные структуры данных уже написаны, есть и в СТЛ и в дот нете. Бери и пользуйся. А большего и не надо для большинства задач. Так что я не понимаю некоторых заявлений что дотнетчики пишут неэффективный код. Программирование-то от языка не зависит.
Здравствуйте, alex_public, Вы писали:
IT>>Это хорошо. А второй, который shared? _>shared_ptr/weak_ptr естественно добавляет по мелочи относительно голых указателей, но их соответственно и употребляют взамен не голых указателей, а тоже нетривиальных велосипедов не попадающих под RAII. Так что никакого провала в производительности при переходе с древнего велосипедного C++ на современный нет. А безопасность при этом становится гарантированной компилятором, как и в управляемых языках. Только эффективнее. )))
Тут явно наглая ложь. Никакой безопасности относительно указателей (ссылок) не даёт ни C++ ни C#/.NET. Утечки одинаково эффективно можно реализовать и там и там — у всех свои особенности. Плюс в C++ в том — что там где не нужно — ненужные велосипеды можно не использовать, а использовать например голые указатели, чего не скажешь об "управляемых" средах.
Что на практике? Под флагом секурности исключительно все браузеры переходят на многопроцессную модель, хотя в 90% случаев — это эффективный способ прикрыть свою несостоятельность своего кода и своих убогих GC (как в V8 например). Rust? Servo? они пошли той же дорожкой. Нафиг. Но и .net тут противопоставить нечего — с этими задачами он не способен справиться на уровне C++. Это так, на примерах из жизни.
IT>>И сколько ещё всяких разных подпорок и затычек нужно для себя открыть?
KP>Если очень хочется писать тормозные и прожорливые корпоративные приложения, в которых главное решить задачу, а "память и алгоритм имеют низкую значимость" (С), то лучше открыть для себя .NET или JVM. Именно это я и утверждал изначально
Сударь, это голословность! Потрудитесь привести конкретные примеры.
Корчое не тем вы меряетесь.
Равных .NET или Java на серверах... ммм... приложений — нет. Понятно, что всегда можно найти узконаправленные задачи, где бы C++ себя показал. Но в целом, важны не только критерии теоретического перфоманса, но и потребности практического саппорта.
Я вот сегодня случайно помогал восстанавливать работоспособность сайта на PHP — одна умелая строчка с error_reporting(0) и @xxx конструкции сделали из пяти минутной задачи — часовую.
Хотя конечно настройка IIS в этом смысле тоже доставляет, но .NET и ASP.NET тут совсем не причём.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, roro, Вы писали:
R>>Здравствуйте, Grundik2, Вы писали:
G>>>Хочу поиграться с чем-нибудь, чтобы компилилось сразу в native код. Аналог C++'са, но не слишком экзотическое, малоизвестное или вымирающее. На ум приходит только D и Rust. Что порекомендуете?
R>>Аналогов С++ имхо нет.
M>Чем Ada не вариант? Если брать стандарт 2012 года? Или ее диалект SPARK?
С++ золотой молоток под все виды задач, бешеная производительность и лихая езда по памяти.
Здравствуйте, kaa.python, Вы писали:
C>>Я тут пишу клиент для Amazon S3 на Rust, причём у меня задача сделать его офигительно параллельным. Пока получается очень неплохо, по сравнению с предыдущей версией на С++. KP>А тебя не утомляет каждый раз переписывать код, после того как в очередной версии все внезапно поменяли? Или ты сидишь на ветке из Git?
Я пока на 0.6 сижу, который в MacPorts лежал.
KP>Да, а вот теперь реально интересующий меня вопрос. Ты что используешь в качестве сетевого уровня? Текущая версия из Rust, мягко говоря, не завершена.
Прикрутил libcurl. Заодно разобрался с ARC и разделяемыми ресурсами
Здравствуйте, alex_public, Вы писали:
C>>С++1x тоже очень неплох, но сейчас слишком не хватает нормальной параллельности. Если на неё пофиг, то всё вполне ОК. _>А что подразумевается под нормальной параллельностью? Мне правда интересно. )
Максимальный контроль компилятора над используемыми данными и изоляция данных между потоками.
Здравствуйте, gandjustas, Вы писали:
G>Средний ноут, в том числе ультрабук, имеет 2-4 гб памяти, которые толком занять нечем. Какой смысл для пользователя от экономии 100мб?
N>>На планшетах тем более ресурс, никто не хочет жить на зарядке. G>Память? А причем тут зарядка?
Performance bottleneck большинства программ это взаимодействие с иерархией памяти.
Плохой memory layout структур данных, лишние индерекции, лишние аллокации, плохая работа с кэшем — это всё яд для производительности — этим всем грешат "управляемые среды", поэтому и производительность намного хуже.
Требуется в 10 раз больше памяти? — косвенный признак тормозов.
Чтобы делать быстрый код в "управляемых средах" — нужно работать против языка, отказываться от многих средств выражения идей, спускаясь на крайне низкий уровень (даже ниже чем C).
В C++ же производительность и выразительность это не враги — можно делать много слоёв удобных абстракций, которые при компиляции практически исчезнут в пучине inline'ов — Light-weight abstraction programming language.
Andrei Alexandrescu: "The going word at Facebook is that 'reasonably written C++ code just runs fast,' which underscores the enormous effort spent at optimizing PHP and Java code. Paradoxically, C++ code is more difficult to write than in other languages, but efficient code is a lot easier."
Здравствуйте, Cyberax, Вы писали:
_>>А что подразумевается под нормальной параллельностью? Мне правда интересно. ) C>Максимальный контроль компилятора над используемыми данными и изоляция данных между потоками.
Ну изоляция то на уровне компилятора это не так что бы особо круто (это можно и административными мерами решать). Гораздо интереснее как реализован обмен данными между потоками. Лично мне больше всего нравится эрланговская модель и я прямо её и использую в C++.
