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

I>В самой библиотеке есть парсер csv, он, что естественно, не заточен под такие вырожденые сценарии. Реальные csv вполне сносно парсит.

Ну я естественно не претендую на подробное знание библиотеки .net. Так, глянул что куча людей ищет сторонние решения... Раз есть, то кинешь ссылку на него в msdn?

I>Ога, библиотеки ориентированые на принципиально разные области.

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

I>В реальных приложениях процессинг минимум раз в 100 дольше, чем загрузка файла и его парсинг.

Ага, но товарищи пишущие в стиле .net/java и процессинг ведь так же напишут. ))) Ведь за тактами гнаться смысла нет... (c)

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

_>>>Так твой пример же как раз чётко последовательный. В начале read, а потом write. Его нельзя переделать в параллельный даже если очень захочется. )))
I>>Я могу запустить сколько угодно таких операций. Собственно так большей частью и происходит.

_>Да, можешь. И в C++ и в C#. И в обеих реализациях получишь некорректный код. Если конечно не вставишь какую-то синхронизацию в async_read. Но это уже другая история и опять же доступно в обеих реализациях.

Это вся та же история.

I>>Пока что не придумали хорошего способа поместить всю базу данных в локальную переменную со всеми таблицами, колонками и строчками.

_>Агааа. И ещё интересно зачем это в базах данных придумали такую странную вещь, как транзакции... )

покажи кодом:

var value = readAsyncFromDatabase();

writeAsyncToDatabase(next(value));

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

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

G>>Это чтобы семантика соответствовала.

_>Ну т.е. в самой библиотеки .net нет ничего с нужной семантикой... )
Конечно, парсить 1000 мб чисел предельно тупым методом — далекая от реальности задача.
Парсить хотябы одну строку с учетом локали — предельно практическая. Еще во времена писания на делфях я сталкивался с такой проблемой и там адекватного решения не было.

G>>Какой смысл мерить время работы функции int.Parse, которая учитывает локальные настройки с рукопашным парсером?
_>Потому что тут мы сравниваем библиотеки, а не языки.
Дык библиотеки проектируются под задачи.
Я понимают что задача спирита генерировать сверхбыстрые примитивные парсеры. Задача .net — облегчать практическую разработку.


G>>Но тогда и сложность решения будет другая. Ты ведь как обычно придумал пример, который не является даже близко похожим на реальную задачу.
G>>Лучше покажи парсеры json и xml.

_>Ха, вообще говоря то, чем мы сейчас тут с тобой развлекались — это было по сути написание парсера csv формата (собственно если ограничиться числами, то это в точности он и был). А csv — это один из самых популярных форматов для данных. Экспорт/импорт в него есть и в Офисе и во всех база данных (и там как раз бывают не только мегабайтные, но и гигабайтные файлы) и ещё много где. Так что может это ты у нас не в курсе реальных задач? )))
Что-то я на практике csv видел только когда на стороне источника данных не было толковой сериализации в xml\json.
Я тебя расстрою, но же лет 10 или больше CSV для практических задач применяется мало. В нем нет ни структуры, ни информации о типах и расширяемость хромает. Поэтому в 99,99% случаев взаимодействие делается на xml\json.

Если же появится ситуация, где будет много CSV данных, то я просто загружу их в СУБД и буду отчеты по ней Excel_ем строить. Вообще ни строчки не напишу.
Так что далека твоя задача от практики очень далека.



_>Кстати, масштаб потребности можно легко увидеть введя в гугле например "csv .net" — т.к. в самой стандартной библиотеке решения нет, то инет переполнен вариантами. Ну а с помощью Boost'a полноценный csv парсер пишется в 3 строки, причём он ещё будет намного быстрее всех этих сторонних .net библиотек.
Linq2csv придумали ооооочень давно. Но даже его совершенно тупо используют чтобы заливать файлы в базу. Это можно вообще без кода делать.

Кстати глянь по нему доку: http://www.codeproject.com/Articles/25133/LINQ-to-CSV-library
Как долго такое на spirit будешь делать?

G>>да-да. парсить 100мб чисел на мобильном устройстве — очень актуально.

_>Да какая разница какой объём.
Огромная.

_>Даже если 100Кб, он всё равно будет тратить в 10 раз больше процессорного времени.
Относительное быстродействие не интересует. Не бывает "медленных" программ, бывают "недостаточно быстрые".
.NET код в 3 строки на 100кб отработает за 2,5 мс. Это достаточно быстро.
Кстати ты забыл что в отличие от компа в устройстве не будет такого кеша диска и тебе придется уже не парсинг оптимизировать, а чтение.


_>Соответственно при постоянном пользование таким кривым софтом, время жизни от аккумулятора заметно уменьшается. Представляю сколько бы жили смартфоны, если например все браузерные движки были написаны в стиле java/.net...
Как связаны браузерные движки и парсинг 100мб чисел?

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

