LINUX.ORG.RU
ФорумTalks

Опрос: Три-пять лучших фич C++

 , ,


3

4

Поскольку я с недавних пор устроился на работу, то простыни временно закончились. Тем не менее, каждый раз при работе с сишным кодом снова и снова всплывает мысль «блин, как же здесь не фатает крестов». Но в остальном сишки мне более чем хватает, мне не нужны геттеры-сеттеры, классы-интерфейсы под single responsibility, и прочая мура. Пару источников вдохновения:

https://google.github.io/styleguide/cppguide.html
https://yosefk.com/c fqa/

Итак, назовите от трех до пяти фич крестов, которые бы вы взяли с собой на необитаемый остров Си. Можно несуществующие или из будущих стандартов. А я чуть позже назову те, которые взял бы я. (назвал)

И да, я в курсе, что где-то год назад ведьмак создавал тред на схожую тему, но мое знание крестов с тех пор выросло настолько, что меня чуть не взяли работать крестовиком. Так что теперь тред вести буду я. Как обычно, «для себя из прошлого», чтоб гештальты позакрывать.

Итоги по состоянию на 24.12.2021 22:00 (MSK): https://pastebin.com/bxamaGDY

★★★★

Последнее исправление: byko3y (всего исправлений: 6)
Ответ на: комментарий от no-such-file

Я работал на крестах, и вообще начинал с Си/С++ потому что в те времена не было никаких пыхов

Погоди, тебе сколько годиков-то будет? Хотя бы по десяткам.

byko3y ★★★★
() автор топика
Ответ на: комментарий от X512

Классы в Javascript есть. Прототипное ООП и всё такое

Неа, это не классы C++.

Синтаксис вполне типичный для классов object.method(args)

Эта аналогия притянута за уши и обманчива. this в JS бывает очень коварным.

byko3y ★★★★
() автор топика
Ответ на: комментарий от abcq

пример вы сами привели

это не я их привел. я показал как можно облегчить себе жизнь если отсутствие конкретной фичи воспринимается так ужасно, што аж кушать не можешь.

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

olelookoe ★★★
()
Ответ на: комментарий от X512

Про Лисп я слишком мало чего знаю чтобы о нём судить. Не писал на нём

Smalltalk?

byko3y ★★★★
() автор топика
Ответ на: комментарий от no-such-file

Естественно. ЛИСП вообще много чего первым реализовал

Ну так и я о том. Многие всерьёз считают, что классы придумал Страуструп. А он ничего не придумал, он просто криво скомпоновал имеющиеся решения под запросы рыночка.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Неа, это не классы C++.

И что? Мир ограничивается одним только C++? Больше нигде классов по определению быть не может?

this в JS бывает очень коварным.

Там вроде для этого strict mode придумали.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от byko3y

Ну, пятый десяток пошёл. Конкретно на крестах я работал 20-15 лет назад. А прикасался последний раз лет 6 назад. Но слежу на повесточкой, да.

no-such-file ★★★★★
()
Ответ на: комментарий от luke

Имхо лучший Си это современный Паскаль, единственное, что регистрозависимости не хватает

Прискорбно вынужден признать, что Паскаль почти не развивается. Может быть паскалевы идеи и развиваются в форме Оберона, но у меня есть большие сомнения по этому поводу.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Прискорбно вынужден признать, что Паскаль почти не развивается.

Развитие ради развития? Ну это как раз к C++.

X512 ★★★★★
()
Ответ на: комментарий от no-such-file

Ох нифига себе. То есть, ты в 50 регулярно бегаешь и у тебя сердце не отваливается? Последний раз я подобного кадра видел в каком-то блоге, назывался как-то вроде «волк нот» или что-то подобное.

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от X512

Там вроде для этого strict mode придумали

Strict mode просто дает this === undefined в тех же неудобных ситуациях, делая их чуть менее неудобными.

byko3y ★★★★
() автор топика
Ответ на: комментарий от X512

Прискорбно вынужден признать, что Паскаль почти не развивается.

Развитие ради развития? Ну это как раз к C++

Вывод типов? Развитые базовые типы и контейнеры?

byko3y ★★★★
() автор топика
Ответ на: комментарий от rumgot

