если брать все же все основные возможности языка, включая стандартную библиотеку то Си++ очень сильно сдает позиции. В отличии от Го который остается на примерно том же уровне.

Т.е. предпочитаешь плюсы, а не C?

да

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

если брать все же все основные возможности языка, включая стандартную библиотеку то Си++ очень сильно сдает позиции. В отличии от Го который остается на примерно том же уровне.

ну про с++ тут еще вопрос какой стандарт рассматривать но изначально да — вопрос был про минимальный сабсет

ну про с++ тут еще вопрос какой стандарт рассматривать но изначально да — вопрос был про минимальный сабсет

не имеет значения, 98 чуть лучше.

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

Ну, не знаю, видимо мне плюсы не зашли, по мне C лучше =)

Ну, не знаю, видимо мне плюсы не зашли, по мне C лучше =)

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

сеттеры-геттеры туда же

сам файл начинает выглядеть как класс, без класса только

ну и вопрос в том - нахрена это надо, когда есть плюсы где это семантически более органично?

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

Видимо дело в применении. Для меня C - это когда есть узкое место и надо что-то с ним делать, тогда import "C" и вперед. А чисто на C давно уже не пишу =)

ну и вопрос в том - нахрена это надо, когда есть плюсы где это семантически более органично?

а потом ты вспоминаешь про сборку мусора и пуреполнение буфера впрочем, для C тоже есть смартпоинтеры, вроде, и точно есть умные буфера

а потом ты вспоминаешь про сборку мусора и пуреполнение буфера впрочем, для C тоже есть смартпоинтеры, вроде, и точно есть умные буфера

В мире сей есть всякая фигня типа glib и его gobject

Объекты, наследование, интроспекция. На сях.

Объекты, наследование, интроспекция. На сях.

просто когда это писалось с++ еще не было )

точнее было, но с компиляторами беда

Объекты, наследование, интроспекция. На сях.

я стараюсь не употреблять тяжелые

просто когда это писалось с++ еще не было )

ты удивишься когда узнаешь насколько новые эти костыли. И когда узнашеь что люди до сих пор так пишут

> но изначально да — вопрос был про минимальный сабсет охереть. надо было так и сказать я: go ближе к железу, чем c++ вы: нет, с++ ближе если бы вы сразу сказали "минимальный сабсет c++ ближе" - я бы согласился, отметив, что минимальный сабсет C++ это С, и он нахер никому не упал при разработке приложений

> но изначально да — вопрос был про минимальный сабсет охереть. надо было так и сказать я: go ближе к железу, чем c++ вы: нет, с++ ближе если бы вы сразу сказали "минимальный сабсет c++ ближе" - я бы согласился, отметив, что минимальный сабсет C++ это С, и он нахер никому не упал при разработке приложений

для тех приложений где нужна близость к железу он не то чтоб прям “нахер не упал”

для тех приложений где нужна близость к железу он не то чтоб прям “нахер не упал”

в современном мире нет причин брать си когда есть си++

даже если нужна близкость к железу

ни одной уважительной

даже в embedded

даже при написании кода под AVR

да я знаю ( это вон к оратору выше минимальный сабсет с++ это не что “нахер не упало когда нужна близость к железу"

Ты тоже?

Кстати, я кретин, дошло как прокидывать методы без асма =)

да я знаю ( это вон к оратору выше минимальный сабсет с++ это не что “нахер не упало когда нужна близость к железу"

коллега, вы все больше погружаетесь в себя

я совсем другое сказал

не такое для вас удобное как для оппонента

то что минимальный сабсет который близок к железу это си? ) нет это не совсем си

как тлько он не совсем С - он дальше от железа

ну классы вон далеки от железа? если без виртуальных методов то это не отличимо от структур в си

всякие штуки типа auto в новом с++ далеки? да тот же код получается как если руками тип написать

ну классы вон далеки от железа? если без виртуальных методов то это не отличимо от структур в си

если с виртуальными то +1 поле

в какой момент там случается это фатальное “дальше от железа”? если буст подцепить? ну так не надо его

всякие штуки типа auto в новом с++ далеки? да тот же код получается как если руками тип написать

если автор близок к железу, то и размещение стек-хип в Го тоже

ибо это магия которую от тебя абстрагирует компилятор

если автор близок к железу, то и размещение стек-хип в Го тоже

ну да, тут и gc говорят близок

ибо это магия которую от тебя абстрагирует компилятор