I>>В самой библиотеке есть парсер csv, он, что естественно, не заточен под такие вырожденые сценарии. Реальные csv вполне сносно парсит.

_>Ну я естественно не претендую на подробное знание библиотеки .net. Так, глянул что куча людей ищет сторонние решения... Раз есть, то кинешь ссылку на него в msdn?

http://msdn.microsoft.com/en-us/library/microsoft.visualbasic.fileio.textfieldparser.aspx

I>>Ога, библиотеки ориентированые на принципиально разные области.

_>Согласен. Но если ты следил за темкой, то знаешь, что идею посравнивать эти библиотеки предложил совсем не я... )

А вроде как ты.

I>>В реальных приложениях процессинг минимум раз в 100 дольше, чем загрузка файла и его парсинг.

_>Ага, но товарищи пишущие в стиле .net/java и процессинг ведь так же напишут. ))) Ведь за тактами гнаться смысла нет... (c)

Ну да, а база данных чудом узнает, что к ней обращаются из С++ и начнет работать в 10 раз быстрее.

Я, если что, примерно 10 лет занимался софтом, который ближе всего похж на САПР, там этого csv и похожих форматов девать было некуда. Так что если хочешь меня повеселить, валяй.

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

Что-то я смотрю мы уже на второй круг пошли в дискуссии, а повторять одно и тоже утомляет... Вроде бы же выяснили уже, что при корректном внешнем (относительно наших библиотечных функций) асинхронном коде всё работает одинаково нормально и в C++ и в C# (только тут надо ещё и переписать библиотечные функции, расставив await и async). А при некорректном внешнем коде будет опять же одинаково глючить как в C++, так и в C#. Рассмотрели это всё, в том числе и на примерах, и пошли дальше. А сейчас ты снова это же самое начинаешь по второму кругу? )))

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

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

Ну так а в библиотеке C++ есть и такое решение. Т.е. имеем и то и то. В отличие от...

G>Что-то я на практике csv видел только когда на стороне источника данных не было толковой сериализации в xml\json.
G>Я тебя расстрою, но же лет 10 или больше CSV для практических задач применяется мало. В нем нет ни структуры, ни информации о типах и расширяемость хромает. Поэтому в 99,99% случаев взаимодействие делается на xml\json.

Ага, ага. ) Расскажи это финансистам, инженерам, учёным и т.п. ))) Им будет любопытно узнать новые для них слова. )))

G>Если же появится ситуация, где будет много CSV данных, то я просто загружу их в СУБД и буду отчеты по ней Excel_ем строить. Вообще ни строчки не напишу.
G>Так что далека твоя задача от практики очень далека.

Ну правильно, идея о том что может самим понадобится написать эту самую СУБД, программисту .net видимо не может прийти в голову... )))

G>Кстати глянь по нему доку: http://www.codeproject.com/Articles/25133/LINQ-to-CSV-library
G>Как долго такое на spirit будешь делать?

Ага... Я смотрю великолепной библиотеки .net уже не хватает, приходится лезть в сторонние...

G>Относительное быстродействие не интересует. Не бывает "медленных" программ, бывают "недостаточно быстрые".
G>.NET код в 3 строки на 100кб отработает за 2,5 мс. Это достаточно быстро.
G>Кстати ты забыл что в отличие от компа в устройстве не будет такого кеша диска и тебе придется уже не парсинг оптимизировать, а чтение.

Ужас какая ересь. ) Если одна и та же задача выполняется при полной загрузке процессора одним кодом за время N, а другим за 10*N, то это значит что второй дико неэффективно расходует аккумулятор. И совершенно не важно что разница в реакции софта будет незаметна для пользователя — энергия при этом тратится несравнимая.

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

I>http://msdn.microsoft.com/en-us/library/microsoft.visualbasic.fileio.textfieldparser.aspx

О, VB... ))) Понятно почему у некоторых проблемы с его нахождением)))

I>А вроде как ты.

Не, это gandjustas порадовал нас мыслью, что стандартная библиотека .net мощнее стандартной библиотеки C++ + boost. ))) А я всего лишь предложил показать это на примерах. На которых естественно оказалась обратная ситуация.

I>Я, если что, примерно 10 лет занимался софтом, который ближе всего похж на САПР, там этого csv и похожих форматов девать было некуда. Так что если хочешь меня повеселить, валяй.

Ну настоящий профи может и на кривом инструменте нормальный код писать. Но как мы видим в основном в мире java и .net процветают совсем другие настроения. Типа "во имя закона Мура". )))

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

_>Что-то я смотрю мы уже на второй круг пошли в дискуссии, а повторять одно и тоже утомляет... Вроде бы же выяснили уже, что при корректном внешнем (относительно наших библиотечных функций) асинхронном коде всё работает одинаково нормально и в C++ и в C# (только тут надо ещё и переписать библиотечные функции, расставив await и async). А при некорректном внешнем коде будет опять же одинаково глючить как в C++, так и в C#. Рассмотрели это всё, в том числе и на примерах, и пошли дальше. А сейчас ты снова это же самое начинаешь по второму кругу? )))