Можно ли там иметь свой тип контейнера со своим типом элементов или хотя бы стандартный контейнер с пользовательским типом элементов и засовывать его в стандартные алгоритмы?

Сложно, но можно. Там так-то стандартные контейнеры по большей части на самом Go и написаны, только отдельными гвоздями они прибиты к компилятору. А в остальном ты можешь писать свои контейнеры, только это сложно и (не так гибко и/или полиморфно и/или быстро выполняется), как стандартные.

По поводу JS еще куда ни шло (хотя это в основном фронт в вебе - а это еще далеко не вся индустрия)

Уже давно не только фронт.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Но ООП сделали в смолтоке, правда в связи с убогостью (тормознутостью) компов в те времена и фиговыми компиляторами парадигма прижилась, но не так как задумана (ООП должен вокруг сообщений работать, которые полноценный объект со всеми вытекающими, но по факту это очень медленно, а компиляторы научить это упрощать никто не осилил). Потому у ООП и проблемы идут в виде кучи костылей.

peregrine ★★★★★
()
Ответ на: комментарий от peregrine

Но ООП сделали в смолтоке, правда в связи с убогостью (тормознутостью) компов в те времена и фиговыми компиляторами парадигма прижилась, но не так как задумана

На самом деле прижилась, и так как задумано, но в Erlang.

byko3y ★★★★
() автор топика
Ответ на: комментарий от peregrine

Я бы не сказал что эта идея с сообщениями удачная, даже если не учитывать производительность. Тот же Objective C по мне выглядит совершенно непонятно и неинтуитивно.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от byko3y

То есть, ты в 50 регулярно бегаешь и у тебя сердце не отваливается

Пятый десяток, это 40+, а не 50. И эти люди что-то там программируют!

регулярно бегаешь и у тебя сердце не отваливается

Чё б ему отваливаться? В первую очередь отваливаются ноги, если ты не в курсе.

Впрочем, не вижу большой разницы, 40 или 50. Когда за 70 там уже да, нет так всё просто. Хотя на последнем ЧР для пенсеров, чувак в 81 год десятку за 49 с копейками бахнул. Вот это терминатор, реально.

no-such-file ★★★★★
()
Ответ на: комментарий от necromant

namespace

Господа, вам не кажется, что namespace — это тупо костыль под отсутствием модулей? То есть, если появится возможность импортировать модуль с «автоматическим неймспейсом», то все эти приседания с ручным описанием онных станут просто бессмысленными?

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

тупо костыль под отсутствием модулей

Почему не наоборот? Модули это тупо костыль за отсутствием неймспейсов.

no-such-file ★★★★★
()
Ответ на: комментарий от byko3y

Классы — это абстрактное непонятно что, на которое навешивается куча разных парадигм…

Хер знает кого мнение. И почему этот аргумент должен иметь вес.

Ответ: не эффективно, а тратить время нужно для того, чтобы научиться делать это эффективно. Беда многих военачальников в том, что они думают, будто их приказ «пойти в наступление» выиграл войну. А на самом деле если бы они приказали «отступить», то тоже бы выиграли войну. И если бы ничего не приказывали, а только пьянствовали с путанами, то все равно бы выиграли войну.

Как я и говорил: разные парадигмы дают один результат.

Разница проявляется только в жестких пограничных условиях, когда лишнее время компиляции значит

Время компиляции не настолько критично. Обычно не перекомпилируется весь проект. Я уже это писал тебе, но ты это проигнорировал.

Вот возьми Instagram — отвратительная реализация, глубокой финансово уботычный сервис. Но его продали, и разрабы по итогу остались в плюсе, какое бы питонье говно они там не написали. Самое главное — они застолбили эту нишу первыми.

Да на чем бы он не был. Один хер был бы. И при чем здесь вебня к C++ ?

Я боюсь, что это тема обсуждения целого нового треда. Qt писался на очень старых крестах, еще до STL, он не мог быть другим.

И что с того? Ты предлагаешь его переписать без ООП или нет?

GPGPU как бы говорит, что ты не прав, потому что по скорости выполнения уделывает твой алгоритм на ЦП в 100 раз.

