И все-таки С++ поддерживает работу со «строками, юникод, итераторы и кучу всего еще» в STL.
STL есть в базе, везде и никаких boost-ов для этого не нужно.
Напоминаю: мы сравниваем в первую очередь языки, а не библиотеки. Ну да ладно. Строки — ужасны, итераторы — покажите мне встроенный в язык foreach и yield.
var selectedOrders = from o in context.Orders
where o.Freight > 30
orderby o.ShippedDate descending
select o;
http://localhost:12345/Northwind.svc/Orders?Orderby=ShippedDate&?filter=Freight gt 30
Т.е. нарушение DRY (да, я ленив) при использовании .h-файлов — это нормально? Зачем сначала заставлять разносить объявление и определение, а потом подтыкать это подпорками в IDE?
в STL: wstring, u16string, u32string — все есть, все прекрасно.
Вы, наверное, издеваетесь:
typedef basic_string<char16_t> u16string
Что «прекрасного» есть в std::basic_string? Про Юникод она знает чуть меньше, чем ничего: ни Code Point'ов, ни графем, ни нормализации. Как «класс строка» она нежизнеспособна.
Как вы лихо подменили время в рантайме временем запуска. И нет, прямой корреляции между «размером» приложения и временем запуска нет.
«Поддержка фич в виде библиотек» — это путь PHP. «У нас нет нормального синтаксиса создания массивов, но зато есть функция!». Так и в С++: «язык не поддерживает нормальную работу со строками, Юникод, итераторы и кучу всего еще, но зато у нас есть Boost!».
.h-файл — атавизм, который адепты C/C++ пытаются всячески оправдывать; пользы от них — ни на грош. а мороки — уйма: те же разъезжающиеся сигнатуры, нарушение DRY и вообще масса способов отстрелить разные куски комиссарского тела. (И позвольте, к слову, заметить, что класс «в тысячи строк кода» — явный антипаттерн; но да что уж). Так вот все современные IDE для современных статически типизированных языков умеют замечательно показывать публичный контракт класса вместе с документацией.
Про итератор сказали уже, но вообще странно слышать претензии к простым и понятным .NET'ным итераторам от C++-разработчика с зоопарком begin(), end(), iterator, reverse_iterator и т.д. И вообще — Iterators Must Go.
Лямбды с Dangling Reference'ами прэлэстны, право слово.
Ну и сравнивать библиотечную подпорку для асинхронного программирования в C++ со встроенной в C# поддержкой оного — несколько за гранью
Небесконечное время компиляции, отсутствие .h-файлов, несравнимая по человечности отладка и диагностика ошибок, LINQ в целом и применительно к БД и XML в частности, лямбды, итераторы, async/await, Unicode.
Вот не надо тут про «интероперабельность»: для того, чтобы создать хотя бы подобие оной, лучшие Энтерпрайз Архитекторы создали целое новое семейство стандартов WS-I поверх спецификации SOAP. И даже со всем этим багажом «нельзя просто так взять» и вызвать сколь-нибудь сложный .NET-сервис из Java-клиента (или наоборот) — обязательно что-нибудь где-нибудь да отъедет. И сиди потом разбирайся в хитросплетении многомудрых XML-элементов.
Строго говоря, RRD как продукт в Graphite уже не используется. Там есть свои, со всем причитающимся, — Whisper и Ceres. Про второй не скажу, а первый — концептуально RRD, верно.
Одна из самых крутых штук в Graphite — это его функциональность по «даунсэмплингу» исторических данных. На базе Graphite можно строить компактные хранилища исторических данных на многие годы назад. Например, измерения текущей температуры за последние сутки хранятся с «разрешением» в 1 минуту, данные за прошлый месяц — с «разрешением» в 1 час (т.е. берутся 60 измерений, вычисляется среднее/максимальное/минимальное значение), а за всё остальное время — с «разрешением» в, например, 4 часа.
Напоминаю: мы сравниваем в первую очередь языки, а не библиотеки. Ну да ладно. Строки — ужасны, итераторы — покажите мне встроенный в язык foreach и yield.
Т.е. нарушение DRY (да, я ленив) при использовании .h-файлов — это нормально? Зачем сначала заставлять разносить объявление и определение, а потом подтыкать это подпорками в IDE?
Вы, наверное, издеваетесь:
Что «прекрасного» есть в std::basic_string? Про Юникод она знает чуть меньше, чем ничего: ни Code Point'ов, ни графем, ни нормализации. Как «класс строка» она нежизнеспособна.
«Поддержка фич в виде библиотек» — это путь PHP. «У нас нет нормального синтаксиса создания массивов, но зато есть функция!». Так и в С++: «язык не поддерживает нормальную работу со строками, Юникод, итераторы и кучу всего еще, но зато у нас есть Boost!».
а таки на уровне поддержки его стандартной библиотекой и рантаймом. И вот тут все становится ожидаемо печальным.
.h-файл — атавизм, который адепты C/C++ пытаются всячески оправдывать; пользы от них — ни на грош. а мороки — уйма: те же разъезжающиеся сигнатуры, нарушение DRY и вообще масса способов отстрелить разные куски комиссарского тела. (И позвольте, к слову, заметить, что класс «в тысячи строк кода» — явный антипаттерн; но да что уж). Так вот все современные IDE для современных статически типизированных языков умеют замечательно показывать публичный контракт класса вместе с документацией.
Про итератор сказали уже, но вообще странно слышать претензии к простым и понятным .NET'ным итераторам от C++-разработчика с зоопарком begin(), end(), iterator, reverse_iterator и т.д. И вообще — Iterators Must Go.
Лямбды с Dangling Reference'ами прэлэстны, право слово.
Ну и сравнивать библиотечную подпорку для асинхронного программирования в C++ со встроенной в C# поддержкой оного — несколько за гранью
Небесконечное время компиляции, отсутствие .h-файлов, несравнимая по человечности отладка и диагностика ошибок, LINQ в целом и применительно к БД и XML в частности, лямбды, итераторы, async/await, Unicode.
А вот чем такое можно сделать?
Я думаю, вернее было бы сказать "чистых функций".