Здравствуйте, AleksandrN, Вы писали:
AN>Для десктопного софта — стал.
Разишо только внутриэнтерпрайзненько, потому что там чо дали то и будут жрать.
А вот для enduser-ей как то жабасофта не видно и не слышно
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, scf, Вы писали:
scf>Ну я осилил, стандарт мог цитировать.
Не, знание стандарта, это как #барь-теоретик — знает чем, знает как, знает куда, а вот на практике на полшестого
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
NB>>а разреши вопрос, какой у тебя опыт практической работы с C++? CC>Я думаю это риторический вопрос
Можно сказать опыт — около 1-2 недели. Переводил библиотеку с С++ на C#, но приходилось только читать и то не очень долго. Второе — это писал небольшую утилиту, по-моему дня на 3 работы.
Но и этого хватило чтобы понять насколько глубока кроличья нора
Сейчас предлагают мне повысить свой уровень и сделать средней сложности проект — как раз выбор между этими двумя. Есть причина, почему не подходит Java, .Net и Dart.
И сейчас больше склонен к выбору C. Тем более что для него есть все библиотеки, практически нет нужды в ++.
V>Когда используешь обобщённое программирование производительность не снижается по сравнению с Си, так как происходит генерация новых функций и классов по шаблону. Зато это позволяет не переписывать код, что не может Си.
Рассуждения в целом верны, однако есть одно "но". Bloating. Распухание бинаря. Возникает сие явление, понятное дело, не от шаблонизации вообще, а исключительно от неумеренного злоупотребления оной. Многие скажут: ну распухание и распухание, что такого-то, RAM–то в наши времена немеряно. Но-но, охладите пыл, и попробуйте задуматься вот о чём: плотный маленький бинарь имеет гигантское преимущество в сравнении с рыхлым и раздутым в плане промахов по кешу инструкций. Вспоминаем основополагающий текст "RAM больше не RAM", нарастающий год от года отрыв кэша от RAM в скоростях и латентностях, а потом суровую практику, многосотмегабайтные бинарники, раздутые от семиэтажных шаблонов, и сверяемся с циферками кэшей: даже самый медленный третий уровень в наши времена что-то около 20 мегабайт, если не ошибаюсь. Ясен пень, не на один процесс, а на всех.
Было дело, QNX хвастался тем, что их плотное минималистичное ядро целиком влезает в L2–кэш, и это вроде как даёт преимущества не только и не столько в скоростях, сколько в детерминизме, так необходимом в системах реального времени.
V>Понимаешь теперь почему Си нельзя убить? Потому что сами операционные системы написаны на нём. Полная совместимость. Можешь даже думать об этом как об улучшенном ассемблере.
Этот верный довод красивее всего формулируется так: "Си теперь не язык, а lingua franca. Наподобие латыни у врачей у юристов. На ней не говорят, но она никуда не денется".
Я в смешанных противоречивых чувствах.
S>Можно сказать опыт — около 1-2 недели. Переводил библиотеку с С++ на C#, но приходилось только читать и то не очень долго. Второе — это писал небольшую утилиту, по-моему дня на 3 работы. S>Но и этого хватило чтобы понять насколько глубока кроличья нора
Поверь, не хватило. Это твоё эго говорит тебе, что хватило
S>Сейчас предлагают мне повысить свой уровень и сделать средней сложности проект — как раз выбор между этими двумя. Есть причина, почему не подходит Java, .Net и Dart.
Если предлагают — берись, учись, делай. С++ — изумительный язык.
S>И сейчас больше склонен к выбору C. Тем более что для него есть все библиотеки, практически нет нужды в ++.
Тебе уже здесь сказали, что бардак — от программиста, а не языка. Да, С++ много позволяет программисту, потому требует от него профессионализма. Если ты что-то не умеешь в нём, просто запрети себе на данном этапе это использовать, например, написав style_guide или coding_standard для конкретного проекта, если нет общего в компании, Да даже если и есть, никто не запретит тебе конкретизировать/уточнить/расширить/сузить фирменные стандарты для применения в твоём проекте.
Здравствуйте, Shmj, Вы писали:
S>И сейчас больше склонен к выбору C. Тем более что для него есть все библиотеки, практически нет нужды в ++.
Думаю что с того же C# проще всего будет перейти на вариант C++ который называется "Си с классами", то есть используются классы + стандартная библиотека, и никаких или по самому минимуму шаблонов и современного сахара в клиентском коде. Дельфисты в свое время вполне успешно и быстро переходили на такой вариант. И да это будет проще чем перейти с C# на чистый си.
Здравствуйте, ry, Вы писали:
ry>Тебе уже здесь сказали, что бардак — от программиста, а не языка. Да, С++ много позволяет программисту, потому требует от него профессионализма. Если ты что-то не умеешь в нём, просто запрети себе на данном этапе это использовать, например, написав style_guide или coding_standard для конкретного проекта, если нет общего в компании, Да даже если и есть, никто не запретит тебе конкретизировать/уточнить/расширить/сузить фирменные стандарты для применения в твоём проекте.
Это правильный подход.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, 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.
Здравствуйте, 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 и недошаблоны, что сильно лучше, чем ничего.
Не соглашусь. Шаблоны -- это МЕТАпрограммирование. Это не программирование програмы, а программирования компилятора, чтоб он запрограммировал программу.
Как-то так. Да, исторически шаблоны создавались для обобщённого программирования, но в 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, а старых пердунов выгонят пинками под зад.
Здравствуйте, 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) гарантирующий обработку в порядке
очерёдности.
Здравствуйте, 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 и энтерпрайзе и лидируют. Готовая библиотека и язык имеют ответы на многие вопросы.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, vsb, Вы писали:
vsb>>Ну мне надо код писать и поддерживать, а не С++ осиливать. С кодом на С я знаю, что я его могу дать любому программисту, который С когда-то учил в университете и он этот код поймёт и сможет поддерживать и что-то по мелочи дописывать. CC>И будет получаться запутано, бойлерплейтненько и всё в трудноуловимых багах, потому что тут недосмотрел, здесь недодизайнил. CC>Си от асма недалеко ушёл. Таки да, сам то язык простой, но вот чтоб таки на нём писать чистый код надо много опыта и силы воли. У каждого пейсателя.
Да, язык C провоцирует к спагетти-коду, полному глобальных переменных и зависимостей основанных на данных (вместо того, чтоб
выделить интерфейс и его использовать, напрямую лезут в чужие структуры данных). Такой код поддерживать тяжело и дорого, рефакторить
практически невозможно, часто оно годится чтоб выкрасить и выбросить только...
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, so5team, Вы писали:
S>>>И сейчас больше склонен к выбору C. S>>С чистым Си опыт такой же (1-2 недели)? S>С++ включает в себя C.
Очень условно. C++ программист с ходу не сможет писать хороший C-код и наоборот совершенно точно. Весь нюансы.