Когда все программы перейдут на него полностью вместе с самой ОС, так что ничего не останется на CPU - тогда и поговорим. Сейчас на него переводится не весь функционал приложения, а только некотрая его часть. И собственно нет ни одного технически обусловленного ограничения, которое не позволяет использовать ООП в GPU программах.

rumgot ★★★★★
()
Ответ на: комментарий от byko3y

Очень даже кажется. Всё это убожество по сравнению с Обероновкими модулями.

X512 ★★★★★
()
Ответ на: комментарий от rumgot

От одного заголовочника обычно не зависят все единицы трансляции в проекте. А если зависят, то в нем есть некий публичный интерфейс, который должен меняться крайне редко

По этой причине все крестовики надрессированы приседать, чтобы до последнего избегать модификации широко используемых заголовков. Просто потому, что в крестах по факту нет никакого private, единственный способ написать приватную реализацию — это сишные предварительные объявления указателей на непрозрачные структуры.

byko3y ★★★★
() автор топика
Ответ на: комментарий от no-such-file

Почему не наоборот? Модули это тупо костыль за отсутствием неймспейсов

Но неймспейсы есть, а модулей нет. Совпадение? Не думаю.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

В плюсах ровно тот private, который в нем есть, т.е. тот который не про сокрытие, а про доступ.

Ну и через указатели и че с того?

rumgot ★★★★★
()
Последнее исправление: rumgot (всего исправлений: 1)
Ответ на: комментарий от rumgot

Да на чем бы он не был. Один хер был бы. И при чем здесь вебня к C++ ?

При том, что подход «грамотно и очень долго писать проект» актуально дай бог если для 1% проектов в индустрии. Вот это и вся ниша C++.

Ты предлагаешь его переписать без ООП или нет?

Предлагаю, но это будет не Qt, и желающих в этом участвовать нет. Поддержка ООП в 90-х была чисто маркетинговым ходом, Qt высплыло потому, что любой проект в то время бы нашел поддержку, только лишь заявив про объектную ориентированность. Но давай не путать социальную составляющую с технической.

И собственно нет ни одного технически обусловленного ограничения, которое не позволяет использовать ООП в GPU программах

Там на половине девайсов нет классического стэка и поддержки рекурсий — как тебе такой сюрприз?

byko3y ★★★★
() автор топика
Ответ на: комментарий от rumgot

Ну и через указатели и че с того?

А то, что чисто сишный проект за счет приватных реализаций в среднем требует меньше перекомпиляций модулей. чем крестовый. Компиляция в крестах и так медленная, а отсутствие приватных объявлений усугубляет эту проблему.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Бля который раз пишу. Редко в проекте все единицы транссляции зависят от одного хедера. А если и зависят, то он редко меняется. Тупой аргумент.

rumgot ★★★★★
()
Ответ на: комментарий от Legioner

Там подразумевалось myobject_somefunc(obj, x, y)

А, тогда твоя позиция ясна. Проблема в том, что эдак половина функций обычно являются межобъектными и надобъектными, то есть, нужно не вызывать метод объекта, а вызывать функцию с объектом в качестве аргумента. Соответсвенно, получается somefunc(obj, x, y). А вот по поводу неймспейсов уже можно спорить.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

1%

Хер. Количество вакансий говорит об обратном.

Предлагаю, но это будет не Qt, и желающих в этом участвовать нет.

И правильно. Ведь один хер тоже самое, но без ооп. Но только в итоге x2 про трудозатратам.

Поддержка ООП в 90-х была чисто маркетинговым ходом

Точно также как сейчас последовавшие за ооп парадигмы.

Но давай не путать социальную составляющую с технической.

Я тебе уже в который раз пишу, что парадигмы в принципе - это субъективно и вопрос пристрастия, я не про технически обусловленную сущность. Там на половине девайсов нет классического стэка и поддержки рекурсий — как тебе такой сюрприз?

И что? Какая-то особенность видеокарт мешает раелизовать ооп в соответствующем api? Да даже в glsl матрицы и векторы - это объекты.

rumgot ★★★★★
()
Ответ на: комментарий от rumgot

И правильно. Ведь один хер тоже самое, но без ооп. Но только в итоге x2 про трудозатратам