ну нет, auto вообще на машинный код не влияет никак а вот где размещена переменная — очень даже влияет

ну классы вон далеки от железа? если без виртуальных методов то это не отличимо от структур в си

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

ну да, тут и gc говорят близок

Прошу не передергивать или ссылаться на оригинальную реплику

ну нет, auto вообще на машинный код не влияет никак а вот где размещена переменная — очень даже влияет

зависит от точки зрения

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

ровно на один аргумент что ли? )

ну да, тут и gc говорят близок

Ибо я говорил, что gc является слоем абстракции и его можно написать под железо на go, насадив сверху на ручное управление памятью

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

задумался кстати, иногда смотришь на асм и сразу непонятно эта функция метод класса или просто функция особенно если с оптимизациями собрано

никто не сталкивался с этой фигней? https://github.com/golang/go/issues/12745 а то вот у меня сотни 400 ошибок в секунду судя по логам nginx а гошечка ничего по этому поводу в логи не говорит...

и я даже не представляю как определить причину 400 ошибок

ровно на один аргумент что ли? )

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

задумался кстати, иногда смотришь на асм и сразу непонятно эта функция метод класса или просто функция особенно если с оптимизациями собрано

если с оптимизациями - то там компилятор творит магию всегда, включая инлайнинг

да даже без если честно есть ABI где this идет там же где первый аргумент в обычные функции и разницы по коду вообще никакой

да даже без если честно есть ABI где this идет там же где первый аргумент в обычные функции и разницы по коду вообще никакой

методы более развесистые, ощутимо более.

это уже зависит от кода в методе ) не волшебным же образом они развесистые потому что компилятор понимает “это с++ метод, резко делаем его в 2 раза толще"

коллега

хватит, а?

это не стыдно - признавать неправоту

хватит, а?

я вроде тебе ничего не писал ща ) чего так возбудился..

да база у меня лежит боевая

да, это печаль ( но я не виноват..

в этом - нет

а в той херне про близость c++ к железу - виноват

не, в этой херне страуструп виноват

я лишь очевидный факт констатирую )

очевиден он только через специальные очки

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

ERROR: S client not available

еще и при лежащей боевой базе )

ути-пуси

но мы все подняли, на самом деле уже

Как-будто есть объективный способ померить близость языка к железу

ну - можно придумать набор критериев

и имми последовательно пользоваться

Вот джабка - она близка? С одной стороны -VM С другой - скоро прикрутят обычную компиляцию

Как-будто есть объективный способ померить близость языка к железу

ну разве что на одном языке можно что-то сделать, а на другом нет (кроме как через биндинги к сям)

жабка нифига не близка

ну разве что на одном языке можно что-то сделать, а на другом нет (кроме как через биндинги к сям)

Хаскель ближе или дальше от железа, чем руби?

оба примерно одинаково далеки

жабка нифига не близка

Почему? Откуда это следует?

оба примерно одинаково далеки

По каким признакам?

Хаскель ближе или дальше от железа, чем руби?

не знаю ( если за с++ и го могу сказать (смотрел что там генерит компилятор) то в хаскель страшно заглядывать

по тому, как конструкции языка превращаются в машинные коды.

go превращается практически один в один

по тому, как конструкции языка превращаются в машинные коды.

А конкретно? Вот у нас есть aot, jit и vm

а при чем тут вм?

как по мне так жабка дальше потому что jit волшебный (не знаешь когда и чего от него ждать) ну и все прелести managed языка которые делают все дальше от железа, но удобнее для программиста

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

а при чем тут вм?

Это один из вариантов имплементации Я имею в виду, "обычная" компиляция, жит и тупо интерпретатор Какой-нибудь язык(например питон) реализован на всех трёх средах Он близок к железу?

еще раз - дело не в том как именно превращается текст в машинный код

дело в сходстве того, что получается с тем, из чего оно получается

дело в сходстве того, что получается с тем, из чего оно получается

Как померять это сходство?

и да, в C все очевидно, в Go по большей части очевидно, в питоне - нет, не очевидно

И вообще, напомните мне, в чём польза понятия "близости к железу"?

Как померять это сходство?

на глаз

на глаз

meh

ну - предложите методику, че

И вообще, напомните мне, в чём польза понятия "близости к железу"?

польза в том что есть задачи для которых иначе нельзя просто )

И вообще, напомните мне, в чём польза понятия "близости к железу"?

Это я холивар начал по поводу того, что го — примитивен

драйвер какой-нибудь для железки например