У тебя пока не видно решения для случая когда цепочки работают параллельно.
1 вариант сама функция запускает кучу параллельных цепочек
2 вариант — функция запускается в нескольких паралельных цепочках

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

_>Не, это gandjustas порадовал нас мыслью, что стандартная библиотека .net мощнее стандартной библиотеки C++ + boost. ))) А я всего лишь предложил показать это на примерах. На которых естественно оказалась обратная ситуация.

Не, это ты начал утверждать что навроде "нож мощнее вилки", т.е. с++ мощнее C# ?

I>>Я, если что, примерно 10 лет занимался софтом, который ближе всего похж на САПР, там этого csv и похожих форматов девать было некуда. Так что если хочешь меня повеселить, валяй.

_>Ну настоящий профи может и на кривом инструменте нормальный код писать. Но как мы видим в основном в мире java и .net процветают совсем другие настроения. Типа "во имя закона Мура". )))

Это миф. Единственно где сливает дотнет и джава, это числодробилки и низкоуровневые операции, в ядро или драйвер не то что GC, даже половину фич С++ не всунешь. Всё.
А вот, скажем, новый компилер шарпа писаный на шарпе рвёт в хлам старый компилер шарпа писаный на плюсах. Странно, да ?
Числодробилок раз два и обчелся. А всё остальное упирается в алгоритмы или ввод вывод.

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

Что характерно, менеджед версию на Скале написал какой то дедушка где то за 6 часов, используя всякие лямбды и паттерн-матчинги. Собтсвенно 80% код это паттерн-матчинг.
Щас у индейцев романтический период — взяли декомпиленый вариант и портируют его на С++ и пытаются угадать, где их обманул декомпилер. Ну и менеджмент памяти пишут специально под этот алгоритм. В скале всё просто — все само освобождается. А в с++ этот вариант не проходит — надо руками-руками-руками, а то выхлоп от скалы если в лоб реализовать, дает кучку циклических ссылок.

Теперь самое интересное — дедушка взял и заимпрувил свою версию, при чем напрочь поменял алгоритм. Потратил еще где то день работы, перформанс вырос вдвое.
Общий расклад такой — на небольших деревьях С++ работает где то в 100 раз быстрее, но вот с реальными данными как то не справляется

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

I>У тебя пока не видно решения для случая когда цепочки работают параллельно.

I>1 вариант сама функция запускает кучу параллельных цепочек

И на C++ и на C# это не сделать без переписывания нашей библиотечной функции. Ну а с переписыванием понятно что проблем уже нет нигде... )))

I>2 вариант — функция запускается в нескольких паралельных цепочках

На C# это опять же записывается только с переписыванием функции. На C++ это получается автоматически, без переписывания. Но и в том и в другом случае, такой код не является корректным, если в асинхронном хранилище данных не предусмотрена какая-то своя синхронизация. Ну или же ещё будет нормальное если она вообще не требуется (например мы запускаем параллельное скачивание 10 файлов) по условию задачи.

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

I>Не, это ты начал утверждать что навроде "нож мощнее вилки", т.е. с++ мощнее C# ?

Это да, я утверждал такое... И собственно это очевидно так и есть. Т.к. все возможности C# можно повторить на C++, а вот часть возможностей C++ (в основном реализуемых через метапрограммирование или же наоборот на самом низком уровне) на C# повторить невозможно.

Собственно по тому же критерию язык D очевидно мощнее чем C++ (а с C# вообще уже смешно сравнивать было бы)... Правда тут у него только в сторону высокоуровневых вещей развитие, а по низкому уровню у них с C++ одинаковых доступ.

Но это речь была только про сам язык, а не про библиотеки... Встроенные там или сторонние. Если смотреть на библиотеки, то тут тому же D очень не хватает своего Boost'a, не говоря уже о GUI фреймворках и т.п. В общем с библиотеками ситуация совсем другая, чем с языками. И я собственно не собирался их обсуждать, если бы не забавное замечание gandjustas.

I>Это миф. Единственно где сливает дотнет и джава, это числодробилки и низкоуровневые операции, в ядро или драйвер не то что GC, даже половину фич С++ не всунешь. Всё.

Вообще то C++ сейчас уже даже на микроконтроллёры пролез (естественно как следствие роста возможностей МК в мире). ))) И он там заметно удобнее обычного C. Но это так, просто мелкое замечание, а не по поводу главного.

I>А вот, скажем, новый компилер шарпа писаный на шарпе рвёт в хлам старый компилер шарпа писаный на плюсах. Странно, да ?

Это вообще ни о чём не говорит. Современные версии компиляторов C++ тоже делают старые.)))

I>Числодробилок раз два и обчелся. А всё остальное упирается в алгоритмы или ввод вывод.