Вообще-то проводились практически испытания. Писать с нуля абсолютно столько же времени, классы не ускоряют разработку. Где классы себя проявляют — так это при необходимости серьезных изменений готового приложения. Просто прикинь, насколько весело будет поменять базовые классы Qt.

Я тебе уже в который раз пишу, что парадигмы в принципе - это субъективно и вопрос пристрастия, я не про технически обусловленную сущность

То, что предпочтения в парадигмах социально обусловлены, не значит, что парадигмы и просто отдельные подходы к написанию софта не могут быть лучше других.

Какая-то особенность видеокарт мешает раелизовать ооп в соответствующем api? Да даже в glsl матрицы и векторы - это объекты

Такими темпами ты и в асме увидишь ООП.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Может. Но тогда получается, что у всей индустрии маразм — что есть весьма близко к реальности, потому что как еще объяснить такую страсть к подражанию ООП Алана.

А какого хера у остальной части страсть к любому новомодному течению? Потому что обыденность и скука? Скучно стало?

Какие еще факты тебе нужны?

Как минимум в виде популярности языка в виде авторитетных ресурсов(tiobe) и большом количестве вакасний. И кстати если вакасний мало, то по закону рынка зп не будет очень уж высокой.

«Уже нет» — поправил. Я сам Maemo пользовался.

Ну и? Нет и нет. Звонить то надо и в тырнете сидеть. А яблоко со своими забаббонами в виде костылей при обычном копировании файла на устройство идет вообще подальше.

rumgot ★★★★★
()
Ответ на: комментарий от byko3y

Вообще-то проводились практически испытания. Писать с нуля абсолютно столько же времени

Да. Именно. Я ведь учитываю время УЖЕ затраченное на разработку.

То, что предпочтения в парадигмах социально обусловлены, не значит, что парадигмы и просто отдельные подходы к написанию софта не могут быть лучше других.

Но и не значит, что могут быть хуже других.

Такими темпами ты и в асме увидишь ООП.

Стояночка. В glsl есть vec4/mat4 и есть умножение между ними. Это как минимум анолог перегрузки оператора умножения в C++ с разными типами. Это не элемент ООП ?

rumgot ★★★★★
()
Последнее исправление: rumgot (всего исправлений: 1)
Ответ на: комментарий от byko3y

Да, сейчас за объектно-ориентированным надо идти в социологию.

luke ★★★★★
()
Ответ на: комментарий от byko3y

Дуглас Крокфорд

Бля, вспомнил. Так этот дебил, который комментарии не сделал для json. Сказочный дол**е6. Ну конечно он за ошибки в рантайме вместо компалтайма. js головного мозга.

Это кстати иллюстрация причины, по которой в стандарты попадают те или иные технологии: решает не самый талантливый или умный, а самый громкий.

rumgot ★★★★★
()
Последнее исправление: rumgot (всего исправлений: 1)

Очередной топик из серии «я не такой как все». Ищи вторую работу, все ещё дохуя свободного времени.

filosofia
()
Ответ на: комментарий от filosofia

Вот это вот «не такой как все» даже в второго ведьмака запихнули.

rumgot ★★★★★
()
Ответ на: комментарий от olelookoe

Ну тут такое дело, ТС уже не первый раз облизывается на С++ т.к. чистый С все-таки удовольствие не для слабонервных, хотя опять же ТС при анонсе своего проекта обронил фразу, что выбрал С потому что так принято. Я уже 10 сообщений назад написал, что никого не принуждаю, конечно пишите как хотите и на чем хотите. Тут скорее риторический вопрос, «зачем», когда есть альтернативы которые уже сделали выводы из С и кто как смог, попытался его улучшить в своем исполнении.

abcq ★★
()
Ответ на: комментарий от i-rinat

то есть арифметические действия нужны, потому что дизайн ЯП без них кривой до состояния неюзабельности?

тюуууу!

Без арифметики вообще никак и она диктует свои законы для синтаксиса и внутренней реализации!

deep-purple ★★★★★
()
Ответ на: комментарий от i-rinat

1. Наличие классов не означает необходимости конструкторов. Есть другие «более хорошие» механизмы для порождения объектов.
2. Да. 3 года из 6 писал именно без исключючений.
3. Qt вместо стандартной библиотеки - считается?


