Re[4]: с++
От: _NN_ www.nemerleweb.com
Дата: 07.05.19 04:20
Оценка:
Здравствуйте, CEMb, Вы писали:

_NN>>В любом случае это всё костыльные решения в отличии от языков, в которых это делается легко и непринуждённо.

CEM>Идея с Node была взята из Urho3d, где тоже штатная сериализация. Но опять же, я сейчас выскажу свою субъективную мысль: за всю халяву приходится платить. С той же Urho3d после десериализации приходилось писать дополнительные методы, которые приводили объекты в надлежащее состояние. Скорее всего я не прав, но мне думается, что прям универсальных способов сериализации не существует, потому что нужды у всех разные, и всё равно придётся потом после универсального сериализатора подкручивать что-то напильником. Для простых классов данных они будут подходить 100% да, но в жизни или постоянно непростые классы данных, или простых классов данных так много, что бонус от универсальности нивелируется или ещё что, что мешает нашему счастью.
Ну вот, а с рефлексией отпадает необходимость в этом цирке.
А пока во всех больших проектах C++, не одно решение и каждое со своими проблемами.
Один коллега судя по всему достиг в этом деле апогея, генерируя из скрипта вызовы макросов Boost.Hana, которые генерируют шаблоны

_NN>>Всё бы ничего но на это уходит приличное время сборки, т.к. шаблоны не бесплатны.

CEM>Это у вас нехилые такие проекты, если время сборки так критично
Грубый подсчёт с wc показывает порядка миллиона строк кода.
Ах да это ещё не используется буст и библиотеки собраны заранее, а не собираются заново каждую сборку
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[5]: с++
От: CEMb  
Дата: 07.05.19 05:37
Оценка:
Здравствуйте, _NN_, Вы писали:

_NN>Ну вот, а с рефлексией отпадает необходимость в этом цирке.

А как рефлексия помогает? Или как рефлексия помогает так, как не могут помочь шаблоны? Хотя тут наверно надо тонкие частные случаи рассматривать. Или с рефлексией вообще всё сказочно получается?
_NN>А пока во всех больших проектах C++, не одно решение и каждое со своими проблемами.
_NN>Один коллега судя по всему достиг в этом деле апогея, генерируя из скрипта вызовы макросов Boost.Hana, которые генерируют шаблоны
Это сурово

_NN>>>Всё бы ничего но на это уходит приличное время сборки, т.к. шаблоны не бесплатны.

CEM>>Это у вас нехилые такие проекты, если время сборки так критично
_NN>Грубый подсчёт с wc показывает порядка миллиона строк кода.
_NN>Ах да это ещё не используется буст и библиотеки собраны заранее, а не собираются заново каждую сборку
Сейчас посмотрел проект, над которым больше всего работаю, 24 Мб кода(h+cpp), полная пересборка заняла 3 минуты.
Re[6]: с++
От: _NN_ www.nemerleweb.com
Дата: 07.05.19 07:22
Оценка:
Здравствуйте, CEMb, Вы писали:

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


_NN>>Ну вот, а с рефлексией отпадает необходимость в этом цирке.

CEM>А как рефлексия помогает? Или как рефлексия помогает так, как не могут помочь шаблоны? Хотя тут наверно надо тонкие частные случаи рассматривать. Или с рефлексией вообще всё сказочно получается?
Как только появляется возможность получить все данные о типе непосредственно, отпадает необходимость во внешних кодогенераторах.
Одна из проблем всех кодогенераторов это отсутствие интеграции с системой типов C++.
В общем решается много проблем достаточно легко.

_NN>>Ах да это ещё не используется буст и библиотеки собраны заранее, а не собираются заново каждую сборку

CEM>Сейчас посмотрел проект, над которым больше всего работаю, 24 Мб кода(h+cpp), полная пересборка заняла 3 минуты.
А у вас используется C++17 на полную или ещё нет ?
Там CADT, auto на каждом шагу и т.д.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[7]: с++
От: CEMb  
Дата: 07.05.19 08:31
Оценка:
Здравствуйте, _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 в коде. Может я и зануда, но порядка в коде много не бывает
Re[8]: с++
От: _NN_ www.nemerleweb.com
Дата: 07.05.19 11:32
Оценка:
Здравствуйте, 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) и остальные усложнения
В обобщённом коде по другому никак.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[4]: с++
От: serj.e  
Дата: 09.05.19 09:29
Оценка:
A>игры, низкоуровневые утилиты, всякие там видео енкодеры-декодеры? на чем такое пишут кроме как на с++?
В этой подподветке речь шла за ассемблер
Re[2]: с++
От: serj.e  
Дата: 09.05.19 10:02
Оценка:
%>Шарп это нечто странное. Лучше с него бежать куда угодно, а не именно возвращаться в c++.
Вот тоже ровно так же думал совсем недавно, не притрагиваясь к шарпу с 2006-го. И тут вдруг возникла необходимость написать проектик. Что могу сказать: шарп за эти годы настолько улучшился, а .net оброс столь крутыми и при этом удобными в использовании наворотами, что с точки зрения технологичности (не путать с дешевой популярностью) я сейчас в некоторых нишах не вижу ему конкурентов от слова совсем. Для быстро-стартапного набрасывания коммуникационной безвебовой миддлвари он оказался гораздо интереснее в использовании, чем та же нода, да и пересесть труда не составляет, т.к. все идиомы асинхронности в ноде спионерены именно из мира дотнета. A принимая во внимание отвязку от винды (.net core), перевод в opensource и высочайшую активность в сообществе разработки платформы, тотальную стандартизацию в ECMA, и что еще важнее в реальном мире, dick moves по отношению к Java–сообществу со стороны Oracle, по-моему будущее дотнета выглядит весьма перспективным.