Как бы это сказать попроще... ) Если бы это было правдой, то у меня на компьютере точно было бы установлено хотя бы несколько модных .net программ (уж за более чем десятилетие должны же были появиться такие). Но из более чем 250 папок в Program Files насколько я помню ни одна не работает через .net. Раньше правда была одна такая мощная папка (Visual Studio), но уже несколько лет как ушёл и с неё. И то это не особо аргумент, т.к. для MS это был скорее их обычный пиар технологии. Так что похоже мифом у нас являются как раз перспективы .net. )))


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

I>Что характерно, менеджед версию на Скале написал какой то дедушка где то за 6 часов, используя всякие лямбды и паттерн-матчинги. Собтсвенно 80% код это паттерн-матчинг.
I>Щас у индейцев романтический период — взяли декомпиленый вариант и портируют его на С++ и пытаются угадать, где их обманул декомпилер. Ну и менеджмент памяти пишут специально под этот алгоритм. В скале всё просто — все само освобождается. А в с++ этот вариант не проходит — надо руками-руками-руками, а то выхлоп от скалы если в лоб реализовать, дает кучку циклических ссылок.

I>Теперь самое интересное — дедушка взял и заимпрувил свою версию, при чем напрочь поменял алгоритм. Потратил еще где то день работы, перформанс вырос вдвое.
I>Общий расклад такой — на небольших деревьях С++ работает где то в 100 раз быстрее, но вот с реальными данными как то не справляется

Забавная история. ) Только вот она как раз в точности подтвердила именно мою мысль, что в руках профи и сомнительный инструмент будет эффективнее чем самый мощный в руках неумехи.

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

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

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

_>Ну так а в библиотеке C++ есть и такое решение. Т.е. имеем и то и то. В отличие от...
Такое есть, а парсинга json и xml нет. Либы для веб-запросов нет. Работы с БД нет.

Ты ща приведешь 100500 примеров таких либ на просторах интернета, но они нифига не совместимы с современным стандартом C++ и между собой. Это значит что придется писать (и поддерживать) тонны plumbing кода в приложении чтобы с ними работать. А если эти либы еще и C-style интерфейс имеют, то становится совсем грустно.


G>>Что-то я на практике csv видел только когда на стороне источника данных не было толковой сериализации в xml\json.
G>>Я тебя расстрою, но же лет 10 или больше CSV для практических задач применяется мало. В нем нет ни структуры, ни информации о типах и расширяемость хромает. Поэтому в 99,99% случаев взаимодействие делается на xml\json.

_>Ага, ага. ) Расскажи это финансистам, инженерам, учёным и т.п. ))) Им будет любопытно узнать новые для них слова. )))
Рассказываю:
0) Самый любимый инструмент финансистов — Excel, к нему через OLDB можно напрямую подключиться. Иногда приходится парсить\генерить xslx файлы, которые внезапно (!) xml.
1) на стороне 1с очень удобно работать с XML
2) Axapta — веб-сервисы
3) SAP — вот тут действительно выставить веб-сервис и обратиться к нему проблема, поэтому появляются csv, но чаще xml.

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



G>>Если же появится ситуация, где будет много CSV данных, то я просто загружу их в СУБД и буду отчеты по ней Excel_ем строить. Вообще ни строчки не напишу.
G>>Так что далека твоя задача от практики очень далека.
_>Ну правильно, идея о том что может самим понадобится написать эту самую СУБД, программисту .net видимо не может прийти в голову... )))
СУБД и так написано немало, зачем еще? Лучше научиться правильно использовать существующие средства, чем писать свои велосипеды.


G>>Кстати глянь по нему доку: http://www.codeproject.com/Articles/25133/LINQ-to-CSV-library
G>>Как долго такое на spirit будешь делать?
_>Ага... Я смотрю великолепной библиотеки .net уже не хватает, приходится лезть в сторонние...
Ты от ответа уходишь.
Когда задача редкая — действительно приходится лезть. Нет смысла требовать от одной либы решения всех проблем. Надо чтобы она решала часто возникающие проблемы.


G>>Относительное быстродействие не интересует. Не бывает "медленных" программ, бывают "недостаточно быстрые".
G>>.NET код в 3 строки на 100кб отработает за 2,5 мс. Это достаточно быстро.
G>>Кстати ты забыл что в отличие от компа в устройстве не будет такого кеша диска и тебе придется уже не парсинг оптимизировать, а чтение.

_>Ужас какая ересь. ) Если одна и та же задача выполняется при полной загрузке процессора одним кодом за время N, а другим за 10*N, то это значит что второй дико неэффективно расходует аккумулятор. И совершенно не важно что разница в реакции софта будет незаметна для пользователя — энергия при этом тратится несравнимая.
И тут снова никого не интересует относительная величина.
Если твоя программа парсит один раз в час 1мб за 3мс вместо 0.3мс, то пользователь это никогда в жизни не заметит.
Если же ты делаешь эту операцию раз в секунду, то гораздо больше батарейки потратится на получение этого 1мб, тем на его парсинг.

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

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

