Здравствуйте, CEMb, Вы писали:
_NN>>В любом случае это всё костыльные решения в отличии от языков, в которых это делается легко и непринуждённо. CEM>Идея с Node была взята из Urho3d, где тоже штатная сериализация. Но опять же, я сейчас выскажу свою субъективную мысль: за всю халяву приходится платить. С той же Urho3d после десериализации приходилось писать дополнительные методы, которые приводили объекты в надлежащее состояние. Скорее всего я не прав, но мне думается, что прям универсальных способов сериализации не существует, потому что нужды у всех разные, и всё равно придётся потом после универсального сериализатора подкручивать что-то напильником. Для простых классов данных они будут подходить 100% да, но в жизни или постоянно непростые классы данных, или простых классов данных так много, что бонус от универсальности нивелируется или ещё что, что мешает нашему счастью.
Ну вот, а с рефлексией отпадает необходимость в этом цирке.
А пока во всех больших проектах C++, не одно решение и каждое со своими проблемами.
Один коллега судя по всему достиг в этом деле апогея, генерируя из скрипта вызовы макросов Boost.Hana, которые генерируют шаблоны
_NN>>Всё бы ничего но на это уходит приличное время сборки, т.к. шаблоны не бесплатны. CEM>Это у вас нехилые такие проекты, если время сборки так критично
Грубый подсчёт с wc показывает порядка миллиона строк кода.
Ах да это ещё не используется буст и библиотеки собраны заранее, а не собираются заново каждую сборку
Здравствуйте, _NN_, Вы писали:
_NN>Ну вот, а с рефлексией отпадает необходимость в этом цирке.
А как рефлексия помогает? Или как рефлексия помогает так, как не могут помочь шаблоны? Хотя тут наверно надо тонкие частные случаи рассматривать. Или с рефлексией вообще всё сказочно получается? _NN>А пока во всех больших проектах C++, не одно решение и каждое со своими проблемами. _NN>Один коллега судя по всему достиг в этом деле апогея, генерируя из скрипта вызовы макросов Boost.Hana, которые генерируют шаблоны
Это сурово
_NN>>>Всё бы ничего но на это уходит приличное время сборки, т.к. шаблоны не бесплатны. CEM>>Это у вас нехилые такие проекты, если время сборки так критично _NN>Грубый подсчёт с wc показывает порядка миллиона строк кода. _NN>Ах да это ещё не используется буст и библиотеки собраны заранее, а не собираются заново каждую сборку
Сейчас посмотрел проект, над которым больше всего работаю, 24 Мб кода(h+cpp), полная пересборка заняла 3 минуты.
Здравствуйте, CEMb, Вы писали:
CEM>Здравствуйте, _NN_, Вы писали:
_NN>>Ну вот, а с рефлексией отпадает необходимость в этом цирке. CEM>А как рефлексия помогает? Или как рефлексия помогает так, как не могут помочь шаблоны? Хотя тут наверно надо тонкие частные случаи рассматривать. Или с рефлексией вообще всё сказочно получается?
Как только появляется возможность получить все данные о типе непосредственно, отпадает необходимость во внешних кодогенераторах.
Одна из проблем всех кодогенераторов это отсутствие интеграции с системой типов C++.
В общем решается много проблем достаточно легко.
_NN>>Ах да это ещё не используется буст и библиотеки собраны заранее, а не собираются заново каждую сборку CEM>Сейчас посмотрел проект, над которым больше всего работаю, 24 Мб кода(h+cpp), полная пересборка заняла 3 минуты.
А у вас используется C++17 на полную или ещё нет ?
Там CADT, auto на каждом шагу и т.д.
Здравствуйте, _NN_, Вы писали:
_NN>>>Ну вот, а с рефлексией отпадает необходимость в этом цирке. CEM>>А как рефлексия помогает? Или как рефлексия помогает так, как не могут помочь шаблоны? Хотя тут наверно надо тонкие частные случаи рассматривать. Или с рефлексией вообще всё сказочно получается? _NN>Как только появляется возможность получить все данные о типе непосредственно, отпадает необходимость во внешних кодогенераторах. _NN>Одна из проблем всех кодогенераторов это отсутствие интеграции с системой типов C++. _NN>В общем решается много проблем достаточно легко.
Т.е, например, MFC-шный CObject решает эту проблему? У них, насколько помню, классы содержат информацию о себе.
А RTTI не помогает (никогда не пользовался)
Ну, по идее, MFC::CObject или Java::Object решают эту проблему (легко?). Стало быть, на плюсах можно, скорее всего просто, сделать библиотеку, которая будет решать проблему?
Я там ссылку на хабр приводил, там человек что-то такое сделал.
_NN>>>Ах да это ещё не используется буст и библиотеки собраны заранее, а не собираются заново каждую сборку CEM>>Сейчас посмотрел проект, над которым больше всего работаю, 24 Мб кода(h+cpp), полная пересборка заняла 3 минуты. _NN>А у вас используется C++17 на полную или ещё нет ? _NN>Там CADT, auto на каждом шагу и т.д.
Мне стыдно, но рабочие проекты у нас на старых сях. На самом деле, их начинали в прошлом веке, используя библиотеки, которые уже никто не поддерживает, но которые были настолько удобные, что переписать их за раз не получится. Так что мне не стыдно Было бы время... И дело не столько во времени, я готов переписать 24 мега кода, просто это же рабочий процесс... там адово количество функционала. Никто не согласится оплатить время по переводу и, самое главное, тестированию всего это хозайства… А все последние нововведения я уже старался делать в новом стиле, используя ATL в качестве заменителя std. Всё новое начинается на новых плюсах.
auto. я в обычном коде не использую auto. auto используется только по назначению, в шаблонах-шаблонах, когда прокинуть тип очень сложно.
когда речь идёт, например, об итераторах (ну, типа, ".. долго писать <vector<shared_ptr<mytype<…>>::const_iterator, для это придумали же auto!.." ) я использую using-и, определяя тип элемента, и его контейнеры и итераторы. Чёткой системы у меня, увы, нет, она родилась по ходу дела, был бы рад почитать, кто как делает. у меня как-то так:
using Item = …;
using Items = vector<Item>;
using ItemI = Items::iterator;
using ItemCI = Items::const_iterator;
//…
Items items;
for (ItemI it : items)
//…
В коде всё хорошо видно глазами. В случае, если мне надо поменять контейнер или скопипастить заменить один исходный класс на другой, я это делаю в одном месте.
Я много видел, как народ использовал auto в коде, потом их type resolving в голове не совпадал с type resolving в компиляторе, и возникали неприятные ошибки. Было смешно даже, один человек поленился написать int, написал auto, ждал int в голове, а получил unsigned int в коде. Может я и зануда, но порядка в коде много не бывает
Здравствуйте, CEMb, Вы писали:
CEM>Т.е, например, MFC-шный CObject решает эту проблему? У них, насколько помню, классы содержат информацию о себе. CEM>А RTTI не помогает (никогда не пользовался) CEM>Ну, по идее, MFC::CObject или Java::Object решают эту проблему (легко?). Стало быть, на плюсах можно, скорее всего просто, сделать библиотеку, которая будет решать проблему? CEM>Я там ссылку на хабр приводил, там человек что-то такое сделал.
Легко решает Java или другие языки с интроспекцией типов.
CObject не позволяет взять абсолютно любой тип и узнать какие поля у него внутри и какие функции.
CEM>В коде всё хорошо видно глазами. В случае, если мне надо поменять контейнер или скопипастить заменить один исходный класс на другой, я это делаю в одном месте. CEM>Я много видел, как народ использовал auto в коде, потом их type resolving в голове не совпадал с type resolving в компиляторе, и возникали неприятные ошибки. Было смешно даже, один человек поленился написать int, написал auto, ждал int в голове, а получил unsigned int в коде. Может я и зануда, но порядка в коде много не бывает
Бывает, поэтому есть и decltype(auto) и остальные усложнения
В обобщённом коде по другому никак.
%>Шарп это нечто странное. Лучше с него бежать куда угодно, а не именно возвращаться в c++.
Вот тоже ровно так же думал совсем недавно, не притрагиваясь к шарпу с 2006-го. И тут вдруг возникла необходимость написать проектик. Что могу сказать: шарп за эти годы настолько улучшился, а .net оброс столь крутыми и при этом удобными в использовании наворотами, что с точки зрения технологичности (не путать с дешевой популярностью) я сейчас в некоторых нишах не вижу ему конкурентов от слова совсем. Для быстро-стартапного набрасывания коммуникационной безвебовой миддлвари он оказался гораздо интереснее в использовании, чем та же нода, да и пересесть труда не составляет, т.к. все идиомы асинхронности в ноде спионерены именно из мира дотнета. A принимая во внимание отвязку от винды (.net core), перевод в opensource и высочайшую активность в сообществе разработки платформы, тотальную стандартизацию в ECMA, и что еще важнее в реальном мире, dick moves по отношению к Java–сообществу со стороны Oracle, по-моему будущее дотнета выглядит весьма перспективным.
Что казается именно веб-backend'ов — то тут ничего не скажу, не пробовал. Но ходят слухи, что да, всё очень жирно-корпоративно и церемониально.
Здравствуйте, serj.e, Вы писали:
SE>%>Шарп это нечто странное. Лучше с него бежать куда угодно, а не именно возвращаться в c++. SE>Вот тоже ровно так же думал совсем недавно, не притрагиваясь к шарпу с 2006-го. И тут вдруг возникла необходимость написать проектик. Что могу сказать: шарп за эти годы настолько улучшился, а .net оброс столь крутыми и при этом удобными в использовании наворотами, что с точки зрения технологичности (не путать с дешевой популярностью) я сейчас в некоторых нишах не вижу ему конкурентов от слова совсем. Для быстро-стартапного набрасывания коммуникационной безвебовой миддлвари он оказался гораздо интереснее в использовании, чем та же нода,
Может потому, что в данном случае нод- это есть кактус? Го, питон, эрланг и т.д.
Здравствуйте, _NN_, Вы писали:
_NN>Язак сегодня это капля в море других технологий. _NN>Достаточно быть готовым расширять кругозор и не принимать иные решение в штыки, и можно научиться работать с практически любым языком.
Это верно если работа уже есть, рекрутерам же и HR нужны ключевые слова в резюме. Да и не начальники готовы ждать условные 3-4 месяца.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Конечно другое. Софт для юбера по всем параметрам интереснее нудятины в драйверах дисков, а тем паче в антивирусе.
Все интересное в Убере уже, скорее всего, написано.
Здравствуйте, Skorodum, Вы писали:
НС>>Конечно другое. Софт для юбера по всем параметрам интереснее нудятины в драйверах дисков, а тем паче в антивирусе. S>Все интересное в Убере уже, скорее всего, написано.
%>Может потому, что в данном случае нод- это есть кактус? Го, питон, эрланг и т.д.
%>Го
Го? Серьезно? Сишечка со сборщиком мусора и зелеными потоками? Не, я понимаю, что и на нём можно написать, и даже с отличными эксплуатационными характеристиками, но писанины всё же выйдет в разы больше, чем на шарпе. К тому же, под ту задачу не я выбирал шарп, а шарп меня: взят он был, так как по условиям задачи нужен был довольно плотный interop с виндовым миром. Приятственность написания асинхронного сетевого кода и колоссальный прогресс шарпа/дотнета за последние 10 лет обнаружились уже в процессе.
%>питон
Вот сразу за борт. Без объяснения причин.
%>эрланг
Годно. Дорасту до задач калибра British Telecom — попробую. Пока что оверкилл.
Здравствуйте, serj.e, Вы писали:
SE>%>Может потому, что в данном случае нод- это есть кактус? Го, питон, эрланг и т.д.
SE>%>Го SE>Го? Серьезно? Сишечка со сборщиком мусора и зелеными потоками? Не, я понимаю, что и на нём можно написать, и даже с отличными эксплуатационными характеристиками, но писанины всё же выйдет в разы больше, чем на шарпе. К тому же, под ту задачу не я выбирал шарп, а шарп меня: взят он был, так как по условиям задачи нужен был довольно плотный interop с виндовым миром. Приятственность написания асинхронного сетевого кода и колоссальный прогресс шарпа/дотнета за последние 10 лет обнаружились уже в процессе.
SE>%>питон SE>Вот сразу за борт. Без объяснения причин.
Винда, асинхронный сетевой код, интероп с вендовым миром? Это ж какой-то содом. Питон бы отлично справился- но выбор ОС несколько странный.
SE>%>эрланг SE>Годно. Дорасту до задач калибра British Telecom — попробую. Пока что оверкилл.
Вырасти из винды сначала
Здравствуйте, Skorodum, Вы писали: S>Здравствуйте, _NN_, Вы писали: _NN>>Язак сегодня это капля в море других технологий. _NN>>Достаточно быть готовым расширять кругозор и не принимать иные решение в штыки, и можно научиться работать с практически любым языком. S>Это верно если работа уже есть, рекрутерам же и HR нужны ключевые слова в резюме. Да и не начальники готовы ждать условные 3-4 месяца.
Согласен, поиск работы через рекрутеров это совсем другое, там смотрят на ключевые слова и по ним делают выводы.
Здравствуйте, a7d3, Вы писали:
A>Просто 80-90% подающих резюме на вакансию вообще неспособны писать программный код. Вполне типичная ситуация в Штатах и других «развитых» государствах.