P.S.
Я надеюсь вы согласитесь, что после того как я ответил на ваши вопросы, будет честно ожидать от вас ответа на мой вопрос.

trex6 ★★★★★
()
Ответ на: комментарий от i-rinat

Но допустим, что из системы классов убираются конструкторы и исключения, а, видимо, всё остальное остаётся. Как это будет выглядеть?

Мне кажется, что проблема с конструкторами и исключениями очень элегантно решена в Rust.

P.S. Для растохейтеров специально отмечу, что я не пытаюсь сказать, что Rust лучше C++. Но именно эта проблема там решена хорошо. Более того, подобное решение проблемы можно успешно примеять и в C++ разработке, зафиксировав его на уровне codestyle или другого подобного документа.

trex6 ★★★★★
()
Ответ на: комментарий от i-rinat

Я уверен, что не только я смогу привести вам примеры успешных языков программирования в которых нет исключений.

Готовы ли в ответ привести примеры успешных языков программирования без арифметических действий?

trex6 ★★★★★
()
Последнее исправление: trex6 (всего исправлений: 1)
Ответ на: комментарий от byko3y

Вот какие есть хорошие задачи, которые они умеют выполнять?

Корутины удобно использовать при написании серверов, большая часть работы которых сводится к обращению к внешним ресурсам (диск, сеть). Без них тоже можно «наколхозить», но с ними получается выразительнее. Сложность, к сожалению, тоже растет (и не факт что пропорционально). Так что вопрос их полезности до конца не закрыт.

trex6 ★★★★★
()
Ответ на: комментарий от NAY_GIGGER

rtti

лучше бы рефлексию завезли прямо на уровне стандартов вместо этого.

bhfq ★★★★★
()
Ответ на: комментарий от byko3y

в 21-ом веке основная проблема — это трудоемкость написания кода мартыхами, а не скорость выполнения инструкций

Так было до тех пор, пока выполнялся закон Мура. На наших глазах происходит разворот обратно. Индустрия уже начинает ощущать нехватку процессорных мощностей на самых разных уровнях. И вопрос не удается решить просто потратив больше денег на железо. Физика - она дама бессердечная. Совершить этот разворот за 2-3 года конечно же не удастся, но я готов спорить на бутылку хорошего виски или коньяка, что через 10 лет результаты этого разворота будут видны всем.

P.S. В качестве примера можно вспомнить о WebAssembly. Это не единственный, но важный пример.

trex6 ★★★★★
()
Ответ на: комментарий от trex6

Наличие классов не означает необходимости конструкторов. Есть другие «более хорошие» механизмы для порождения объектов.

Кавычки вокруг «более хорошие» очень хорошо обрисовывает костыльность этих механизмов.

Qt вместо стандартной библиотеки - считается?

Соболезную. Если долго писать на Qt, особенно если с этого начинать, может сложиться впечатление, что всеми способами избегать конструкторов в Си++ это нормально. Может сложиться впечатление, что ожидать от аллокатора всегда не-NULL ответа в основе языка — нормально. Но, хотя это может показаться странным, это не так.

будет честно ожидать от вас ответа на мой вопрос

Легко. Чтобы классами можно было пользоваться для создания любых программ. Конечно, можно выбросить конструкторы и выбросить исключения, но тогда добавленное в Си окажется не более, чем небольшим упрощением. Всё, чего получится добиться — вместо class_name_method_name(obj, params) можно будет писать obj.method_name(params).

Предлагаю подумать, что понадобится изменить в Qt, если захочется сделать из него надёжную основу для программирования. Для этого необходимо обработать ситуацию с нехваткой памяти.

i-rinat ★★★★★
()
Ответ на: комментарий от trex6

проблема с конструкторами и исключениями очень элегантно решена в Rust.

В Rust решили, что если программа не может выделить память, то она падает в панику. Это тоже элегантное решение? Если притащить это в Си или Си++, теряется смысл Си и Си++. Насколько я понимаю, placement new в Rust нет. По крайней мере, он плохо ложится в общую картину.

зафиксировав его на уровне codestyle или другого подобного документа

Вот это хорошая оговорка. На уровне coding style. А не на уровне языка.

i-rinat ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.