_>Ну правильно, идея о том что может самим понадобится написать эту самую СУБД, программисту .net видимо не может прийти в голову... )))

Кстати вот одному пришло такое в голову, посмотри чем он занимается:

http://ayende.com/blog

Внезапно чувак занимается оптимизацией IO.

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

_> Т.к. все возможности C# можно повторить на C++, а вот часть возможностей C++ на C# повторить невозможно.

Для сферического писькомерства — да, можно сказать "С++ круче", но вам за что деньги платят? За промышленный код, мэйнстрим. И по-моему, вполне очевидно, что нарезка овощей на тёрке (C#) намного быстрее и безопаснее, чем их рубка саблей (С++). Нет никакого "превосходства" С++, если помимо самого алгоритма ты должен держать в голове выкрутасы С++. Про синтаксис вообще молчу — мрак второго уровня (после Перла и Хаскеля).


I>>А вот, скажем, новый компилер шарпа писаный на шарпе рвёт в хлам старый компилер шарпа писаный на плюсах. Странно, да ?
_>Это вообще ни о чём не говорит. Современные версии компиляторов C++ тоже делают старые.)))

Это говорит о том, что несмотря на всякие MSIL/JIT'ы, можно безо всяких хаков, на безопасном языке, ваять серьёзные приложения.


_>Как бы это сказать попроще... ) Если бы это было правдой, то у меня на компьютере точно было бы установлено хотя бы несколько модных .net программ

Этот парадокс я сам не пойму, но пара мыслей есть:
1. Хотя дотнету уже 10 лет, свою "идеальную форму" он обрёл далеко не с первой версии — даже WPF появился совсем недавно. Или вот ORM — давно ли вы открывали DataReader'ы? А как появились ORM, стало намного легче дышать.
2. Чтобы писать хорошие приложения на дотнете, сначала надо стать хорошими прогерами на дотнете, а это время, опыт, инертность, отставание от самого дотнета и т.п. Вот сейчас уже есть значимая масса дотнетчиков, готовых заполонить мэйнстрим.
3. Громадное количество "не-дотнет" приложений живы чисто в силу бизнес-соображений: не будет никто переписывать 1С только потому, что это безопасно и перспективно, "работает — и ладно!".
4. У "бывалых сипиписеров" до сих пор костное мышление "раз на С++ можно сделать задачу на 0.0001 секунд быстрее, буду и дальше лабать свои таймбомбы!". Их не волнует, что они не способны гарантировать "безглючность" любой программы длиннее 10KLOC. Равно как не могут гарантировать поддерживаемость своих "хакатонов" средним программистом — все ж спецы, блин!

Так что да, дотнет как-то не очень резво замещает "нативщину", но прелесть ситуации в том, что дотнет объективно удобнее для написания виндоприблуд, чем "старый, добрый С++ + Win32". Думаю, как только планшетно-мобильный маразм поутихнет, все как миленькие вернутся на десктоп и C#.


_>Забавная история. ) Только вот она как раз в точности подтвердила именно мою мысль, что в руках профи и сомнительный инструмент будет эффективнее чем самый мощный в руках неумехи.

История подтверждает то, что С++ нафик не нужен для мэйнстрима — "средний сферический индус" не способен писать на нём нормальные приложения. Это верно даже безотносительно сравнения с C#. Когда же на сцену выходит дотнет с его мощнейшей библиотекой и безопасным C#, тут вообще думать нечего — любой проект на C#, сделаный даже средней руки прогерами, способен развиваться десятилетиями.

Но возвращаясь к Ди, мне он кажется куда более интересным и перспективным, чем кактус сипипей — он не даром Ди, а не "Скала" — Ди поднял планку понятия "современный язык" так, что весь легаси код сипипи кажется унылым наследием времён фортрана. Да, к С++ можно прикрутить много интересных плюшек, но он так и останется С++ — неизлечимым гибридом ассемблера и ООП. скорее бы он уже RIP...

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

G>Такое есть, а парсинга json и xml нет. Либы для веб-запросов нет. Работы с БД нет.

G>Ты ща приведешь 100500 примеров таких либ на просторах интернета, но они нифига не совместимы с современным стандартом C++ и между собой. Это значит что придется писать (и поддерживать) тонны plumbing кода в приложении чтобы с ними работать. А если эти либы еще и C-style интерфейс имеют, то становится совсем грустно.

Вообще то есть фреймворки, которые так же как и .net пытаются вместить в себя сразу всё. Я бы не сказал что согласен с этим подходом. Множество отдельных специализированных и при этом крайне эффективных библиотек выглядят явно лучше. Но если очень хочется всё сразу в одном пакете, то надо просто взять Qt или wxWidgets. Там и gui и xml и web-запросы и базы данных и ещё дофига всего, интегрированного в единый комплекс.

G>Но ты ведь понимаешь, что имея нормальный язык с нормальной библиотекой программист почти никогда напрямую с xml не сталкивается.

