Здравствуйте, rudzuk, Вы писали:
R>А как будет выглядеть этот код (и асм), если регистровые переменные (i,j,k,z) будут не байтовыми, а в размер регистров cpu (u3232, u64)?
Если компилятор сможет увидеть что нет выходов за пределы буфера то точно также как и с 8 битами:
use std::num::Wrapping;
use std::time::{SystemTime, UNIX_EPOCH};
fn main() {
let nanos = SystemTime::now()
.duration_since(UNIX_EPOCH)
.unwrap()
.subsec_nanos();
let b = nanos as usize;
//dbg!(b);
// начальные переменныеlet s = [10u8; 256];
let (i, j, k) = (Wrapping(b), Wrapping(b), Wrapping(b));
let mut z = Wrapping(b);
// сам кодlet S = |a: Wrapping<usize>| Wrapping(s[a.0 as u8 as usize].into());
z = S(j + S(i + S(z + k)));
//dbg!(z);
std::process::exit(z.0 as i32);
}
Тут приведение к u8 в S() дает такую информацию, если его убрать то снова будут добавлены проверки на выход за границы буфера и пропадет инлайнинг, но зато в рантайме свалится с паникой, а не будет непредсказуемо переполнять буфер как в си.
fk0> Шаблон -- это лишь некоторое правило для компилятора. Он ни к чему не обязывает, в частности к генерации "раздутого кода". fk0>Как им воспользуются, и что из этого получится -- зависит от программиста, а не от шаблонов вообще.
Разумеется. Так-то я то же самое утверждал: нет ничего плохого в шаблонах, а только лишь в неумеренном злоупотреблении оными.
fk0> Простейший пример: попытка сделать самодельный аналог STL-контейнера, например, вектора. fk0>Подход в лоб даст тот самый эффект, что на каждый тип компилятор порождает всё новые инстансы fk0>одних и тех же функций (может быть, даже буквально совпадающих в ассемблере). Если за задачу fk0>возьмётся студент, так наверное и выйдет. Если возьмётся немного более опытный программист, то
Если возьмётся опытный программист, или небольшая группа таковых, то всё будет хорошо. Когда же за дело берутся "цыгане шумною толпою", то получаются нездорово раздутые бинари, как это часто, например, получается у Facebook.
Здравствуйте, zx zpectrum, Вы писали:
fk0>> Простейший пример: попытка сделать самодельный аналог STL-контейнера, например, вектора. fk0>>Подход в лоб даст тот самый эффект, что на каждый тип компилятор порождает всё новые инстансы fk0>>одних и тех же функций (может быть, даже буквально совпадающих в ассемблере). Если за задачу fk0>>возьмётся студент, так наверное и выйдет. Если возьмётся немного более опытный программист, то ZZ>Если возьмётся опытный программист, или небольшая группа таковых, то всё будет хорошо. Когда же за дело берутся "цыгане шумною толпою", то получаются нездорово раздутые бинари, как это часто, например, получается у Facebook.
Совершенно не факт, что дело вообще в шаблонах или в C++. Может там в бинарях ресурсы в виде png картинок.
Здравствуйте, Privalov, Вы писали:
P>Я видел женщин — системных программистов. Большинству мужиков у них учиться и учиться. Я, кстати, тоже у них кое-чему научился.
Здравствуйте, Shmj, Вы писали:
V>>Но я сейчас сижу в GNU/Linux, конкретно в Debian, и вся структура операционки сделана, чтобы создавать проекты для Си и C++. Просто заглядываешь в системные папки и понимаешь, что другим языкам здесь делать нечего, потому что вся их структура заточена под Си и C++.
S>Вы как бы обещаете — Си и C++. На самом деле там только C. Ядро и основополагающие вещи на голом C без бардака, который вносит ++. Что сверх того — то от лукавого.
Ты, как обычно, написать ерунду. Как говорится, программист на фортране напишет программу на фортране на любом языке программирования. Это я про то, что бардак от языка не зависит, в общем случае (если не говорить о каком-нибудь брайнфаке, конечно)
Ты в какой-нибудь линупсовый софт в сорцы смотрел? Gnome, например? Видел там у них GOject? Понимаешь? Гобжект, буагага А как смешно смотреть, как линупсоиды изобретают плюсовые виртуальные функции на таблицах указателей на функцию. Так и представляешь, сколько боли испытали эти люди, пока это всё хоть как-то начинало работать. А казалось бы — взял плюсовый класс, сделал абстрактный интерфейс, отнаследовался, написал реализацию. Компилятор за тебя все таблицы собрал, все по параметрам проверил.. Но нет, это не линупсовый путь, без кактуса в жопе они уже не могут
S>Когда хочется и то и то — это типичный женский подход. Мужик умеет отрезать — выделять главное. А женщина — и то хочу, и чтобы и систему писать, и чтобы классы и все в одном — потому что нет силы характера — не может выбрать главное и отказаться от малозначимого. Мужик может выбрать — если система и скорость — то голый C. Если рюшечки — то Java/C#.
О, а теперь еще и мужской/женский подход решил натянуть
Здравствуйте, lpd, Вы писали:
lpd>Получается: если нужно написать программу хорошо — используйте С;
На чистом C сложно хорошо написать программу. И это будет очень небыстро
lpd>если нужно написать хорошо прикладную программу — C++;
lpd>если нужно написать быстро — Java; если под винду — C#; если программа уже написана, но у вас странные наклонности — Rust/Go/...
Я как-то под андроид писал — там всего ничего, на плюсах за гнднлю бы сделал, а так — пришлось пару месяцев сражаться с этой джавой
С слову, точно также мне нужно было написать на шарпе под вин мобайл прогу. Условия были те же практически — ни с тем ни с другим я до того не работал. С шарпом получилось гораздо быстрее. Это при том, что под андроид я писал чисто локальное приложение, а на шарпе мне нужно было с удалённой БД общаться
Здравствуйте, Shmj, Вы писали:
AG>>Это, конечно же, заблуждение. AG>>Если проект большой, даже средний, и всё на C — его продвижение и поддержка превращаются в nightmare.
S>Вы так говорите, как будто ++ что-то улучшает в этом вопросе. Давайте честно — ++ только усугубляет положение, т.к. дает больший простор для создания бардака, чем всенепременно воспользуются кодо-писатели.
Давайте честно — ты ничего не писал на плюсах. Да и на сишечке тоже вряд ли
Здравствуйте, Shmj, Вы писали:
S>Можно сказать опыт — около 1-2 недели. Переводил библиотеку с С++ на C#, но приходилось только читать и то не очень долго. Второе — это писал небольшую утилиту, по-моему дня на 3 работы.
S>Но и этого хватило чтобы понять насколько глубока кроличья нора
А, вопросов больше не имею
S>Сейчас предлагают мне повысить свой уровень и сделать средней сложности проект — как раз выбор между этими двумя. Есть причина, почему не подходит Java, .Net и Dart.
S>И сейчас больше склонен к выбору C. Тем более что для него есть все библиотеки, практически нет нужды в ++.
Здравствуйте, zx zpectrum, Вы писали:
V>>Когда используешь обобщённое программирование производительность не снижается по сравнению с Си, так как происходит генерация новых функций и классов по шаблону. Зато это позволяет не переписывать код, что не может Си. ZZ>Рассуждения в целом верны, однако есть одно "но". Bloating. Распухание бинаря. Возникает сие явление, понятное дело, не от шаблонизации вообще, а исключительно от неумеренного злоупотребления оной. Многие скажут: ну распухание и распухание, что такого-то, RAM–то в наши времена немеряно. Но-но, охладите пыл, и попробуйте задуматься вот о чём: плотный маленький бинарь имеет гигантское преимущество в сравнении с рыхлым и раздутым в плане промахов по кешу инструкций. Вспоминаем основополагающий текст "RAM больше не RAM", нарастающий год от года отрыв кэша от RAM в скоростях и латентностях, а потом суровую практику, многосотмегабайтные бинарники, раздутые от семиэтажных шаблонов, и сверяемся с циферками кэшей: даже самый медленный третий уровень в наши времена что-то около 20 мегабайт, если не ошибаюсь. Ясен пень, не на один процесс, а на всех.
А можно поподробнее про распухание? А то может оказаться, что кроме распухания происходит и спухание — когда на этапе линковки одинаковый код не дублируется. Далее, с шаблонами можно писать и так, что общий код реализуется в каком-то базовом классе, а параметризуемый — в наследниках, и его с гулкин нос. Если же типы, для которых производится инстанциация — сильно разные, и действительно пучат бинарь — то какой-тогда магией в сишечке делают плотный маленький бинарь?
А многосотмегабайтные бинарники (ты, кстати, о чем) — они обычно от того, что туда засунуто до черта функционала. Сишечные бинарники будут сравнимых размеров
ZZ>Было дело, QNX хвастался тем, что их плотное минималистичное ядро целиком влезает в L2–кэш, и это вроде как даёт преимущества не только и не столько в скоростях, сколько в детерминизме, так необходимом в системах реального времени.
Здравствуйте, zx zpectrum, Вы писали:
ZZ>Если возьмётся опытный программист, или небольшая группа таковых, то всё будет хорошо. Когда же за дело берутся "цыгане шумною толпою", то получаются нездорово раздутые бинари, как это часто, например, получается у Facebook.
А ты представляешь, что цыгане могут сделать на чистой сишечке? Подскажу — ничего. Оно у них даже если и скомпилится, то работать не будет
M>А можно поподробнее про распухание? А то может оказаться, что кроме распухания происходит и спухание — когда на этапе линковки одинаковый код не дублируется.
LTO, да-да, понятное дело. А потом какие-нить грамотеи проект разобьют на динамические библиотеки, в которых до черта предкомпилированных специализаций:
а) тюленями
б) оленями
в) пельменями
г) существами, издалека напоминающие людей
д) существами, которые объявили войну
е) сказочными
ж) бродячимим собаками
з) включёнными в эту классификацию
и) бегающими как сумасшедшие
к) бесчисленными
л) нарисованными тончайшей кистью из верблюжьей шерсти
м) прочими
н) разбившими цветочную вазу
о) похожими издали на мух
, и их уже просто так линковочной оптимизацией не выковыряешь.
M>А многосотмегабайтные бинарники (ты, кстати, о чем) — они обычно от того, что туда засунуто до черта функционала. Сишечные бинарники будут сравнимых размеров
Ну тогда покажите мне хоть одну, сравнимую с libcurl по функциональности, http(s)–клиентскую библиотеку на "развесистых" языках (C++, Rust, Swift и т.д.) схожего размера в компилированном виде. Если бы было так, как Вы говорите, то на C уже и embedded не писали бы, и ядро linux. Дело-то не только в человеческой инерции, как это многие пытаются себе представить.
M>И чего? На плюсах такое что, не написать?
Конечно написать. Если за дело возьмётся специально обученная группа высочайшей квалификации. "Цыгане шумною толпою", нанятые по объявлению — не напишут.
M>А ты представляешь, что цыгане могут сделать на чистой сишечке? Подскажу — ничего. Оно у них даже если и скомпилится, то работать не будет
Подскажу — GNU/Linux. Цыганами ведь метафорично можно обозвать не только "Фейсбучную въетнамскую швейную фабрику", но и ГНУтый "базар вместо собора".
Здравствуйте, zx zpectrum, Вы писали:
M>>А можно поподробнее про распухание? А то может оказаться, что кроме распухания происходит и спухание — когда на этапе линковки одинаковый код не дублируется. ZZ>LTO, да-да, понятное дело. А потом какие-нить грамотеи проект разобьют на динамические библиотеки, в которых до черта предкомпилированных специализаций: ZZ>а) тюленями ZZ>б) оленями
... ZZ>о) похожими издали на мух ZZ>, и их уже просто так линковочной оптимизацией не выковыряешь.
Специализации для тюленей, оленей и мух чем-то отличаются? Если нет, то в DLL будет лежать одна версия, просто на неё будут ссылаться разные имена. Если реализации различаются, то каким образом использование чистого C тут поможет?
M>>А многосотмегабайтные бинарники (ты, кстати, о чем) — они обычно от того, что туда засунуто до черта функционала. Сишечные бинарники будут сравнимых размеров ZZ>Ну тогда покажите мне хоть одну, сравнимую с libcurl по функциональности, http(s)–клиентскую библиотеку на "развесистых" языках (C++, Rust, Swift и т.д.) схожего размера в компилированном виде.
Может, такой нет, потому что уже есть libcurl, а дураков просто переписывать, чтобы было на другом языке — нет?
ZZ>Если бы было так, как Вы говорите, то на C уже и embedded не писали бы,
Так в эмбеде никто на C уже и не пишет. Это я тебе говорю, как человек, писавший 5 лет на C++ 11 для эмбеда, говорю. Те либы, которые на сишке — это артефакты эпохи начала нулевых или ранее, когда плюсики не умели в эмбед.
Ещё на чистой сишечке в эмбеде пишут для тех платформ, для которых C++ нет и уже не предвидится, типа MSC-51
ZZ>и ядро linux. Дело-то не только в человеческой инерции, как это многие пытаются себе представить.
Ядро линупс как раз яркий пример человеческой иннерции, которую задал главпингвин, не осиливший плюсики
M>>И чего? На плюсах такое что, не написать? ZZ>Конечно написать. Если за дело возьмётся специально обученная группа высочайшей квалификации. "Цыгане шумною толпою", нанятые по объявлению — не напишут.
Ещё раз — "цыгане шумною толпою", нанятые по объявлению — если на сишечке будут писать — у них оно даже не заведётся, будет по сегфолтам падать, а до релиза дело довести у инвестора денег не хватит
Здравствуйте, zx zpectrum, Вы писали:
M>>А ты представляешь, что цыгане могут сделать на чистой сишечке? Подскажу — ничего. Оно у них даже если и скомпилится, то работать не будет ZZ>Подскажу — GNU/Linux. Цыганами ведь метафорично можно обозвать не только "Фейсбучную въетнамскую швейную фабрику", но и ГНУтый "базар вместо собора".
Ну ты тут в соседнем сообщении написал про "цыган, набранных по объявлениям" — хочешь соврать, что ядро линупса пишут именно такие?
Или таки эти цыгане на самом деле квалифицированные разработчики?
Нашел
Просто у тебя только что цыгане были синонимом неумелых неквалифицированных программистов:
Если возьмётся опытный программист, или небольшая группа таковых, то всё будет хорошо. Когда же за дело берутся "цыгане шумною толпою", то получаются нездорово раздутые бинари, как это часто, например, получается у Facebook.
Может тогда не будем всех и вся называть цыганами?
Кстати, KDE — гораздо более молодой, чем GNOME — написан на плюсах. А работает гораздо приятнее
И да, не хочу тебя сильно травмировать, но основной компилятор GNU — GCC — переписывают на плюсы. Видимо, тащить его на сишечке уже больше нет сил
M>Ну ты тут в соседнем сообщении написал про "цыган, набранных по объявлениям" — хочешь соврать, что ядро линупса пишут именно такие?
Зачем сразу соврать? Нет, не соврать, а подписать под эту шутливую метафору две категории разношёрстной толпы с плавающей квалификацией. У сишной (linux) получается отлично, у плюсовой (FB–клиенты) — какое-то угрёбище. Но да, два примера как-то маловато будет.
M>Кстати, KDE — гораздо более молодой, чем GNOME — написан на плюсах. А работает гораздо приятнее
ХЗ, лично мне нынешний гном гораздо больше нравится. Ну да ладно, в религию не будем углубляться, пустое это.
А если же взять не KDE, а Qt, то да, отличная библиотека. Но заглянув внутрь видим, что плюсы под капотом весьма минималистичны, без тридцатиэтажных шаблонных матов, без метапрограммирования (1) головного мозга.
M>И да, не хочу тебя сильно травмировать, но основной компилятор GNU — GCC — переписывают на плюсы. Видимо, тащить его на сишечке уже больше нет сил
Не травмируешь, я прекрасно это знаю )
(1) Метапрограммирование — отличная концепция, но не тот его сорт, что был "discovered" в противовес "engineered".
Здравствуйте, zx zpectrum, Вы писали:
M>>Ну ты тут в соседнем сообщении написал про "цыган, набранных по объявлениям" — хочешь соврать, что ядро линупса пишут именно такие? ZZ>Зачем сразу соврать? Нет, не соврать, а подписать под эту шутливую метафору две категории разношёрстной толпы с плавающей квалификацией.
Не соврать, а натянуть сову
Если серьезно, то у двух сравнимых по квалификации разношерстных толп разработчиков вероятность довести проект до релиза лично я оцениваю команду плюсовиков как 10 против 1 у сишников. И это ещё гуманная для сишников оценка.
ZZ>У сишной (linux) получается отлично, у плюсовой (FB–клиенты) — какое-то угрёбище. Но да, два примера как-то маловато будет.
Взял очень большое сообщество с одной стороны, взял что-то отдельное с другой — получил подходящие результаты, и вроде даже и не соврал...
M>>Кстати, KDE — гораздо более молодой, чем GNOME — написан на плюсах. А работает гораздо приятнее ZZ>ХЗ, лично мне нынешний гном гораздо больше нравится. Ну да ладно, в религию не будем углубляться, пустое это. ZZ>А если же взять не KDE, а Qt, то да, отличная библиотека. Но заглянув внутрь видим, что плюсы под капотом весьма минималистичны, без тридцатиэтажных шаблонных матов, без метапрограммирования (1) головного мозга.
Видишь ли, плюсы — они разные. В отличие от сишечки, которая всегда одна и та же
M>>И да, не хочу тебя сильно травмировать, но основной компилятор GNU — GCC — переписывают на плюсы. Видимо, тащить его на сишечке уже больше нет сил ZZ>Не травмируешь, я прекрасно это знаю )
Так там что, цыган-обезьян набрали в команду GCC, или что?
ZZ>(1) Метапрограммирование — отличная концепция, но не тот его сорт, что был "discovered" в противовес "engineered".
Здравствуйте, vsb, Вы писали:
vsb>Ничего не мешает по мере усложнения переписать внутренности на C++, если это усложнение вообще будет и если это будет оправдано. ABI всё равно был, есть и всегда будет на C.
Такой хороший аргумент про выбор языка для будущего проекта: fk0> Только вот по мере роста объёма кода, статически типизированные языки >начинают выигрывать. А скриптовые вязнут в отладке.
Повидал уже не мало проектов. Если рассматривать проектную деятельность команды, продукта, то основные обязанности программистов видятся такие:
-узнавать у аналитиков, клиентов их траблы
-фиксить баги
-допиливать фичи
-много разбираться в коде, т.к. плохо документировано и прошлые разработчики ушли
-возможно тестировать
-возможно следить за продом
-возможно заниматься деплоем
-возможно менторить, писать доку, ревьювить код других
...
При живом проекте время и ресурсы на "перепишем-ка ребята на другой язык" никак не наблюдал. И нарастающий техдолг вяжет твои руки, залазиет в мозг, закрывает веки. Что даже простое изменение ты не можешь просто взять и сделать. А сначала нужно много в чём разобраться и ничего своим изменением не сломать.
Если у вас подразумевается небольшой side проектик на месяцок работы на 1 человека, как здесь уже писали — С, наверное, был бы хорош.
Возможно, вас пугает сложность С++. Это нормально. Даже не знаю как вам помочь, к сожалению. Может быть, действительно, не стоит его выбирать из-за этого. Если вас от него не прёт. И вы не хотите по услышанным антиаргументам его выбора связывать с ним часть своей жизни.
Еще один антиаргумент подкину и я — разработчик С++. Пока работал интенсивно в банке 2 года практически не читал статей и не смотрел видео с конференций. Хотя до этого делал это с большой охотой и регулярностью.
Думаете как меня оценили когда на очередном собеседование спросили насколько хорошо я ориентируюсь в новом стандарте?
Еще мысли для рассуждений:
1. Я не до конца понимаю недавно услышанное высказывание разработчика как на каком-то языке он сделал такой проект, на другом языке другой проект. Так в жизни, может, у него повернулось, конечно.
2. Думаю, всё-таки, есть основная связка языков(в моём случае С++, python, bash), технологий(Linux, ELK, БД и т.п.) своего стека. С ним по жизни и идти. Совершенствоваться, естественно. Может, постепенно перекатиться на другой. Но может оказаться, что ты обнуляешь N лет специфичных для твоего стека знаний потаенных углов, хороших, плохих практик, шаблонов и теперь конкурируешь с людьми, которые N лет в этой новой для тебя области уже работают и прутся от этого.
Просто когда ты профессионал, ты можешь делать такие вещи. Разработчик с 2000ых занимается JDK(наш соотечественник, как понял). И сейчас взял и ускорил переносимый сервис Netflix'a сделав патчи в сам JDK.