Что казается именно веб-backend'ов — то тут ничего не скажу, не пробовал. Но ходят слухи, что да, всё очень жирно-корпоративно и церемониально.
Re[3]: с++
От: % Австралия жж
Дата: 09.05.19 23:17
Оценка:
Здравствуйте, serj.e, Вы писали:

SE>%>Шарп это нечто странное. Лучше с него бежать куда угодно, а не именно возвращаться в c++.

SE>Вот тоже ровно так же думал совсем недавно, не притрагиваясь к шарпу с 2006-го. И тут вдруг возникла необходимость написать проектик. Что могу сказать: шарп за эти годы настолько улучшился, а .net оброс столь крутыми и при этом удобными в использовании наворотами, что с точки зрения технологичности (не путать с дешевой популярностью) я сейчас в некоторых нишах не вижу ему конкурентов от слова совсем. Для быстро-стартапного набрасывания коммуникационной безвебовой миддлвари он оказался гораздо интереснее в использовании, чем та же нода,
Может потому, что в данном случае нод- это есть кактус? Го, питон, эрланг и т.д.
Re[2]: с++
От: Skorodum Россия  
Дата: 10.05.19 10:19
Оценка:
Здравствуйте, _NN_, Вы писали:

_NN>Язак сегодня это капля в море других технологий.

_NN>Достаточно быть готовым расширять кругозор и не принимать иные решение в штыки, и можно научиться работать с практически любым языком.
Это верно если работа уже есть, рекрутерам же и HR нужны ключевые слова в резюме. Да и не начальники готовы ждать условные 3-4 месяца.
Re[8]: с++
От: Skorodum Россия  
Дата: 10.05.19 10:21
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Конечно другое. Софт для юбера по всем параметрам интереснее нудятины в драйверах дисков, а тем паче в антивирусе.

Все интересное в Убере уже, скорее всего, написано.
Re[9]: с++
От: Ночной Смотрящий Россия  
Дата: 10.05.19 10:40
Оценка:
Здравствуйте, Skorodum, Вы писали:

НС>>Конечно другое. Софт для юбера по всем параметрам интереснее нудятины в драйверах дисков, а тем паче в антивирусе.

S>Все интересное в Убере уже, скорее всего, написано.

Чего, серьезно?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[4]: с++
От: serj.e  
Дата: 10.05.19 12:02
Оценка: +2 -1
%>Может потому, что в данном случае нод- это есть кактус? Го, питон, эрланг и т.д.

%>Го
Го? Серьезно? Сишечка со сборщиком мусора и зелеными потоками? Не, я понимаю, что и на нём можно написать, и даже с отличными эксплуатационными характеристиками, но писанины всё же выйдет в разы больше, чем на шарпе. К тому же, под ту задачу не я выбирал шарп, а шарп меня: взят он был, так как по условиям задачи нужен был довольно плотный interop с виндовым миром. Приятственность написания асинхронного сетевого кода и колоссальный прогресс шарпа/дотнета за последние 10 лет обнаружились уже в процессе.

%>питон
Вот сразу за борт. Без объяснения причин.

%>эрланг
Годно. Дорасту до задач калибра British Telecom — попробую. Пока что оверкилл.
Re[5]: с++
От: % Австралия жж
Дата: 10.05.19 12:25
Оценка: +2 -3
Здравствуйте, serj.e, Вы писали:

SE>%>Может потому, что в данном случае нод- это есть кактус? Го, питон, эрланг и т.д.


SE>%>Го

SE>Го? Серьезно? Сишечка со сборщиком мусора и зелеными потоками? Не, я понимаю, что и на нём можно написать, и даже с отличными эксплуатационными характеристиками, но писанины всё же выйдет в разы больше, чем на шарпе. К тому же, под ту задачу не я выбирал шарп, а шарп меня: взят он был, так как по условиям задачи нужен был довольно плотный interop с виндовым миром. Приятственность написания асинхронного сетевого кода и колоссальный прогресс шарпа/дотнета за последние 10 лет обнаружились уже в процессе.

SE>%>питон

SE>Вот сразу за борт. Без объяснения причин.

Винда, асинхронный сетевой код, интероп с вендовым миром? Это ж какой-то содом. Питон бы отлично справился- но выбор ОС несколько странный.

SE>%>эрланг

SE>Годно. Дорасту до задач калибра British Telecom — попробую. Пока что оверкилл.
Вырасти из винды сначала
Re[3]: с++
От: _NN_ www.nemerleweb.com
Дата: 10.05.19 18:31
Оценка:
Здравствуйте, Skorodum, Вы писали:

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


_NN>>Язак сегодня это капля в море других технологий.

_NN>>Достаточно быть готовым расширять кругозор и не принимать иные решение в штыки, и можно научиться работать с практически любым языком.
S>Это верно если работа уже есть, рекрутерам же и HR нужны ключевые слова в резюме. Да и не начальники готовы ждать условные 3-4 месяца.
Согласен, поиск работы через рекрутеров это совсем другое, там смотрят на ключевые слова и по ним делают выводы.

  LinkedIn
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[4]: статистика
От: Vetal_ca Канада http://vetal.ca
Дата: 10.05.19 20:40
Оценка:
Здравствуйте, a7d3, Вы писали:

A>Просто 80-90% подающих резюме на вакансию вообще неспособны писать программный код. Вполне типичная ситуация в Штатах и других «развитых» государствах.


Это в крупные конторы.

В мелкие процент "незомби" — 1-2%
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.