А причём тут программисты то? ) Я писал про обычных пользователей, которые по любому с csv работают. Ну и кстати для программиста csv тоже совсем не плохой формат для табличных данных — у него намного меньше накладных расходов в сравнение с остальными перечисленными.

G>И тут снова никого не интересует относительная величина.
G>Если твоя программа парсит один раз в час 1мб за 3мс вместо 0.3мс, то пользователь это никогда в жизни не заметит.
G>Если же ты делаешь эту операцию раз в секунду, то гораздо больше батарейки потратится на получение этого 1мб, тем на его парсинг.

Так я то писал не про конкретный парсер, а про этот java/c# стиль вообще. Если люди так пишут, то они напишут в этом стиле не только парсер, а вообще всё. И хотя пользователь при этом по прежнему может не замечать разницу в отклике, но расход энергии будет намного больше, т.к. везде будет отъедаться понемногу. Хотя для стационарных компов это никогда не было проблемой, а как раз для них java и .net и создавались. Это сейчас пошёл максимальный уклон в мобильность. И думаю он будет только нарастать с приходом носимых устройств. Кстати, уже и в самой MS сменился вектор с продавливания .net'a на другие технологии. Правда приход мобильных устройств далеко не единственная причина этого (есть и более интересные), но думаю это тоже внесло небольшой вклад. )))

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

E>Для сферического писькомерства — да, можно сказать "С++ круче", но вам за что деньги платят? За промышленный код, мэйнстрим. И по-моему, вполне очевидно, что нарезка овощей на тёрке (C#) намного быстрее и безопаснее, чем их рубка саблей (С++). Нет никакого "превосходства" С++, если помимо самого алгоритма ты должен держать в голове выкрутасы С++. Про синтаксис вообще молчу — мрак второго уровня (после Перла и Хаскеля).

Ну конкретно в нашем случае, у нас не просто область, где может "и C# и C++", а как раз где может только C++. ))) Однако я считаю, что C++ надо использовать не только в таких случаях, но и там где C++ и C# могут работать оба. При условии что мы говорим об IT компаниях (см. в конец сообщения).

>Этот парадокс я сам не пойму, но пара мыслей есть:
>...

Комментарии см. опять же в конце сообщения.

E>Так что да, дотнет как-то не очень резво замещает "нативщину", но прелесть ситуации в том, что дотнет объективно удобнее для написания виндоприблуд, чем "старый, добрый С++ + Win32". Думаю, как только планшетно-мобильный маразм поутихнет, все как миленькие вернутся на десктоп и C#.

1. "С++ + Win32" — это действительно довольно жёстко. А вот как насчёт C++ + Qt или wxWidget? )
2. Переход к мобильности будет только усиливаться — впереди носимые устройства. )))

E>История подтверждает то, что С++ нафик не нужен для мэйнстрима — "средний сферический индус" не способен писать на нём нормальные приложения. Это верно даже безотносительно сравнения с C#. Когда же на сцену выходит дотнет с его мощнейшей библиотекой и безопасным C#, тут вообще думать нечего — любой проект на C#, сделаный даже средней руки прогерами, способен развиваться десятилетиями.

Тут какое-то очень странное понимание мэйнстрима. За ним чётко угадывается так называемый Enterprise, т.е. ПО пишущееся в IT отделах не IT компаний. Там действительно очень востребована возможность использования низкоквалифицированных и хорошо взаимозаменяемых программистов, т.к. это совсем не основное направление компании, а всего лишь один из внутренних сервисов. И как раз в этой области Java и C# наголову сильнее любых других решений. Я кстати с этим никогда не спорил...

Но я бы точно не стал называть Enterprise мэйнстримом. Разве что по количеству строк кода. А так, весь основной софт, окружающий нас, написан в профессиональных IT компаниях, для которых создание ПО главное предназначение. И которые соответственно могут себе позволить держать лучших профессионалов и использовать самые сложные (и при этом соответственно эффективные) инструменты.

E>Но возвращаясь к Ди, мне он кажется куда более интересным и перспективным, чем кактус сипипей — он не даром Ди, а не "Скала" — Ди поднял планку понятия "современный язык" так, что весь легаси код сипипи кажется унылым наследием времён фортрана. Да, к С++ можно прикрутить много интересных плюшек, но он так и останется С++ — неизлечимым гибридом ассемблера и ООП. скорее бы он уже RIP...

Безусловно. У D основная проблема в отсутствие большого сообщества (написавшего бы необходимые библиотеки/инструменты) или же крупной корпорации, толкающей его. При нынешнем развитие его использование ограничено узкими областями, для которых уже написана необходима инфраструктура. И то при этом есть неудобства в следствие отсутствия удобного редактора (с полноценным дополнением и т.п.).

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

E>Нет никакого "превосходства" С++, если помимо самого алгоритма ты должен держать в голове выкрутасы С++. Про синтаксис вообще молчу — мрак второго уровня (после Перла и Хаскеля).
Я бы не стал их на один уровень ставить...
Тем более, что в шарпе фичи тоже постоянно добавляются. То есть "выкрутасы" тоже добавляются. В итоге напрягать голову тоже придётся.

