Обычно как — все согласны с тем что C незаменимый язык, будет жить еще долго, особо нечего добавить и нечего убавить, со всех сторон хорош.
Ну и как бы C++ — этот тот же C, но плюс еще доп. фишки в виде классов — как бы и то и то.
Но! Больше — не значит лучше. Оно в теории то так, используя C++ вы можете не тянуть все фишки, однако же оно неизбежно засоряется и усложняется, раз такая возможность присутствует. Особенно когда n разработчиков.
Один авторитет (имя запамятовал) рассматривал так. Для системы — C и Asm. Для гламура, когда нужны классы — сразу Java. Не С++. Ну и, кроме того, C++ сейчас может быть потеснен тем же Rust-ом, как бы вы опять не высмеивали — а C ничем потеснен не будет, он как всегда неотразим в своей нише.
Здравствуйте, Shmj, Вы писали:
S>Ну и как бы C++ — этот тот же C, но плюс еще доп. фишки в виде классов — как бы и то и то.
Классы это объектно-ориентированное программирование, а ещё есть шаблоны, это обобщённое программирование. Когда используешь обобщённое программирование производительность не снижается по сравнению с Си, так как происходит генерация новых функций и классов по шаблону. Зато это позволяет не переписывать код, что не может Си.
А теперь следи за руками, Unix, Си и C++ были разработаны в лаборатории Белла. И ты можешь сказать, ну и что?
А вот если бы ты сначала прочёл книжку от создателей Си, то понял бы, что они заменили им ассемблер. Смекаешь? Си это системный или если не понятно системообразующий язык для наследников Unix. А кто у нас наследник Unix? О! Да это все свободные дистрибутивы. А ещё Google, Apple, Sony, Nintendo и прочие создали "свои" операционки на базе BSD или Linux.
Понимаешь теперь почему Си нельзя убить? Потому что сами операционные системы написаны на нём. Полная совместимость. Можешь даже думать об этом как об улучшенном ассемблере.
А теперь, что касается C++. По сути он расширяет возможности Си. И это не какая-то левая приблуда от незнамо кого. У C++ такая же железобетонная поддержка на уровне компиляторов как и у Си. И производительность у него на уровне Си в обобщённом программировании. И есть какая никакая совместимость с Си на уровне кода, пусть и не полная.
Далее лично ты, компания "Рога и копыта" или кто угодно может писать программы на чём хочет. Даже я заметь тебя не агитирую ни за Си ни за C++, я просто пытаюсь объяснить ситуацию.
Но я сейчас сижу в GNU/Linux, конкретно в Debian, и вся структура операционки сделана, чтобы создавать проекты для Си и C++. Просто заглядываешь в системные папки и понимаешь, что другим языкам здесь делать нечего, потому что вся их структура заточена под Си и C++.
И существует не только огромное количество проектов на Си и C++. Если в лесу есть тропинка, то на встречу или обгоняя может пройти человек. Тропинка это значит лес не безлюден, здесь активно каждый день ходят люди раз так умудрились протоптать землю.
Тоже самое и с проектами. Ты смотришь на них, но забываешь про армию программистов, которые это всё написали. Для начала утилизируй не только всех наследников Unix, но и профессиональных программистов написавших огромное количество программ.
А они ведь никуда не денутся и не только из-за топовых проектов, но ведь операционку тоже надо писать. Причём обучаться алгоритмам как раз желательно на Си, а потом уже можно переходить на C++.
В общем собака лает, караван идёт. Пока яваскрипты и расты покоряют просторы вселенной где-то рядом корпят программисты на Си и C++. Вот ты собрался убить C++, ну тогда прощай игровые движки, прощай CAD/CAE/CAM, некоторые графические интерфейсы пользователя, обобщённые библиотеки алгоритмов и прочее.
А я прекрасно вижу какое говно получилось у тех, кто программировал Android и iOS для виртуальных машин. Лучшие приложения включая игры там тоже используют движки написанные на C++. И это не шутка, а факт.
Есть ещё два мнение отличных от написанного выше. Якобы язык программирования выбирается не из профессионализма программистов, а под задачу. Ещё одно мнение, что всё должно быть модно и хайпово, на результат плевать.
Здравствуйте, Shmj, Вы писали:
S>Обычно как — все согласны с тем что C незаменимый язык, будет жить еще долго, особо нечего добавить и нечего убавить, со всех сторон хорош.
Не согласен. Его легко пнёт из кресла D. Тут ведь вопрос коммерческий, а уж возможностей D хватит потягаться с ЛЮБЫМ языком!
S>Ну и как бы C++ — этот тот же C, но плюс еще доп. фишки в виде классов — как бы и то и то.
Ну и как бы ушлёпский синтаксис, что чёрт ногу сломит!
S>Один авторитет (имя запамятовал) рассматривал так. Для системы — C и Asm.
На сегодня — да, вполне стабильная связка.
S> Для гламура, когда нужны классы — сразу Java
Дилетант это, а не "авторитет", гоните его ссаными тряпками!
S> C++ сейчас может быть потеснен тем же Rust-ом
Не может. Раст — это внебрачное дитя удода с ежом, так что вообще никаких надежд с Растом не питаю — обычный высер, коих сотни.
S>Возражения?
Занялся б ты делом, Шмж! Только на вентилятор набрасываешь, толку — ноль.
Здравствуйте, CreatorCray, Вы писали:
NB>>а разреши вопрос, какой у тебя опыт практической работы с C++? CC>Я думаю это риторический вопрос
Можно сказать опыт — около 1-2 недели. Переводил библиотеку с С++ на C#, но приходилось только читать и то не очень долго. Второе — это писал небольшую утилиту, по-моему дня на 3 работы.
Но и этого хватило чтобы понять насколько глубока кроличья нора
Сейчас предлагают мне повысить свой уровень и сделать средней сложности проект — как раз выбор между этими двумя. Есть причина, почему не подходит Java, .Net и Dart.
И сейчас больше склонен к выбору C. Тем более что для него есть все библиотеки, практически нет нужды в ++.
Здравствуйте, velkin, Вы писали:
V>Но я сейчас сижу в GNU/Linux, конкретно в Debian, и вся структура операционки сделана, чтобы создавать проекты для Си и C++. Просто заглядываешь в системные папки и понимаешь, что другим языкам здесь делать нечего, потому что вся их структура заточена под Си и C++.
Вы как бы обещаете — Си и C++. На самом деле там только C. Ядро и основополагающие вещи на голом C без бардака, который вносит ++. Что сверх того — то от лукавого.
Когда хочется и то и то — это типичный женский подход. Мужик умеет отрезать — выделять главное. А женщина — и то хочу, и чтобы и систему писать, и чтобы классы и все в одном — потому что нет силы характера — не может выбрать главное и отказаться от малозначимого. Мужик может выбрать — если система и скорость — то голый C. Если рюшечки — то Java/C#.
Здравствуйте, AlexGin, Вы писали:
AG>Это, конечно же, заблуждение. AG>Если проект большой, даже средний, и всё на C — его продвижение и поддержка превращаются в nightmare.
Вы так говорите, как будто ++ что-то улучшает в этом вопросе. Давайте честно — ++ только усугубляет положение, т.к. дает больший простор для создания бардака, чем всенепременно воспользуются кодо-писатели.
Здравствуйте, vsb, Вы писали:
vsb>Ну мне надо код писать и поддерживать, а не С++ осиливать. С кодом на С я знаю, что я его могу дать любому программисту, который С когда-то учил в университете и он этот код поймёт и сможет поддерживать и что-то по мелочи дописывать.
И будет получаться запутано, бойлерплейтненько и всё в трудноуловимых багах, потому что тут недосмотрел, здесь недодизайнил.
Си от асма недалеко ушёл. Таки да, сам то язык простой, но вот чтоб таки на нём писать чистый код надо много опыта и силы воли. У каждого пейсателя.
На плюсах же в этом отношении вменяемому лиду куда проще сделать загончики, чтоб маппетам было сложно говна наворотить. На сях нет никаких для этого инструментов, кроме таких же рукопашных как сам си.
vsb> С кодом на С++ — однозначно нужен отдельный человек, который будет незаменимым.
Банально надо чтобы лид, который задаёт архитектуру, был вменяемый. Незаменимых не надо, нафига?
vsb>Так что — да, C++ не осилил и считаю это проблемой C++, а не своей.
Да нашел что мешает, переполнение безнаковых целочисленных в расте. В си просто такое переполнение игнорируется и считает по модулю. Но почему трудолюбивый автор раст кода везде использует wrapping_add когда есть удобная обертка Wrapping непонятно. С ней можно сделать так:
use std::num::Wrapping;
fn main() {
// начальные переменныеlet s:[u8; 256] = [10; 256];
let (i, j, k, z) = (250u8, 250u8, 250u8, 250u8);
// заворачиваем (если операция частая можно макрос сварганить).let (i, j, k) = (Wrapping(i), Wrapping(j), Wrapping(k));
let mut z = Wrapping(z);
// сам кодlet S = |a: Wrapping<u8>| Wrapping(s[a.0 as usize]);
z = S(j + S(i + S(z + k)));
// разворачиваем результатlet z = z.0;
dbg!(z);
}
И судя по его коду по твоей ссылке можно было не обертывать при каждом использовании а сразу объявить переменные как Wrapping<u8> тогда свертки развертки не нужны. В таком случае все совсем просто будет, практически как на си:
use std::num::Wrapping;
fn main() {
// начальные переменныеlet s = [Wrapping(10u8); 256];
let (i, j, k) = (Wrapping(250u8), Wrapping(250u8), Wrapping(250u8));
let mut z = Wrapping(250u8);
// сам кодlet S = |a: Wrapping<u8>| s[a.0 as usize];
z = S(j + S(i + S(z + k)));
dbg!(z);
}
R>Покажи уже, как правильно и без потери производительности.
Судя по ассемблерному коду тут оптимизируется вусмерть.
FR>> И также что мешает в си засунуть все переменные в структуру (для получения "красивого" self->) и вместо макроса зафигарить такую же красоту по месту как в раст примере?
R>
R>Ничто не мешает И читаемость не страдает, как по мне.
Ну нет для полноты картины надо без макроса, как автор кода на расте, мы же на стили хотим посмотреть.
R>Тут демонстрация того, что в раст встроен обфускатор на уровне языка. Ну правда, ведь невозможно же код читать И это примитивное выражение, а если на метод update посмотреть...
Тут похоже демонстрация не очень хорошего знания языка автором кода, с таким знанием он и на си без макросов трудолюбиво бы все расписал.
Здравствуйте, Baiker, Вы писали:
B>Не согласен. Его легко пнёт из кресла D
И всё никак...
D вообще ни в каких окрестностях около С не замечен.
Более того, С жеж используют совсем не потому что это хороший язык, совсем нет.
Здравствуйте, AleksandrN, Вы писали:
AN>Для десктопного софта — стал.
Разишо только внутриэнтерпрайзненько, потому что там чо дали то и будут жрать.
А вот для enduser-ей как то жабасофта не видно и не слышно
Я в смешанных противоречивых чувствах.
S>Можно сказать опыт — около 1-2 недели. Переводил библиотеку с С++ на C#, но приходилось только читать и то не очень долго. Второе — это писал небольшую утилиту, по-моему дня на 3 работы. S>Но и этого хватило чтобы понять насколько глубока кроличья нора
Поверь, не хватило. Это твоё эго говорит тебе, что хватило
S>Сейчас предлагают мне повысить свой уровень и сделать средней сложности проект — как раз выбор между этими двумя. Есть причина, почему не подходит Java, .Net и Dart.
Если предлагают — берись, учись, делай. С++ — изумительный язык.
S>И сейчас больше склонен к выбору C. Тем более что для него есть все библиотеки, практически нет нужды в ++.
Тебе уже здесь сказали, что бардак — от программиста, а не языка. Да, С++ много позволяет программисту, потому требует от него профессионализма. Если ты что-то не умеешь в нём, просто запрети себе на данном этапе это использовать, например, написав style_guide или coding_standard для конкретного проекта, если нет общего в компании, Да даже если и есть, никто не запретит тебе конкретизировать/уточнить/расширить/сузить фирменные стандарты для применения в твоём проекте.
Здравствуйте, Shmj, Вы писали:
S>И сейчас больше склонен к выбору C. Тем более что для него есть все библиотеки, практически нет нужды в ++.
Думаю что с того же C# проще всего будет перейти на вариант C++ который называется "Си с классами", то есть используются классы + стандартная библиотека, и никаких или по самому минимуму шаблонов и современного сахара в клиентском коде. Дельфисты в свое время вполне успешно и быстро переходили на такой вариант. И да это будет проще чем перейти с C# на чистый си.
Здравствуйте, 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() дает такую информацию, если его убрать то снова будут добавлены проверки на выход за границы буфера и пропадет инлайнинг, но зато в рантайме свалится с паникой, а не будет непредсказуемо переполнять буфер как в си.
Здравствуйте, Kernan, Вы писали: K> Скорее всего С++ нас будет ещё долго радовать или "радовать" кому как, а вот С будет заменён Rust который, на мой взгляд, выглядит как более простой язык для решения задач системных уровня, но уже имеющий внутри все наработки и инструменты текущего языкостроения которых не хватает в С.
V>Когда используешь обобщённое программирование производительность не снижается по сравнению с Си, так как происходит генерация новых функций и классов по шаблону. Зато это позволяет не переписывать код, что не может Си.
Рассуждения в целом верны, однако есть одно "но". Bloating. Распухание бинаря. Возникает сие явление, понятное дело, не от шаблонизации вообще, а исключительно от неумеренного злоупотребления оной. Многие скажут: ну распухание и распухание, что такого-то, RAM–то в наши времена немеряно. Но-но, охладите пыл, и попробуйте задуматься вот о чём: плотный маленький бинарь имеет гигантское преимущество в сравнении с рыхлым и раздутым в плане промахов по кешу инструкций. Вспоминаем основополагающий текст "RAM больше не RAM", нарастающий год от года отрыв кэша от RAM в скоростях и латентностях, а потом суровую практику, многосотмегабайтные бинарники, раздутые от семиэтажных шаблонов, и сверяемся с циферками кэшей: даже самый медленный третий уровень в наши времена что-то около 20 мегабайт, если не ошибаюсь. Ясен пень, не на один процесс, а на всех.
Было дело, QNX хвастался тем, что их плотное минималистичное ядро целиком влезает в L2–кэш, и это вроде как даёт преимущества не только и не столько в скоростях, сколько в детерминизме, так необходимом в системах реального времени.
V>Понимаешь теперь почему Си нельзя убить? Потому что сами операционные системы написаны на нём. Полная совместимость. Можешь даже думать об этом как об улучшенном ассемблере.
Этот верный довод красивее всего формулируется так: "Си теперь не язык, а lingua franca. Наподобие латыни у врачей у юристов. На ней не говорят, но она никуда не денется".
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Wawan, Вы писали:
W>>новая перекличка тех кто С++ не осилил
vsb>Ну мне надо код писать и поддерживать, а не С++ осиливать. С кодом на С я знаю, что я его могу дать любому программисту, который С когда-то учил в университете и он этот код поймёт и сможет поддерживать и что-то по мелочи дописывать.
НЕЕЕЕТ! НЕТ. Ровно те же концепции, что есть в Java, C#, F#, C++, Common Lisp... их все реально реализовать на голом C.
Выглядеть будет страшновато. И программа уже будет не совсем на C. Воспринимать её как программу на C можно ровно так
же, как результат компиляции C++ в ассемблер можно воспринимать на ассемблере. Любой студент разберётся? Скорей наломает дров,
причём куда хуже, чем если бы ему дали сразу C++.
Легко доказывается, что идея "простого языка" она не состоятельна. Можно взять, например, воображаемую ленту Тьюринга.
Или Brainfuck. Или язык ассемблера контроллеров фирмы Microchip PIC, где как любит упомянутая фирма писать, всего 35
(плюс-минус) инструкций, которые легко выучить. И на всех этих языках можно писать _сложные_ программы, а для последнего
есть попросту C-компилятор (не простой, с "компилируемым стеком"). Очевидно что программирование всего перечисленного
прямо скажем -- сильно не тривиально. Хотя казалось бы "несколько простых инструкций". Только любые более-менее сложные
концепции в этих инструкциях начинают выражаться очень непростым способом.
На самом деле мы имеем такую ситуацию, что с одной стороны стоят языки с "очень простыми инструкциями", а с другой
языки с очень большим количеством очень сложных концепций. И то и другое -- две крайности. Человеку проще освоить
всё же несколько большее количество инструкций и готовых концепций (библиотечных функций, конструкций языка), чем
реализовывать эти концепции на "очень простом языке" самостоятельно. Но до определённого предела. Слишком сложные
концепции не лучше, чем "очень простые инструкции". Последнее, на мой взгляд, демонстрирует C#. Где слишком много
встроенных именно концепций языка.
Что же касается C++, то многие вещи в нём на самом деле -- библиотечные функции,
а база на которой они построены пожалуй куда проще. Там проблема в другом, что те кто не понимают C++, на самом деле
не понимают, что это по меньшей мере три разных языка: язык макропроцессора C, императивный "улучшенный язык C с объектами",
и наконец _декларативный_ язык шаблонов, который лишь позволяет задавать правила по которому генерируются конструкции
"языка C с объектами". И повторюсь, многие вещи -- библиотечные функции или классы, а не свойства языка. Проблема в том,
что учат всему в целом, в куче, не разделяя на слои и у обучаемых не складывается правильая картина, они попросту
не понимают, например, что cout << "text" -- это ни разу не свойство языка (как Write() в паскале), а лишь перегруженный
оператор и библиотечный класс.
Отдельная проблема, что некоторые люди практически не владеют абстрактным мышлением ("не отдам ему яблоко, хоть он дерись").
По-видимости это какой-то дефект развития заложенный в очень раннем возрасте (родители не обучали ребенка).
Понимают всё только на конкретных примерах. И им просто объективно сложно понять концепции метапрограммирования.
И таких людей -- много. Увы.
vsb> С кодом на С++ — однозначно нужен отдельный человек, который будет незаменимым. Если в компании всё на С++, vsb> то нормально. Если всё на Java, к примеру, а какие-то небольшие части нужно на С/С++ написать по какой-то причине, vsb> лично я альтернативы C вообще не вижу.
В переводе на русский -- C++ требует обученных сотрудников, а с языком C -- может кто-то работать "по-совместительству".
Да, но по мере усложнения C-подпроекта он рискует по-сложности обогнать C++. И там действительно будут незаменимые люди.
Потому, что одно дело программа написанная в рамках стандартных средств языка, а другое дело, когда эти стандартные
(и всем понятные) средства заменяются на самодельные аналоги (к чему приходит сложная C-программа). Потому, что ряд
условно сложных концепций он в любой программе существует, не зависимо от языка. Это определяется задачей, а не языком.
И хорошо, если эти сложноть концепций ограничивается в языке или в стандартной библиотеке, а не в коде который нужно
поддерживать. Почему C#/Java и энтерпрайзе и лидируют. Готовая библиотека и язык имеют ответы на многие вопросы.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, vaa, Вы писали:
vaa>>Против чего? Что СИ вечен? Это все знают.
S>Что C вечен а вот C++ — нет.
ничто не вечно, но пока есть си плюсам быть, на нем стока кода уже написано.
даже если будет транслятор в другой яп, полностью переписать все нереально(ни желание ни сил думаю не хватит)
допустим раст. нужно либо переписать либо разработать лучщий аналог. объем работ фантастический. т.е. лет уйдет столько же сколько сущ плюсы.
или больше.
Здравствуйте, Shmj, Вы писали:
S>Вы как бы обещаете — Си и C++. На самом деле там только C. Ядро и основополагающие вещи на голом C без бардака, который вносит ++. Что сверх того — то от лукавого.
Я видел женщин — системных программистов. Большинству мужиков у них учиться и учиться. Я, кстати, тоже у них кое-чему научился.
S>Мужик может выбрать — если система и скорость — то голый C. Если рюшечки — то Java/C#.
Да-да. Видел я однажды, как мужик на голом C запилил сортировку файла. 2000 записей у него сортировались 40 минут. Понимаешь? Две тысячи записей. За сорок минут. Вот это скорость! И никакого бардака.
Здравствуйте, scf, Вы писали:
scf>Ну я осилил, стандарт мог цитировать.
Не, знание стандарта, это как #барь-теоретик — знает чем, знает как, знает куда, а вот на практике на полшестого
Здравствуйте, zx zpectrum, Вы писали:
V>>Когда используешь обобщённое программирование производительность не снижается по сравнению с Си, так как происходит генерация новых функций и классов по шаблону. Зато это позволяет не переписывать код, что не может Си. ZZ>Рассуждения в целом верны, однако есть одно "но". Bloating. Распухание бинаря. Возникает сие явление, понятное дело, не от шаблонизации вообще, а исключительно от неумеренного злоупотребления оной. Многие скажут: ну распухание и распухание, что такого-то, RAM–то в наши времена немеряно.
Пухнет обычно тогда когда не понимают чем пользуются. Утверждение, мол C++ раздувает код -- бредовое.
И таки да, часто имеет смысл пожертвовать объёмом программной памяти в пользу производительности.
ZZ> Но-но, охладите пыл, и попробуйте задуматься вот о чём: плотный маленький бинарь имеет
Где-то имеет, где-то не имеет. Маленький плотный бинарь может при этом может препятствовать суперскалярному и спекулятивному исполнению,
векторизации, просто использовать существенно менее эффективные алгоритмы и т.п. Скажем qsort из C и std::sort из C++ сравнивать очевидно глупо.
Первый сколько-нибудь эффективно реализован быть не может. А второй может запросто породить шаблонного кода нужного только один раз
и так каждый раз заново для нового типа. Но зато второй может оказаться существенно быстрей.
ZZ> раздутые от семиэтажных шаблонов
Шаблон -- это лишь некоторое правило для компилятора. Он ни к чему не обязывает, в частности к генерации "раздутого кода".
Как им воспользуются, и что из этого получится -- зависит от программиста, а не от шаблонов вообще.
Простейший пример: попытка сделать самодельный аналог STL-контейнера, например, вектора.
Подход в лоб даст тот самый эффект, что на каждый тип компилятор порождает всё новые инстансы
одних и тех же функций (может быть, даже буквально совпадающих в ассемблере). Если за задачу
возьмётся студент, так наверное и выйдет. Если возьмётся немного более опытный программист, то
он ряд обобщённых методов, не зависящих от конкретного типа, выделит в один базовый класс, например,
где свойства конкретных типов будут уже не параметрами шаблона а просто данными. И только в основном
конструкторы, операторы присваивания и деструкторы нетривиальных классов останутся специфичными для
каждого типа параметра шаблона.
ZZ>Было дело, QNX хвастался тем, что их плотное минималистичное ядро целиком влезает в L2–кэш, и это вроде как даёт преимущества не только и не столько в скоростях, сколько в детерминизме, так необходимом в системах реального времени.
Детерминизм в значительной степени определяется применяемыми АЛГОРИТМАМИ, а не оптимизацией уровня ассемблера.
И разница между хорошим и плохим алгоритмом может быть как между n*x или e^x, а оптимизация на ассемблере лишь
меняет в какой-то степени константу n. Что на фоне e^x ни разу не существенно вообще.
В частности, корни детерминизма растут из примитивов синхронизации и алгоритмов планирования.
Например, наивная реализация спинлока, самого что ни на есть базового механизма синхронизации любой ОС,
вообще не гарантирует, что она завершится за хоть какое-нибудь конечное время. И для этого существует
специальный алгоритм (https://en.wikipedia.org/wiki/Ticket_lock) гарантирующий обработку в порядке
очерёдности.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, vsb, Вы писали:
vsb>>Ну мне надо код писать и поддерживать, а не С++ осиливать. С кодом на С я знаю, что я его могу дать любому программисту, который С когда-то учил в университете и он этот код поймёт и сможет поддерживать и что-то по мелочи дописывать. CC>И будет получаться запутано, бойлерплейтненько и всё в трудноуловимых багах, потому что тут недосмотрел, здесь недодизайнил. CC>Си от асма недалеко ушёл. Таки да, сам то язык простой, но вот чтоб таки на нём писать чистый код надо много опыта и силы воли. У каждого пейсателя.
Да, язык C провоцирует к спагетти-коду, полному глобальных переменных и зависимостей основанных на данных (вместо того, чтоб
выделить интерфейс и его использовать, напрямую лезут в чужие структуры данных). Такой код поддерживать тяжело и дорого, рефакторить
практически невозможно, часто оно годится чтоб выкрасить и выбросить только...
Здравствуйте, rudzuk, Вы писали:
R>Ага, очень простой...
Непонятно что мешает на раст написать функцию (лямбду если по месту или макрос если надо развернуть не надеясь на инлайнинг) S и получить точно такой же код как в си?
И также что мешает в си засунуть все переменные в структуру (для получения "красивого" self->) и вместо макроса зафигарить такую же красоту по месту как в раст примере?
По моему тут никаких демонстраций особенностей языков нет вообще (кроме более строгих кастов раста), а только демонстрация разных стилей одинаково доступных на обеих языках.
Здравствуйте, Shmj, Вы писали:
V>>Но я сейчас сижу в GNU/Linux, конкретно в Debian, и вся структура операционки сделана, чтобы создавать проекты для Си и C++. Просто заглядываешь в системные папки и понимаешь, что другим языкам здесь делать нечего, потому что вся их структура заточена под Си и C++.
S>Вы как бы обещаете — Си и C++. На самом деле там только C. Ядро и основополагающие вещи на голом C без бардака, который вносит ++. Что сверх того — то от лукавого.
Ты, как обычно, написать ерунду. Как говорится, программист на фортране напишет программу на фортране на любом языке программирования. Это я про то, что бардак от языка не зависит, в общем случае (если не говорить о каком-нибудь брайнфаке, конечно)
Ты в какой-нибудь линупсовый софт в сорцы смотрел? Gnome, например? Видел там у них GOject? Понимаешь? Гобжект, буагага А как смешно смотреть, как линупсоиды изобретают плюсовые виртуальные функции на таблицах указателей на функцию. Так и представляешь, сколько боли испытали эти люди, пока это всё хоть как-то начинало работать. А казалось бы — взял плюсовый класс, сделал абстрактный интерфейс, отнаследовался, написал реализацию. Компилятор за тебя все таблицы собрал, все по параметрам проверил.. Но нет, это не линупсовый путь, без кактуса в жопе они уже не могут
S>Когда хочется и то и то — это типичный женский подход. Мужик умеет отрезать — выделять главное. А женщина — и то хочу, и чтобы и систему писать, и чтобы классы и все в одном — потому что нет силы характера — не может выбрать главное и отказаться от малозначимого. Мужик может выбрать — если система и скорость — то голый C. Если рюшечки — то Java/C#.
О, а теперь еще и мужской/женский подход решил натянуть
Здравствуйте, scf, Вы писали:
scf>Ну я осилил, стандарт мог цитировать. Но зачем писать на С++, если производительность труда на Java выше в несколько раз?
Если отойти немного, от мира оффисного программирования, то окажется, что приложения на таких ЯВУ как Java и C#,заметно проигрывают по производительности выполнения нативным.
Здесь дело не только в наличии GC. Вся среда выполнения (ран-тайм) этих приложений достаточно громоздкая. Я не хочу и не буду вдаваться здесь
в теорию, но факт остаётся фактом — где надо выжимать из аппаратуры всю производительность, там — добро пожаловать в C++
scf>А в профессиональной и домашней деятельности мне почти не попадалось задач, которые можно хорошо сделать на С++ и нельзя хорошо сделать на Java.
Это смотря что понимать под деятельностью:
Профессиональная — разработка умных устройств для ВПК, движки БД, сложные алгоритмы, обработка фото, видео, звука.
Домашняя — программы для умного_дома, IoT.
Вот — далеко не полный список направлений для разработок, где применение C++ не имеет альтернатив.
Но, конечно же, если ограничиться деятельностью офис и/или банк — то здесь Вы правы.
Здравствуйте, rudzuk, Вы писали:
FR>> Судя по ассемблерному коду тут оптимизируется вусмерть.
R>Не, так не интересно, он там все соптимизировал во время компиляции. А можно пример, где компилятор будет реально по индексам читать?
Пример
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 u8;
//dbg!(b);
// начальные переменныеlet s = [Wrapping(10u8); 256];
let (i, j, k) = (Wrapping(b), Wrapping(b), Wrapping(b));
let mut z = Wrapping(b);
// сам кодlet S = |a: Wrapping<u8>| s[a.0 as usize];
z = S(j + S(i + S(z + k)));
//dbg!(z);
std::process::exit(z.0 as i32);
}
тут выхлоп ассемблера получается без проверок границ:
То есть компилятор смог понять что выходов за границы массива не будет и выкинул все проверки.
Вот если вместо let s = [Wrapping(10u8); 256]; сделать например let s = [Wrapping(10u8); 25]; то есть длина массива меньше 256 то добавятся проверки на границы и плюс пропадет инлайнинг замыкания.
FR>> Ну нет для полноты картины надо без макроса, как автор кода на расте, мы же на стили хотим посмотреть.
R>Без макроса подлиннее, но в рамках приличий. R>
Здравствуйте, Shmj, Вы писали:
S>Обычно как — все согласны с тем что C незаменимый язык, будет жить еще долго, особо нечего добавить и нечего убавить, со всех сторон хорош.
S>Ну и как бы C++ — этот тот же C, но плюс еще доп. фишки в виде классов — как бы и то и то.
S>Но! Больше — не значит лучше. Оно в теории то так, используя C++ вы можете не тянуть все фишки, однако же оно неизбежно засоряется и усложняется, раз такая возможность присутствует. Особенно когда n разработчиков.
S>Один авторитет (имя запамятовал) рассматривал так. Для системы — C и Asm. Для гламура, когда нужны классы — сразу Java. Не С++. Ну и, кроме того, C++ сейчас может быть потеснен тем же Rust-ом, как бы вы опять не высмеивали — а C ничем потеснен не будет, он как всегда неотразим в своей нише.
S>Возражения?
Против чего? Что СИ вечен? Это все знают.
Пока не вернутся ЛИСП-машины будем писать на СИ.
Здравствуйте, Shmj, Вы писали:
S>Возражения?
C++ Modules & ABI, разговоры и обсуждения давно идут, жду когда это всё оформят и поддержат(компиляторы), после этого C будет потихоньку уходить а на его место встанет С++ с меньшим кодом и лучшей оптимизацией.
Здравствуйте, Shmj, Вы писали:
S>Один авторитет (имя запамятовал) рассматривал так. Для системы — C и Asm. Для гламура, когда нужны классы — сразу Java. Не С++. Ну и, кроме того, C++ сейчас может быть потеснен тем же Rust-ом, как бы вы опять не высмеивали — а C ничем потеснен не будет, он как всегда неотразим в своей нише.
И это был тот же Исаак Ломоносов, который утверждал, что у цитат в интернете все теряют авторство.
S>Возражения?
"Было бы величайшей ошибкой думать!" ([ПСС В.И.Ленина, том 41, страница 55])
Здравствуйте, Wawan, Вы писали:
W>новая перекличка тех кто С++ не осилил
Ну я осилил, стандарт мог цитировать. Но зачем писать на С++, если производительность труда на Java выше в несколько раз? А в профессиональной и домашней деятельности мне почти не попадалось задач, которые можно хорошо сделать на С++ и нельзя хорошо сделать на Java.
Здравствуйте, vsb, Вы писали:
vsb>Ну мне надо код писать и поддерживать, а не С++ осиливать. С кодом на С я знаю, что я его могу дать любому программисту, который С когда-то учил в университете и он этот код поймёт и сможет поддерживать и что-то по мелочи дописывать.
Это, конечно же, заблуждение.
Если проект большой, даже средний, и всё на C — его продвижение и поддержка превращаются в nightmare.
Ну а если проект достаточно элементарный — тогда всё примерно так.
vsb>С кодом на С++ — однозначно нужен отдельный человек, который будет незаменимым. Если в компании всё на С++, то нормально. Если всё на Java, к примеру, а какие-то небольшие части нужно на С/С++ написать по какой-то причине, лично я альтернативы C вообще не вижу.
Про то, что незаменимых нет — аксиома давно известная.
Зная C & Java, освоение C++ выглядит достаточно реальным, не сверх-сложним, шагом.
vsb>Так что — да, C++ не осилил и считаю это проблемой C++, а не своей.
Проблема человечества — Матушка Лень раньше всех нас родилась.
P.S. Поймите меня правильно, уважаемый vsb, что овладевая новым (для самого себя) языком или технологией:
1) Расширяешь свой профессиональный кругозор;
2) Повышаешь свою потенциальную востребованность на рынке труда;
3) Тренируешь свой мозг, на позволяя ему атрофироваться.
Здравствуйте, Shmj, Вы писали:
S>Вы как бы обещаете — Си и C++. На самом деле там только C. Ядро и основополагающие вещи на голом C без бардака, который вносит ++. Что сверх того — то от лукавого.
Не секрет, что разработчики для UNIX/Linux используют именно C и C++ (там, где попроще — C, где посложнее — плюсы).
Что же касается бардака, то как раз применение Объектно-ориентированного подхода (характерное для C++) помогает его избежать.
S>Когда хочется и то и то — это типичный женский подход. Мужик умеет отрезать — выделять главное. А женщина — и то хочу, и чтобы и систему писать, и чтобы классы и все в одном — потому что нет силы характера — не может выбрать главное и отказаться от малозначимого. Мужик может выбрать — если система и скорость — то голый C. Если рюшечки — то Java/C#.
Давайте, уважаемый Shmj, отложим в сторону чьих-то гендерных тараканов.
Если у меня: система, скорость, алгоритмическая_сложность — что же я (как мужик, разрабатывающий софт последние 0x14 лет) должен выбрать?
P.S. Думаю, что выбор будет именно за C++. Но, естественно, до этого надо дойти. Дойти своим умом, своей дорогой...
Здравствуйте, Shmj, Вы писали:
S>Вы так говорите, как будто ++ что-то улучшает в этом вопросе. Давайте честно — ++ только усугубляет положение, т.к. дает больший простор для создания бардака, чем всенепременно воспользуются кодо-писатели.
а разреши вопрос, какой у тебя опыт практической работы с C++?
Здравствуйте, Shmj, Вы писали:
S>Обычно как — все согласны с тем что C незаменимый язык, будет жить еще долго, особо нечего добавить и нечего убавить, со всех сторон хорош.
Моё мнение, C -- это оставшийся в 70-х недоязык, и C++ это современная замена ему, родившаяся как развитие
и бесконечное исправление недостатков предка (т.е. языка C). Что-то доказывать не буду, как и спорить.
Наелся того и другого, пришёл в программирование из embedded и сейчас в какой-то степени ембеддед (причём C),
прекрасно понимаю, что C -- один сплошной недостаток, многое в C++ исправлено и сделано лучше. Есть
много новых "лишних" сущностей, но не нравится -- не используй... Хотя и не согласен, что лишних.
C-решения -- багоопасны, не эффективны, запутаны. У C единственное преимущество -- могут работать
малоквалифицированные программисты. Которые ноги себе отстрелят в C++. Хотя если копнуть по-глубже, то
может выйти и наоборот. Программа на C++ как правило требует отладки на уровне компиляции, а программа
на C -- в отладчике. Потому, что C-программист уподобляется астрологу, который по расположению звёздочек
в программе должен угадать где ошибка. Ибо везде reinterpret_cast и void*, отсутствие автоматического
управления ресурсами (RAII) и легко что-то забыть, полное игнорирование понятия указателя на константу.
Язык для хакеров, где важно быстро тяп-ляп.
S>Один авторитет (имя запамятовал) рассматривал так. Для системы — C и Asm. Для гламура, когда нужны классы — сразу Java. Не С++. Ну и, кроме того, C++ сейчас может быть потеснен тем же Rust-ом, как бы вы опять не высмеивали — а C ничем потеснен не будет, он как всегда неотразим в своей нише.
Скорей C может быть потеснён Rust'ом. Это как раз языки одного уровня. Где всё вручную,
хотя в Rust уже зачатки RAII и недошаблоны, что сильно лучше, чем ничего.
Здравствуйте, Kernan, Вы писали:
K> R>Без комментария в это не просто не въехать
K> Писать на Rust, а не на С средствами Rust. Эта же проблема и в С++ когда С-шник начинает писать на нём как на С.
А как этот код должен выглядеть по-растовски правильно?
Здравствуйте, Shmj, Вы писали:
AG>>Это, конечно же, заблуждение. AG>>Если проект большой, даже средний, и всё на C — его продвижение и поддержка превращаются в nightmare.
S>Вы так говорите, как будто ++ что-то улучшает в этом вопросе. Давайте честно — ++ только усугубляет положение, т.к. дает больший простор для создания бардака, чем всенепременно воспользуются кодо-писатели.
Давайте честно — ты ничего не писал на плюсах. Да и на сишечке тоже вряд ли
Здравствуйте, zx zpectrum, Вы писали:
V>>Когда используешь обобщённое программирование производительность не снижается по сравнению с Си, так как происходит генерация новых функций и классов по шаблону. Зато это позволяет не переписывать код, что не может Си. ZZ>Рассуждения в целом верны, однако есть одно "но". Bloating. Распухание бинаря. Возникает сие явление, понятное дело, не от шаблонизации вообще, а исключительно от неумеренного злоупотребления оной. Многие скажут: ну распухание и распухание, что такого-то, RAM–то в наши времена немеряно. Но-но, охладите пыл, и попробуйте задуматься вот о чём: плотный маленький бинарь имеет гигантское преимущество в сравнении с рыхлым и раздутым в плане промахов по кешу инструкций. Вспоминаем основополагающий текст "RAM больше не RAM", нарастающий год от года отрыв кэша от RAM в скоростях и латентностях, а потом суровую практику, многосотмегабайтные бинарники, раздутые от семиэтажных шаблонов, и сверяемся с циферками кэшей: даже самый медленный третий уровень в наши времена что-то около 20 мегабайт, если не ошибаюсь. Ясен пень, не на один процесс, а на всех.
А можно поподробнее про распухание? А то может оказаться, что кроме распухания происходит и спухание — когда на этапе линковки одинаковый код не дублируется. Далее, с шаблонами можно писать и так, что общий код реализуется в каком-то базовом классе, а параметризуемый — в наследниках, и его с гулкин нос. Если же типы, для которых производится инстанциация — сильно разные, и действительно пучат бинарь — то какой-тогда магией в сишечке делают плотный маленький бинарь?
А многосотмегабайтные бинарники (ты, кстати, о чем) — они обычно от того, что туда засунуто до черта функционала. Сишечные бинарники будут сравнимых размеров
ZZ>Было дело, QNX хвастался тем, что их плотное минималистичное ядро целиком влезает в L2–кэш, и это вроде как даёт преимущества не только и не столько в скоростях, сколько в детерминизме, так необходимом в системах реального времени.
Здравствуйте, 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>Конечно написать. Если за дело возьмётся специально обученная группа высочайшей квалификации. "Цыгане шумною толпою", нанятые по объявлению — не напишут.
Ещё раз — "цыгане шумною толпою", нанятые по объявлению — если на сишечке будут писать — у них оно даже не заведётся, будет по сегфолтам падать, а до релиза дело довести у инвестора денег не хватит
M>Ну ты тут в соседнем сообщении написал про "цыган, набранных по объявлениям" — хочешь соврать, что ядро линупса пишут именно такие?
Зачем сразу соврать? Нет, не соврать, а подписать под эту шутливую метафору две категории разношёрстной толпы с плавающей квалификацией. У сишной (linux) получается отлично, у плюсовой (FB–клиенты) — какое-то угрёбище. Но да, два примера как-то маловато будет.
M>Кстати, KDE — гораздо более молодой, чем GNOME — написан на плюсах. А работает гораздо приятнее
ХЗ, лично мне нынешний гном гораздо больше нравится. Ну да ладно, в религию не будем углубляться, пустое это.
А если же взять не KDE, а Qt, то да, отличная библиотека. Но заглянув внутрь видим, что плюсы под капотом весьма минималистичны, без тридцатиэтажных шаблонных матов, без метапрограммирования (1) головного мозга.
M>И да, не хочу тебя сильно травмировать, но основной компилятор GNU — GCC — переписывают на плюсы. Видимо, тащить его на сишечке уже больше нет сил
Не травмируешь, я прекрасно это знаю )
(1) Метапрограммирование — отличная концепция, но не тот его сорт, что был "discovered" в противовес "engineered".
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Baiker, Вы писали:
B>>Не согласен. Его легко пнёт из кресла D CC>И всё никак... CC>D вообще ни в каких окрестностях около С не замечен. CC>Более того, С жеж используют совсем не потому что это хороший язык, совсем нет.
Здравствуйте, Wawan, Вы писали:
W>новая перекличка тех кто С++ не осилил
Ну мне надо код писать и поддерживать, а не С++ осиливать. С кодом на С я знаю, что я его могу дать любому программисту, который С когда-то учил в университете и он этот код поймёт и сможет поддерживать и что-то по мелочи дописывать. С кодом на С++ — однозначно нужен отдельный человек, который будет незаменимым. Если в компании всё на С++, то нормально. Если всё на Java, к примеру, а какие-то небольшие части нужно на С/С++ написать по какой-то причине, лично я альтернативы C вообще не вижу.
Так что — да, C++ не осилил и считаю это проблемой C++, а не своей.
Здравствуйте, vaa, Вы писали:
vaa>даже если будет транслятор в другой яп, полностью переписать все нереально(ни желание ни сил думаю не хватит)
В web же другой путь уже давно пробуют с переменным успехом, так как JavaScript тоже заменить невозможно то пишут языки которые тупо в него компилируются, и тот же TypeScript вполне взлетел.
Для С++ и Си такое тоже вполне возможно, для Си и раньше были языки которые в него компилировались, но там цель больше переносимость была, а вот аналогов TypeScript, то есть попыток исправить недостатки, сохранив при этом достоинства и возможность прозрачно использовать весь старый наработанный код, что-то не припоминается. Carbon вроде интересная попытка, но не факт что этот эксперимент разовьется во что-то серьезное.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, vaa, Вы писали:
vaa>>даже если будет транслятор в другой яп, полностью переписать все нереально(ни желание ни сил думаю не хватит)
FR>В web же другой путь уже давно пробуют с переменным успехом, так как JavaScript тоже заменить невозможно то пишут языки которые тупо в него компилируются, и тот же TypeScript вполне взлетел. FR>Для С++ и Си такое тоже вполне возможно, для Си и раньше были языки которые в него компилировались, но там цель больше переносимость была, а вот аналогов TypeScript, то есть попыток исправить недостатки, сохранив при этом достоинства и возможность прозрачно использовать весь старый наработанный код, что-то не припоминается. Carbon вроде интересная попытка, но не факт что этот эксперимент разовьется во что-то серьезное.
Получается: если нужно написать программу хорошо — используйте С; если нужно написать хорошо прикладную программу — C++; если нужно написать быстро — Java; если под винду — C#; если программа уже написана, но у вас странные наклонности — Rust/Go/...
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, ry, Вы писали:
ry>Тебе уже здесь сказали, что бардак — от программиста, а не языка. Да, С++ много позволяет программисту, потому требует от него профессионализма. Если ты что-то не умеешь в нём, просто запрети себе на данном этапе это использовать, например, написав style_guide или coding_standard для конкретного проекта, если нет общего в компании, Да даже если и есть, никто не запретит тебе конкретизировать/уточнить/расширить/сузить фирменные стандарты для применения в твоём проекте.
Здравствуйте, Baiker, Вы писали:
B>Не согласен. Его легко пнёт из кресла D. Тут ведь вопрос коммерческий, а уж возможностей D хватит потягаться с ЛЮБЫМ языком!
Да, да, что-то такое я помню слышал 20 лет назад, потом еще раз 15 лет назад, а потом что-то уже не слышал. Может язык и хороший, но ИМХО если он за 20 лет не взлетел, то что-то с ним не так и он уже не взлетит.
B>Ну и как бы ушлёпский синтаксис, что чёрт ногу сломит!
Ну вообще тут согласен, причем синтаксис становится все сложенн и сложнее.
S>>Один авторитет (имя запамятовал) рассматривал так. Для системы — C и Asm.
B>На сегодня — да, вполне стабильная связка.
Че то я уже давно не видел чтоб кто-нибудь писал на асме, даже для всяких там микроконтроллеров.
B>Не может. Раст — это внебрачное дитя удода с ежом, так что вообще никаких надежд с Растом не питаю — обычный высер, коих сотни.
Раст в отличии от D вполне себе взлетел, хоть и не высоко. Но вообще раст влезает именно в нишу где юзают С++, так что не исключаю, что он может довольно сильно потеснить С++, хотя полностью не убьет
Memory issues in software comprise a large portion of the exploitable vulnerabilities in existence. NSA advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++, to a memory safe language when possible. Some examples of memory safe languages are C#, Go, Java, RubyTM, and Swift®. Memory safe languages provide differing degrees of memory usage protections, so available code hardening defenses, such as compiler options, tool analysis, and operating system configurations, should be used for their protections as well. By using memory safe languages and available code hardening defenses, many memory vulnerabilities can be prevented, mitigated, or made very difficult for cyber actors to exploit.
Не соглашусь. Шаблоны -- это МЕТАпрограммирование. Это не программирование програмы, а программирования компилятора, чтоб он запрограммировал программу.
Как-то так. Да, исторически шаблоны создавались для обобщённого программирования, но в C++ всё так, что изначально создавалось что-то одно,
а получалось неизменно что-то совершенно другое. Язык действительно эволюционировал за последние лет 30.
V>А теперь, что касается C++. По сути он расширяет возможности Си.
+1 -- это принципиальный момент.
V>Далее лично ты, компания "Рога и копыта" или кто угодно может писать программы на чём хочет.
Если жизненный цикл комплекса ПО составляет более пятилетки, и существует далеко не одна целевая платформа, то
этих чего угодно не так уж и много. Вот агитируют за Rust. Но нет никакой гарантии, что во-первых через
пять-десять лет о нём вообще напрочь все не забудут, и что будут в наличии поддерживаемые компиляторы для нужных
целевых платформ. И самое главное, что сам язык за это время не изменится до неузнаваемости.
V>В общем собака лает, караван идёт. Пока яваскрипты и расты покоряют просторы вселенной где-то рядом...
Где-то рядом C++ и C-код компилируется в webassembly и загружается вместо javascript'а.
Впрочем Rust вроде так же может. Есть ещё одно важное свойство языка подходящего для системного
программирования -- отсутствие "рантайма". У C он минимальный, у C++/Rust чуть побольше
(может даже у C++ больше), но всё равно обозримого размера, позволяющий портирование на новую
платформу своими силами. Про C# такое не скажешь...
V>Есть ещё два мнение отличных от написанного выше. Якобы язык программирования выбирается не из профессионализма программистов, а под задачу. Ещё одно мнение, что всё должно быть модно и хайпово, на результат плевать.
И это правда. C/C++ для старых пердунов которые не хотят учиться ничему новому.
Rust уже тоже, устаревший язык, ему уже больше 12 лет.
Скоро будет один сплошной Carbon и Dart, а старых пердунов выгонят пинками под зад.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, so5team, Вы писали:
S>>>И сейчас больше склонен к выбору C. S>>С чистым Си опыт такой же (1-2 недели)? S>С++ включает в себя C.
Очень условно. C++ программист с ходу не сможет писать хороший C-код и наоборот совершенно точно. Весь нюансы.
Здравствуйте, scf, Вы писали:
scf>Здравствуйте, Wawan, Вы писали:
W>>новая перекличка тех кто С++ не осилил
scf>Ну я осилил, стандарт мог цитировать. Но зачем писать на С++, если производительность труда на Java выше в несколько раз?
А производительность программиста на скриптовых языках -- ещё выше. Про это уже 25 лет назад писалось.
Когда Java ещё и в проекте не было, а её место мог занять Tcl. Но не занял. Но вот задачки до 1000 строк кода, условно,
на нём решаются на порядок быстрей (и каждая строчка заменяет десяток строк на Java). С питоном не хуже думаю,
или с PHP, или с Perl, или с Ruby... Только вот по мере роста объёма кода, статически типизированные языки
начинают выигрывать. А скриптовые вязнут в отладке.
Если этой позиции подходить, то оптимальный вариант: комбинация скриптового языка и статически типизированного.
Где скриптовый выступает в роли "клея" для дискретных компонентов созданных на статически типизированном языке.
Здравствуйте, fk0, Вы писали:
fk0> В переводе на русский -- C++ требует обученных сотрудников, а с языком C -- может кто-то работать "по-совместительству". fk0>Да, но по мере усложнения C-подпроекта он рискует по-сложности обогнать C++. И там действительно будут незаменимые люди. fk0>Потому, что одно дело программа написанная в рамках стандартных средств языка, а другое дело, когда эти стандартные fk0>(и всем понятные) средства заменяются на самодельные аналоги (к чему приходит сложная C-программа). Потому, что ряд fk0>условно сложных концепций он в любой программе существует, не зависимо от языка. Это определяется задачей, а не языком. fk0>И хорошо, если эти сложноть концепций ограничивается в языке или в стандартной библиотеке, а не в коде который нужно fk0>поддерживать. Почему C#/Java и энтерпрайзе и лидируют. Готовая библиотека и язык имеют ответы на многие вопросы.
Ничего не мешает по мере усложнения переписать внутренности на C++, если это усложнение вообще будет и если это будет оправдано. ABI всё равно был, есть и всегда будет на C.
Здравствуйте, fk0, Вы писали:
fk0> Не соглашусь. Шаблоны -- это МЕТАпрограммирование. Это не программирование программы, а программирования компилятора, чтоб он запрограммировал программу.
Обобщённое программирование (англ. generic programming) — парадигма программирования, заключающаяся в таком описании данных и алгоритмов, которое можно применять к различным типам данных, не меняя само это описание.
Сам Бьерн Страуструп в своей книге говорит о шаблонах C++ как об обобщённом программировании. Метапрограммирование не упоминается ни разу.
При определении метапрограммирования лично я прежде всего смотрю есть ли рефлексия.
Отражение (рефлексия; холоним интроспекции, англ. reflection) — процесс, во время которого программа может отслеживать и модифицировать собственную структуру и поведение во время выполнения. Парадигма программирования, положенная в основу отражения, является одной из форм метапрограммирования и называется рефлексивным программированием.
У людей есть ещё представление о метапрограммировании как о продвинутом кодогенераторе. Но это не про шаблоны C++, там простая подстановка без возможности расширения конструкций языка. Более того, давай вспомним о макросах, вот оно где твоё "метапрограммирование".
Но если говорить по существу, то в чистом C++ нет никакого вида метапрограммирования. Программисты уже давно описали подобную ситуацию в книгах, вроде "Чистая архитектура" Мартин Роберт.
Для примера.
1. Может ли программист написать блок, ветвление и цикл на ассемблере как это делают в структурном программировании.
Да, может.
2. А может ли он написать на ассемблере подпрограмму и её подвиды, процедуру, функцию как в процедурном программировании.
Да, может.
3. Может он и класс может написать?
Естественно.
Потому что разница между языками реализующими парадигму и не реализующими не просто в возможности их использовать, а в удобстве их использования за счёт специальных конструкций языка.
В чистом C++ для рефлексии даже не нужен метаобъектный компилятор, можно же прописать всё в ручную и в программе появится точно такой же механизм как при автоматической генерации, позволяющий использовать свойства, методы, интерфейсы и многое другое.
Точно так же люди пытаются реализовать в C++ метапрограммирование за счёт парадигмы обобщённого программирования, ту самую кодогенерацию. Только большинство подобных случаев не упрощают жизнь, а усложняют. И тогда говорят, что парадигма в языке не поддерживается.
Здравствуйте, vsb, Вы писали:
vsb>Ничего не мешает по мере усложнения переписать внутренности на C++
Мешает отвратительная архитектура программы, которая такая получилась вынужденно, потому как банально не было нормальных средств сделать её хорошо на С.
Так что переписывать придётся всё и с нуля, а это дохренища работы, на которую мало кто подпишется из тех, кто решает на что потратить деньги.
Здравствуйте, AleksandrN, Вы писали:
AN>Здравствуйте, Muxa, Вы писали:
M>>Ну, так и почему народ не стал использовать Java вместо плюсов?
AN>Для десктопного софта — стал.
Для декстопного применение JVM довольно маргинально, а вот для серверного — сплошь и рядом.
Правда, честно говоря, это не замена плюсов, потому что их в этой области днем с огнем не сыскать было и раньше
Здравствуйте, velkin, Вы писали:
V> Здравствуйте, fk0, Вы писали:
fk0>> Не соглашусь. Шаблоны -- это МЕТАпрограммирование. Это не программирование программы, а программирования компилятора, чтоб он запрограммировал программу.
V>Шаблоны C++ это обобщённое программирование, что позволяет писать обобщённые алгоритмы. К сожалению в C++ нет метапрограммирования из-за этого его пришлось ввести в Qt за счёт метаобъектного компилятора.
V> парадигма программирования, заключающаяся в таком описании данных и алгоритмов, которое можно применять к различным типам данных, не меняя само это описание.
V>Сам Бьерн Страуструп в своей книге говорит о шаблонах C++ как об обобщённом программировании. Метапрограммирование не упоминается ни разу.
Это информация примерно 20-летней давности, когда только Qt появлялся.
С тех пор C++ сильно уехал вперёд (в основном в C++11). Да, действительно, шаблоны не планировались
для метапрограммирования, оно само так получилось, что получилось. Но сейчас используются именно что для
метапрограммирования. Обобщённое программирование на шаблонах выходит временами так себе (в этом же треде
претензии по объёму генерируемого шаблонного кода).
Метапрограммирование началось тогда, наверное, когда поняли, что условно Class<T> может породить
совершенно разные сущности для неких разных T и U. Обобщённое же программирование предусматривает
одинаковую реализацию класса для всех T, отличающихся только собственно типом и функциями зависимыми
от типа. Краеугольным камнем является возможность специализации шаблона для конкретного типа или
константы параметра и совершенно отдельное определение или функции в таком случаев. Вторым краеугольным
камнем по-моему является SFINAE принцип, позволяющий не ожидать единственного решения заданного
наперёд программистом, а осуществлять выбор из нескольких, возможно не подходящих (что не ведёт к
остановке из-за ошибки, а продолжает поиск).
И разумеется, подразумевается программирование на, повторюсь, _декларативном_ языке шаблонов,
где компилятор самостоятельно ищет решение по заданному набору правил. А не где программист
в императивном стиле описывает последовательность действий.
V>При определении метапрограммирования лично я прежде всего смотрю есть ли рефлексия.
Рефлексия не связана с метапрограммированием. Метапрограммирование -- по-определению это программирование компилятора.
В какой-то ограниченной форме "недорефлексия" в C++ есть (по сравнению, например, с Rust).
В C++ шаблон класса может, например, исследовать данный ему тип или функцию и определить обладает
ли он определёнными свойствами. Выявить, существуют ли в неймспейсе функции или типы с такими-то свойствами,
или может породить новые типы и функции, в том числе добавить в неймспейс. Известны, например, способы
итерации по элементам структур таким образом, что позволяет их (де)сериализацию. Там правда немножко
грязный хак из-за возможности навешивания alignas свойства членам, о чём такой метод окажется не в курсе.
Впрочем последнее много где может дать негативные эффекты и идея исправлять выравнивание у переменной
(но не типа) сама по себе -- порочная. Точно такая же порочная, как packed структуры (когда указатель на
член такой структуры уже не знает об его "упакованности").
V>У людей есть ещё представление о метапрограммировании как о продвинутом кодогенераторе. Но это не про шаблоны C++, там простая подстановка
В шаблонах ни разу не подстановка. Подстановка -- это в C-препроцессоре. Подстановка в C# Generics.
Принципиальное отличие C++-шаблона, что его результат может зависеть от входных аргументов и давать совершенное
разные, не ограничивающиеся подстановкой, результаты для разных аргументов. Это должно быть очевидно глядя на
то, как шаблон может вычислить какую-либо рекурсивную функцию, например сумму или логарифм. В языках где вместо
C++-шаблона есть Generics -- так невозможно.
И да, в C-препроцессоре тоже не совсем подстановка, при определённых обстоятельтвах он тоже может выдавать
результаты зависимые от аргумента (для чего используется способ со склейкой предопределённого имени макроса и скобками) или
что-то считать рекурсивно (совсем уж рекурсивно, бесконечно, не может, но число итераций можно увеличить до достаточно
больших величин). Другое дело, что он не обладает понятием числа, поэтому результаты там -- только текст или списки.
V> без возможности расширения конструкций языка. Более того, давай вспомним о макросах, вот оно где твоё "метапрограммирование".
Без возможности. Метапрограммирование не подразумевает изменение грамматики языка. Метапрограммирование это лишь
о автоматизированном формировании программы на другом языке. Язык шаблонов -- это позволяет. Хотя и не создавался для
этого. Однако сейчас элементы метапрограммирования широко используются стандартной библиотекой и множество новых свойств
C++ без этого были бы невозможны попросту.
V>Но если говорить по существу, то в чистом C++ нет никакого вида метапрограммирования. Программисты уже давно описали подобную ситуацию в книгах, вроде "Чистая архитектура" Мартин Роберт.
Книга в значительной степени об ООП. К метапрограммированию и шаблонам оно никаким боком.
V>Потому что разница между языками реализующими парадигму и не реализующими не просто в возможности их использовать, а в удобстве их использования за счёт специальных конструкций языка.
В том же C++ многие "специальные конструкции языка" часто оказываются библиотечными функциями.
Те же смарт-поинтеры. Они вообще ни разу не часть языка. А, например, корутины без помощи компилятора никак не сделаешь.
Хотя в последнем случае каких-то конструкций особенных не нужно, просто сама кодогенерация меняется.
V>В чистом C++ для рефлексии даже не нужен метаобъектный компилятор, можно же прописать всё в ручную и в программе появится точно такой же механизм как при автоматической генерации, позволяющий использовать свойства, методы, интерфейсы и многое другое.
В ассемблере тоже можно прописать вручную. Но неудобно. Потому появляются такие штуки: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/n4856.pdf
V>Точно так же люди пытаются реализовать в C++ метапрограммирование за счёт парадигмы обобщённого программирования, ту самую кодогенерацию. Только большинство подобных случаев не упрощают жизнь, а усложняют. И тогда говорят, что парадигма в языке не поддерживается.
Шаблоны давно не обобщённое программирование и изначально им толком не было. Это совершенно другое, очевидно любому, кто понимает как они работают.
Обобщённое программирование есть в Rust, например, в C# -- и это другое. Это совершенно иной механизм уступающий шаблонам.
Без которых, повторюсь, половина функционала _современной_ стандартной библиотеки -- не реализуема. В начале 2000-х была другая ситуация,
но сегодня 2022 год, а не 2002, когда C++03 ещё не вышел.
Здравствуйте, Shmj, Вы писали:
S>Возражения?
Скорее всего С++ нас будет ещё долго радовать или "радовать" кому как, а вот С будет заменён Rust который, на мой взгляд, выглядит как более простой язык для решения задач системных уровня, но уже имеющий внутри все наработки и инструменты текущего языкостроения которых не хватает в С.
Здравствуйте, rudzuk, Вы писали:
R>Без комментария в это не просто не въехать
Писать на Rust, а не на С средствами Rust. Эта же проблема и в С++ когда С-шник начинает писать на нём как на С.
Здравствуйте, FR, Вы писали:
FR> Непонятно что мешает на раст написать функцию (лямбду если по месту или макрос если надо развернуть не надеясь на инлайнинг) S и получить точно такой же код как в си?
Покажи уже, как правильно и без потери производительности.
FR> И также что мешает в си засунуть все переменные в структуру (для получения "красивого" self->) и вместо макроса зафигарить такую же красоту по месту как в раст примере?
Ничто не мешает И читаемость не страдает, как по мне.
FR> По моему тут никаких демонстраций особенностей языков нет вообще (кроме более строгих кастов раста), а только демонстрация разных стилей одинаково доступных на обеих языках.
Тут демонстрация того, что в раст встроен обфускатор на уровне языка. Ну правда, ведь невозможно же код читать И это примитивное выражение, а если на метод update посмотреть...
Здравствуйте, rudzuk, Вы писали:
R>А как этот код должен выглядеть по-растовски правильно?
Начнём с того, что и на С код наркоманский и без 0.7 не разобраться что он делает и вообще зачем он вот так написан. Я не спец по Раст, но мне кажется надо как-то макросы тут поюзать.
Здравствуйте, Kernan, Вы писали:
K> Начнём с того, что и на С код наркоманский и без 0.7 не разобраться что он делает и вообще зачем он вот так написан.
Тебе не надо понимать что он делает, нужно просто распарсить выполняемые операции, что в коде на Rust сделать очень не просто (автор не зря там комментарий оставил).
Здравствуйте, FR, Вы писали:
FR> И судя по его коду по твоей ссылке можно было не обертывать при каждом использовании а сразу объявить переменные как Wrapping<u8> тогда свертки развертки не нужны. В таком случае все совсем просто будет, практически как на си: FR>
FR> use std::num::Wrapping;
FR> fn main() {
FR> // начальные переменные
FR> let s = [Wrapping(10u8); 256];
FR> let (i, j, k) = (Wrapping(250u8), Wrapping(250u8), Wrapping(250u8));
FR> let mut z = Wrapping(250u8);
FR> // сам код
FR> let S = |a: Wrapping<u8>| s[a.0 as usize];
FR> z = S(j + S(i + S(z + k)));
FR> dbg!(z);
FR> }
FR>
Клево!
FR> R>Покажи уже, как правильно и без потери производительности.
FR> Судя по ассемблерному коду тут оптимизируется вусмерть.
Не, так не интересно, он там все соптимизировал во время компиляции. А можно пример, где компилятор будет реально по индексам читать?
FR> Ну нет для полноты картины надо без макроса, как автор кода на расте, мы же на стили хотим посмотреть.
FR> То есть компилятор смог понять что выходов за границы массива не будет и выкинул все проверки. FR> Вот если вместо let s = [Wrapping(10u8); 256]; сделать например let s = [Wrapping(10u8); 25]; то есть длина массива меньше 256 то добавятся проверки на границы и плюс пропадет инлайнинг замыкания.
А как будет выглядеть этот код (и асм), если регистровые переменные (i,j,k,z) будут не байтовыми, а в размер регистров cpu (u3232, u64)?
fk0> Шаблон -- это лишь некоторое правило для компилятора. Он ни к чему не обязывает, в частности к генерации "раздутого кода". fk0>Как им воспользуются, и что из этого получится -- зависит от программиста, а не от шаблонов вообще.
Разумеется. Так-то я то же самое утверждал: нет ничего плохого в шаблонах, а только лишь в неумеренном злоупотреблении оными.
fk0> Простейший пример: попытка сделать самодельный аналог STL-контейнера, например, вектора. fk0>Подход в лоб даст тот самый эффект, что на каждый тип компилятор порождает всё новые инстансы fk0>одних и тех же функций (может быть, даже буквально совпадающих в ассемблере). Если за задачу fk0>возьмётся студент, так наверное и выйдет. Если возьмётся немного более опытный программист, то
Если возьмётся опытный программист, или небольшая группа таковых, то всё будет хорошо. Когда же за дело берутся "цыгане шумною толпою", то получаются нездорово раздутые бинари, как это часто, например, получается у Facebook.
Здравствуйте, zx zpectrum, Вы писали:
fk0>> Простейший пример: попытка сделать самодельный аналог STL-контейнера, например, вектора. fk0>>Подход в лоб даст тот самый эффект, что на каждый тип компилятор порождает всё новые инстансы fk0>>одних и тех же функций (может быть, даже буквально совпадающих в ассемблере). Если за задачу fk0>>возьмётся студент, так наверное и выйдет. Если возьмётся немного более опытный программист, то ZZ>Если возьмётся опытный программист, или небольшая группа таковых, то всё будет хорошо. Когда же за дело берутся "цыгане шумною толпою", то получаются нездорово раздутые бинари, как это часто, например, получается у Facebook.
Совершенно не факт, что дело вообще в шаблонах или в C++. Может там в бинарях ресурсы в виде png картинок.
Здравствуйте, Privalov, Вы писали:
P>Я видел женщин — системных программистов. Большинству мужиков у них учиться и учиться. Я, кстати, тоже у них кое-чему научился.
Здравствуйте, lpd, Вы писали:
lpd>Получается: если нужно написать программу хорошо — используйте С;
На чистом C сложно хорошо написать программу. И это будет очень небыстро
lpd>если нужно написать хорошо прикладную программу — C++;
lpd>если нужно написать быстро — Java; если под винду — C#; если программа уже написана, но у вас странные наклонности — Rust/Go/...
Я как-то под андроид писал — там всего ничего, на плюсах за гнднлю бы сделал, а так — пришлось пару месяцев сражаться с этой джавой
С слову, точно также мне нужно было написать на шарпе под вин мобайл прогу. Условия были те же практически — ни с тем ни с другим я до того не работал. С шарпом получилось гораздо быстрее. Это при том, что под андроид я писал чисто локальное приложение, а на шарпе мне нужно было с удалённой БД общаться
Здравствуйте, Shmj, Вы писали:
S>Можно сказать опыт — около 1-2 недели. Переводил библиотеку с С++ на C#, но приходилось только читать и то не очень долго. Второе — это писал небольшую утилиту, по-моему дня на 3 работы.
S>Но и этого хватило чтобы понять насколько глубока кроличья нора
А, вопросов больше не имею
S>Сейчас предлагают мне повысить свой уровень и сделать средней сложности проект — как раз выбор между этими двумя. Есть причина, почему не подходит Java, .Net и Dart.
S>И сейчас больше склонен к выбору C. Тем более что для него есть все библиотеки, практически нет нужды в ++.
Здравствуйте, zx zpectrum, Вы писали:
ZZ>Если возьмётся опытный программист, или небольшая группа таковых, то всё будет хорошо. Когда же за дело берутся "цыгане шумною толпою", то получаются нездорово раздутые бинари, как это часто, например, получается у Facebook.
А ты представляешь, что цыгане могут сделать на чистой сишечке? Подскажу — ничего. Оно у них даже если и скомпилится, то работать не будет
M>А можно поподробнее про распухание? А то может оказаться, что кроме распухания происходит и спухание — когда на этапе линковки одинаковый код не дублируется.
LTO, да-да, понятное дело. А потом какие-нить грамотеи проект разобьют на динамические библиотеки, в которых до черта предкомпилированных специализаций:
а) тюленями
б) оленями
в) пельменями
г) существами, издалека напоминающие людей
д) существами, которые объявили войну
е) сказочными
ж) бродячимим собаками
з) включёнными в эту классификацию
и) бегающими как сумасшедшие
к) бесчисленными
л) нарисованными тончайшей кистью из верблюжьей шерсти
м) прочими
н) разбившими цветочную вазу
о) похожими издали на мух
, и их уже просто так линковочной оптимизацией не выковыряешь.
M>А многосотмегабайтные бинарники (ты, кстати, о чем) — они обычно от того, что туда засунуто до черта функционала. Сишечные бинарники будут сравнимых размеров
Ну тогда покажите мне хоть одну, сравнимую с libcurl по функциональности, http(s)–клиентскую библиотеку на "развесистых" языках (C++, Rust, Swift и т.д.) схожего размера в компилированном виде. Если бы было так, как Вы говорите, то на C уже и embedded не писали бы, и ядро linux. Дело-то не только в человеческой инерции, как это многие пытаются себе представить.
M>И чего? На плюсах такое что, не написать?
Конечно написать. Если за дело возьмётся специально обученная группа высочайшей квалификации. "Цыгане шумною толпою", нанятые по объявлению — не напишут.
M>А ты представляешь, что цыгане могут сделать на чистой сишечке? Подскажу — ничего. Оно у них даже если и скомпилится, то работать не будет
Подскажу — GNU/Linux. Цыганами ведь метафорично можно обозвать не только "Фейсбучную въетнамскую швейную фабрику", но и ГНУтый "базар вместо собора".
Здравствуйте, zx zpectrum, Вы писали:
M>>А ты представляешь, что цыгане могут сделать на чистой сишечке? Подскажу — ничего. Оно у них даже если и скомпилится, то работать не будет ZZ>Подскажу — GNU/Linux. Цыганами ведь метафорично можно обозвать не только "Фейсбучную въетнамскую швейную фабрику", но и ГНУтый "базар вместо собора".
Ну ты тут в соседнем сообщении написал про "цыган, набранных по объявлениям" — хочешь соврать, что ядро линупса пишут именно такие?
Или таки эти цыгане на самом деле квалифицированные разработчики?
Нашел
Просто у тебя только что цыгане были синонимом неумелых неквалифицированных программистов:
Если возьмётся опытный программист, или небольшая группа таковых, то всё будет хорошо. Когда же за дело берутся "цыгане шумною толпою", то получаются нездорово раздутые бинари, как это часто, например, получается у Facebook.
Может тогда не будем всех и вся называть цыганами?
Кстати, KDE — гораздо более молодой, чем GNOME — написан на плюсах. А работает гораздо приятнее
И да, не хочу тебя сильно травмировать, но основной компилятор GNU — GCC — переписывают на плюсы. Видимо, тащить его на сишечке уже больше нет сил
Здравствуйте, 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.
Дилетант это, а не "авторитет", гоните его ссаными тряпками! 
И читаемость не страдает, как по мне.