E>2. Чтобы писать хорошие приложения на дотнете, сначала надо стать хорошими прогерами на дотнете, а это время, опыт, инертность, отставание от самого дотнета и т.п. Вот сейчас уже есть значимая масса дотнетчиков, готовых заполонить мэйнстрим.
Так можно просто писать безопасный код или всё-таки нужно "стать хорошим прогером", получить опыт и т.д.? То есть без знания "выкрутасов" и в дотнете никуда?

E>4. Их не волнует, что они не способны гарантировать "безглючность" любой программы длиннее 10KLOC.
А ты можешь?
Сомневаюсь, что это вообще на любом языке возможно.

E>Но возвращаясь к Ди, мне он кажется куда более интересным и перспективным, чем кактус сипипей — он не даром Ди, а не "Скала" — Ди поднял планку понятия "современный язык" так, что весь легаси код сипипи кажется унылым наследием времён фортрана.
Мне вот даже интересно зачем тебе D, если есть такой замечательный С#/дотнет. Они ведь лучше, правда?

E>скорее бы он уже RIP...
Боюсь, что до этого мы не доживём.

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

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

G>>Такое есть, а парсинга json и xml нет. Либы для веб-запросов нет. Работы с БД нет.

G>>Ты ща приведешь 100500 примеров таких либ на просторах интернета, но они нифига не совместимы с современным стандартом C++ и между собой. Это значит что придется писать (и поддерживать) тонны plumbing кода в приложении чтобы с ними работать. А если эти либы еще и C-style интерфейс имеют, то становится совсем грустно.

_>Вообще то есть фреймворки, которые так же как и .net пытаются вместить в себя сразу всё. Я бы не сказал что согласен с этим подходом. Множество отдельных специализированных и при этом крайне эффективных библиотек выглядят явно лучше.
Разве одно другому мешает? Вот в .net часть активно развивающихся компонент вынесли в отдельные либы, доставаемые через NuGet. От этого они не перестали быть частью .NET.

_>Но если очень хочется всё сразу в одном пакете, то надо просто взять Qt или wxWidgets. Там и gui и xml и web-запросы и базы данных и ещё дофига всего, интегрированного в единый комплекс.
Вот в том и проблема C++, то многие библиотеки типа Qt или wxWidgets очень интрузивны. У них свои наборы классов для решения одних и тех же задач, которые причем отличаются от стандартной библиотеки. Чаще всего это касается базовых вещей, типа строк, дат, ввода-вывода итп. Это все ставит крест на преимуществах C++, заставляет писать много plumbing кода.

G>>Но ты ведь понимаешь, что имея нормальный язык с нормальной библиотекой программист почти никогда напрямую с xml не сталкивается.

_>А причём тут программисты то? ) Я писал про обычных пользователей, которые по любому с csv работают.
Обычные пользователи не работают с csv. Вообще.

_>Ну и кстати для программиста csv тоже совсем не плохой формат для табличных данных — у него намного меньше накладных расходов в сравнение с остальными перечисленными.
Ты еще не понял, что мифические "накладные расходы" вообще никого не интересуют?


G>>И тут снова никого не интересует относительная величина.
G>>Если твоя программа парсит один раз в час 1мб за 3мс вместо 0.3мс, то пользователь это никогда в жизни не заметит.
G>>Если же ты делаешь эту операцию раз в секунду, то гораздо больше батарейки потратится на получение этого 1мб, тем на его парсинг.

_>Так я то писал не про конкретный парсер, а про этот java/c# стиль вообще. Если люди так пишут, то они напишут в этом стиле не только парсер, а вообще всё. И хотя пользователь при этом по прежнему может не замечать разницу в отклике, но расход энергии будет намного больше, т.к. везде будет отъедаться понемногу.
Более 95% времени программы находятся в ожидании завершения ввода-вывода. Грамотное использование асинхронности делает perceived performance достаточным для большинства приложений.


_>Хотя для стационарных компов это никогда не было проблемой, а как раз для них java и .net и создавались. Это сейчас пошёл максимальный уклон в мобильность. И думаю он будет только нарастать с приходом носимых устройств.
_>Большая часть заряда батареи мобильных устройств расходуется на сеть и экран, а не на работу процессора.
Это только в случае игрушек может быть актуально то, что ты пишешь.
Но по странному стечению обстоятельств немало игрушек делается на Unity (Mono) из-за кросс-платформенности


_>Кстати, уже и в самой MS сменился вектор с продавливания .net'a на другие технологии.
Ага, именно поэтому MS парнтерится с Xamarin, который позволяет именно на C# писать приложения для любых устройств. надеются что приложения написанные для iPhone и Android взлетят на WP.
А вот с Azure ситуация обратная. Чтобы продать как можно больше облаков надо сделать их пригодными для любых приложений. МС в этом преуспел.

Начал понемногу "D programming language" читать. Местами впечатления неоднозначные. Догадываюсь, что часть вопросов может проясниться со временем, но всё-таки некоторые вещи смущают. Сразу скажу, что плюсы разумеется тоже есть. Просто когда смотришь на "удобную замену С++", то ожидаешь избавления от всех кривостей. И когда находишь там новые, свои собственные неприятные мелочи, то несколько разочаровываешься. Разумеется, часть претензий — это просто от непривычки или "вкусовщина", ещё какая-то часть (наверное) чем-то обьясняется и является разумным компромиссом. Но некоторые вещи понять не могу, возможно, кто-нибудь объяснить.


Не очень понял пример отсюда:
Тот где cast+mutate = UB:

const(int)* p;
int* q = cast(int*)p;
*q = 3;   // undefined behavior

Это не разрешено что ли? Если так, то какой смысл в приведении вообще?
В С++ в этом плане как-то более логично — если кастуешь и модифицируешь "константные" данные, то сам отвечаешь за то реально ли они константные. Или это просто в документации как-то непонятно выразились?


Ну и обьявление указателей мне как-то проще в С++ читать:

// D:
//ptr to const ptr to const int
const(int*)* p;
//const ptr to const ptr to const int
const int** p;
**p = 3; // error

// C:
//ptr to const ptr to const int
const int *const *p;

Приведение типов. Я так понимаю, что на все случаи жизни один каст (cast) предусмотрен? Может в С++ их "многовато", но по моему это удобно. В том смысле, что меньше вероятность случайно что-то не то сделать.


Ещё не очень понял со строками. В С++ долгое время не хватало "raw string literals". В Д они есть, но в виде кучи разных вариантов со своими (местами не очень прозрачными) правилами. Например:

auto a1 = "just a string";
auto a2 = r"raw string\n\r";
auto a3 = `raw string\n\r`;

Плюс строки с задаваемыми разделителями. Правда в качестве "разделителя" может быть только один символ и только из этого списка: "[(<{" (так написано в книге, на самом деле такое тоже работает (q"a123a"), а вот такое уже нет (q"a123a"). Разделители допускают вложение (если честно, то не понял зачем это надо):

auto а5 = q"/test/eee/"; // Error.
auto a6 = q"[]]"; // Error.
auto a7 = q"[[]]"; // OK, a7 = "[]".

Можно задавать разделители из более чем одного символа, но при этом надо разбивать такой литерал на несколько строк (разделители должны быть на разных строках):

auto a1 = q"EOS
Test string
EOS";

Вот так написать нельзя, ну и отступ попал бы в строку:

auto a1 = q"EOS
  Test string
  EOS";

На мой взгляд, это не очень удoбно. В С++ сделали как-то получше, без необходимости строки разрывать и ломать форматирование:

R"delimiter(The String Data \ Stuff " )delimiter"

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

G>Вот в том и проблема C++, то многие библиотеки типа Qt или wxWidgets очень интрузивны. У них свои наборы классов для решения одних и тех же задач, которые причем отличаются от стандартной библиотеки. Чаще всего это касается базовых вещей, типа строк, дат, ввода-вывода итп. Это все ставит крест на преимуществах C++, заставляет писать много plumbing кода.

Да, так и есть, определяют свои. Но в том то всё и дело, что если ставишь такого монстра, то сторонние библиотеки скорее всего не нужны уже будут))) Ну или же обратный вариант — использовать много мелких лёгких библиотек (типа Boost'a, который же не единая библиотека, а просто общий архив разных), которые естественно никаких своих новых строк и т.п. не определяют. Выбор является личным делом каждого.

Кстати, лично я предпочитаю именно второй способ, т.к. там максимально эффективный код выходит. )

_>>Ну и кстати для программиста csv тоже совсем не плохой формат для табличных данных — у него намного меньше накладных расходов в сравнение с остальными перечисленными.
G>Ты еще не понял, что мифические "накладные расходы" вообще никого не интересуют?

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

G>Более 95% времени программы находятся в ожидании завершения ввода-вывода. Грамотное использование асинхронности делает perceived performance достаточным для большинства приложений.

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

_>>Кстати, уже и в самой MS сменился вектор с продавливания .net'a на другие технологии.
G>Ага, именно поэтому MS парнтерится с Xamarin, который позволяет именно на C# писать приложения для любых устройств. надеются что приложения написанные для iPhone и Android взлетят на WP.
G>А вот с Azure ситуация обратная. Чтобы продать как можно больше облаков надо сделать их пригодными для любых приложений. МС в этом преуспел.

Ты хочешь сказать, что совсем совсем не заметил как MS уже наверное второй год постепенно отворачиваются от .net? ))) Или всё же понимаешь о чём я? )))

Что касается существующих приложений на C# для iPhone/Android и WinPhone, то я думаю это очень гармоничное сочетание по месту на рынке. )))