The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Первый стабильный релиз компоновщика Mold, развиваемого разработчиком LLVM lld, opennews (??), 16-Дек-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


6. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +4 +/
Сообщение от Аноним (6), 16-Дек-21, 11:27 
>печально

Да, жаль, что не на Си.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

21. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +8 +/
Сообщение от Анонимemail (1), 16-Дек-21, 13:08 
да, код на Си намного читабельнее кода на современном C++
Ответить | Правка | Наверх | Cообщить модератору

46. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +3 +/
Сообщение от Аноним (46), 16-Дек-21, 20:49 
Увы, но, современный код на си, даже при том, что читабельный сам по себе, заставляет городить невообразимые тонны нечитаемого бойлерплейта, который ещё и еггог проне. У меня не получается сделать корректно и не превратить либо в лапшу либо в 1000 этажные инлайны с препроцессором. Для высокоуровневых задач плючи всё же намного лучше, кроме того есть уже нормальные стандартные реализации для многих вещей и их обычно достаточно. Особенно современные. Когда хватает самой примитивной работы с байтами, тут да, си вне конкуренции (и то придётся обмазаться расширениями). Интероп опять же намного более годный на мой взгляд тоже в си.
Ответить | Правка | Наверх | Cообщить модератору

71. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  –1 +/
Сообщение от Аноним (-), 17-Дек-21, 08:56 
Если у тебя "1000 этажные инлайны с препроцессором", то в этом виноват только ты сам. Не умеешь организовывать код. GTK писан на чистом Си, а сам код чётко структурирован как ООП.

Не умеешь писать в процедурном стеле не лезь.

Ответить | Правка | Наверх | Cообщить модератору

106. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +6 +/
Сообщение от мое правило (?), 18-Дек-21, 00:19 
Только чет он так круто организованный, что гномьи авторы придумали vala, только что бы не писать на всратом с.
Ответить | Правка | Наверх | Cообщить модератору

65. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +2 +/
Сообщение от Аноним (65), 17-Дек-21, 03:06 
Замечательно, что не на С, а на С++20. И разработка быстрее, и код читабельнее, и производительность на высоте. А С-луддитам пора выйти из зоны комфорта и выучить, наконец, С++.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

80. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (80), 17-Дек-21, 13:07 
Только какой в этом смысл, если за питон больше платят?
Ответить | Правка | Наверх | Cообщить модератору

88. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +2 +/
Сообщение от Ананас (?), 17-Дек-21, 18:05 
Что, аж две миски?
Ответить | Правка | Наверх | Cообщить модератору

89. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 17-Дек-21, 18:06 
Сомневаюсь что-то. Можно пруфлинк?
Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

102. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (80), 17-Дек-21, 21:31 
https://leonardo.osnova.io/6f458341-e3ff-5373-907e-f19f5a231.../
Не то чтобы сильно больше, но дорасти до большей зп на питоне можно быстрее, так что профита больше учить питон, а не дидовские кресты.
Ответить | Правка | Наверх | Cообщить модератору

103. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (80), 17-Дек-21, 21:33 
А если питонщик умеет ещё и на сях лабать, то у него есть хороший шанс стать незаменимым, попадя в правильно место)
Ответить | Правка | Наверх | Cообщить модератору

104. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от Аноним (80), 17-Дек-21, 21:33 
А если питонщик умеет ещё и на сях лабать, то у него есть хороший шанс стать незаменимым, попадя в правильно место)
Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

114. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от Аноним (65), 18-Дек-21, 18:12 
Это что, шутка какая-то? Во-первых, по ссылке зарплата на Python и на С++ абсолютно одинаковая, а не просто "не сильно больше". Во-вторых, цифры неправдоподобные. Зарплата программиста 130 000 рублей? Это одних джунов и студентов опрашивали что ли? Я ожидал увидеть цифры в районе 400 000. В-третьих, что за сайт левый такой и только картинка, почему не дать ссылку на оригинал, статью на Хабре? Наверное потому что там уже напихали авторше в панамку по поводу совершенно неправдоподных цифр?
Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

116. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (80), 18-Дек-21, 20:53 
> Я ожидал увидеть цифры в районе 400 000.

На hh.ru если выставить фильтр на 400+, вакансий для питонистов 262 находится, а для с++ 125.

Ответить | Правка | Наверх | Cообщить модератору

117. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 18-Дек-21, 23:03 
Ну и что, это же не показатель средней зарплаты. Если так любишь hh.ru, вот тебе статья про высокооплачиваемые работы:

https://hh.ru/article/28335

C++ там в первом разделе в топе, а Питон в последнем разделе на последнем месте.

И погоди, а то что ты лажанулся с каким-то там leonardo.osnova.io уже как бы и не считается? Признать своё лажание не хочешь?

Ответить | Правка | Наверх | Cообщить модератору

119. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (80), 19-Дек-21, 11:55 
> ты лажанулся

Что за агрессия? Ты приплюснутый что ли82808 и тебя это задело? Средняя зп по методике расчёта это float, если ты считаешь что из 2х float с одинаковой целой частью один не может быть быть больше, а другой меньше, то у меня для тебя плохие новости.
> C++ там в первом разделе в топе, а Питон в последнем разделе на последнем месте.

И что мне это должно сказать? За "топовую" вакансию на плюсах и 400к не предложили, тогда как на питоне таких по 400+ 262 шт находится.

Ответить | Правка | Наверх | Cообщить модератору

120. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 19-Дек-21, 19:27 
Просто непонятно как говорить с человеком, который то "забывает" свои предыдущие несостоявшиеся аргументы, то передёргивает и сравнивает цифры из разных статей. Наверное никак.
Ответить | Правка | Наверх | Cообщить модератору

68. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от n00by (ok), 17-Дек-21, 08:11 
>>печально
> Да, жаль, что не на Си.

Ну почему же

std::string get_realpath(std::string_view path) {
  char buf[8192];
  if (!realpath(std::string(path).c_str(), buf))
    return std::string(path);
  return buf;
}

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

93. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (-), 17-Дек-21, 19:08 
> Ну почему же
> std::string get_realpath(std::string_view path) {
>   char buf[8192];
>   return buf;

Тут "спрятанно" какое-то копирование buf в возвращаемый std::string (которого не будет в си)?

Ответить | Правка | Наверх | Cообщить модератору

95. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 17-Дек-21, 19:40 
Да, будет копирование. Но его можно было бы избежать, сделав buf изначально типа std::string и передавая buf.data() в realpath().

Но это всё такое крохоборство походу. В Java и Python строки неизменяемые, там любое изменение строковой переменной это создание нового строкового объекта, ещё дороже получается. Программисты на других языках смотрят на этот подсчёт крох со смехом.

Ответить | Правка | Наверх | Cообщить модератору

98. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (-), 17-Дек-21, 20:33 
> В Java и Python строки неизменяемые, там любое изменение строковой переменной это создание нового строкового объекта, ещё дороже получается.

Вообще-то, еще во втором питоне для "объемной" работы со строками были MutableString и StringIO, в Java - тот же StringBuffer.


Ответить | Правка | Наверх | Cообщить модератору

100. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 17-Дек-21, 21:05 
Это всё так, но мы друг другу не противоречим. MutableString, StringIO и StringBuffer - это не строковые переменные. Это объекты, содержащие массивы байтов. В них надо загонять текстовые данные, копированием, а потом полученные строки в строковые переменные извлекать, тоже копированием. Двойное копирование то бишь. В С++ тоже такое есть, называется std::stringstream.

Ответить | Правка | Наверх | Cообщить модератору

96. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 17-Дек-21, 19:52 
> копирование ... которого не будет в си

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

Это вообще распространённая проблема в С. Ошиблись при работе с памятью, потом из неправильного места в памяти читаем мусор и радостно исполняемся некоторое время, пока проблема не всплывёт вообще в другом месте кода. Трудно дебажить такое. В С++ такие ошибки встречаются гораздо реже.

Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

97. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (-), 17-Дек-21, 20:17 
>> копирование ... которого не будет в си
> А в С был бы возврат указателя на локальный буфер в функции,
> где после выхода из функции и вызова парочки других функций,

Я в курсе, потому и спросил.
>  Зато без копирования, да.

Угу, зато есть такие вот неявные кунстштюки, вместо (условного) return str::string(buf).

Ответить | Правка | Наверх | Cообщить модератору

99. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 17-Дек-21, 20:45 
Такое неявное конструирование объектов очень удобно. И это не является какой-то секретной фичей, это базовая фича, о которой знают все программисты С++. Можно конструировать явно, std::string(buf) является валидной конструкцией. Можно пометить конструктор как explicit, тогда неявное конструирование будет запрещено.

А в функциональных языках вообще return неявный, возвращается последнее вычисленное выражение, тоже очень удобно, можно писать короткие функции как "a + b", без return.

Ответить | Правка | Наверх | Cообщить модератору

105. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (-), 17-Дек-21, 22:04 
> Такое неявное конструирование объектов очень удобно. И это не является какой-то секретной
> фичей, это базовая фича, о которой знают все программисты С++.

(Не)явное удобство явно переоцененно, но это вкусовщина, о которой я не вижу смысла спорить.

> А в функциональных языках вообще return неявный, возвращается последнее вычисленное выражение,

Не соглашусь. Это - игра словами (просто потому что нет ключевого слова return).
Основной момент: там, где нет return и возвращается последнее выражение - все вполне себе явно. Тем более, функциональный стиль, сопоставление с образцом и "все есть выражение" (expression), с упрятыванием "не-выражений" с побочными эффектами - куда подальше в монады и ко, (т.е. еще и код структурированн по другому).

Для "императивных" ЯП тут вспоминается "single entry, single exit" из "древнего" "structured programming".

Неявно - это к ЯП, где возможен и явный "return foo" и возврат последнего выражения (например ruby, rust - где есть "типа фунциональщина и сбоку бантик").

Ответить | Правка | Наверх | Cообщить модератору

109. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от n00by (ok), 18-Дек-21, 09:18 
>> копирование ... которого не будет в си
> А в С был бы возврат указателя на локальный буфер в функции,

Смотрим man 3 realpath

       char *realpath(const char *path, char *resolved_path);

...

       Получившееся  имя  сохраняется  в  виде  строки (с null на конце) не длиннее чем PATH_MAX байт в
       буфере, указанном в resolved_path. Конечный путь не содержит символьных ссылок и компонентов /./
       или /../.

       Если  значение  resolved_path  равно NULL, то realpath() выделяет буфер размером PATH_MAX байт с
       помощью malloc(3) для хранения полного пути и возвращает указатель  на  этот  буфер.  Вызывающий
       должен освободить буфер с помощью free(3).

Т.е. в Си убрали бы char buf[8192] и вернули указатель на кучу.

Что бы в Си++ не заниматься крохоборством с магическими числами вместо PATH_MAX, можно было конструировать std::string из аллоцированого ф-цией realpath() результата?

Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

115. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 18-Дек-21, 18:54 
> Т.е. в Си убрали бы char buf[8192] и вернули указатель на кучу.

В таком случае вызывающий get_realpath() должен деаллоцировать результат с помощью free(). А что если get_realpath() вернёт не результат realpath(), a path, полученный параметром? Он то вообще непонятно где находится и как аллоцирован. Тогда мы имеем или double free, или попытку сделать free() на указатель на стеке. С сопутствующими проблемами безопасности. Значит нельзя просто возвращать path, а надо сделать ему strdup(), получается одно копирование заменили на другое. Ты можешь сказать, ну тогда надо менять всю функцию, чтоб копирования не было. Или вообще её убрать и те 2-4 строчки в вызывающий код вписать. Но тогда можно и на С++ тоже функцию полностью переписать "по правильному". И вообще теряется весь предмет разговора.

> Что бы в Си++ не заниматься крохоборством с магическими числами вместо PATH_MAX, можно было конструировать std::string из аллоцированого ф-цией realpath() результата?

Да, запросто.

Ответить | Правка | Наверх | Cообщить модератору

118. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от n00by (ok), 19-Дек-21, 10:26 
>> Т.е. в Си убрали бы char buf[8192] и вернули указатель на кучу.
> В таком случае вызывающий get_realpath() должен деаллоцировать результат с помощью free().

Да. Точно так же в Си++ будет деаллоцирован буфер std:string. Только в Си все освобождения явны.

> А что если get_realpath() вернёт не результат realpath(), a path, полученный
> параметром? Он то вообще непонятно где находится и как аллоцирован. Тогда
> мы имеем или double free, или попытку сделать free() на указатель
> на стеке. С сопутствующими проблемами безопасности. Значит нельзя просто возвращать path,
> а надо сделать ему strdup(), получается одно копирование заменили на другое.
> Ты можешь сказать, ну тогда надо менять всю функцию, чтоб копирования
> не было. Или вообще её убрать и те 2-4 строчки в
> вызывающий код вписать.

Ну да, в Си эта обёртка вроде как совсем не нужна.

> Но тогда можно и на С++ тоже функцию
> полностью переписать "по правильному". И вообще теряется весь предмет разговора.

Так и я о том. Вроде как переписали на Си++, но наполовину, в итоге там потенциально буфер переполняется.

>> Что бы в Си++ не заниматься крохоборством с магическими числами вместо PATH_MAX, можно было конструировать std::string из аллоцированого ф-цией realpath() результата?
> Да, запросто.

В общем, непонятна экономия. Если есть имя файла, значит его будут читать, а это всю "оптимизацию" с кучей перевесит.

Ответить | Правка | Наверх | Cообщить модератору

122. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от Аноним (65), 19-Дек-21, 20:10 
> Только в Си все освобождения явны.

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

> Вроде как переписали на Си++, но наполовину,
> в итоге там потенциально буфер переполняется.

Да, не очень хорошо получилось. Но код на стыке языков часто таким бывает. Я не про потенциальное переполнение буфера, а просто про элегантность. Да и get_realpath() - это по сути С++ wrapper вокруг сишного API realpath(), а к врапперам требования по элегантности снижены, врапперы как раз и призваны локализовать неэлегантность в себе, предоставляя удобное API наружу.

Ответить | Правка | Наверх | Cообщить модератору

129. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +/
Сообщение от n00by (ok), 20-Дек-21, 11:25 
>> Только в Си все освобождения явны.
> Хм, так пишешь, как будто это хорошо. Явны, значит замусоривают код и
> заставляют программиста всё деаллоцировать вручную, т.е. лишают автоматизации, заставляют
> следить чтобы и не забыть про деаллокацию, и чтобы она больше
> одного раза не произошла.

Так там кто-то хотел на Си, значит для него это хорошо.

>> Вроде как переписали на Си++, но наполовину,
>> в итоге там потенциально буфер переполняется.
> Да, не очень хорошо получилось. Но код на стыке языков часто таким
> бывает. Я не про потенциальное переполнение буфера, а просто про элегантность.
> Да и get_realpath() - это по сути С++ wrapper вокруг сишного
> API realpath(), а к врапперам требования по элегантности снижены, врапперы как
> раз и призваны локализовать неэлегантность в себе, предоставляя удобное API наружу.

Есть же std::filesystem::canonical().

Ответить | Правка | Наверх | Cообщить модератору

110. "Первый стабильный релиз компоновщика Mold, развиваемого разр..."  +1 +/
Сообщение от n00by (ok), 18-Дек-21, 09:21 
>> Ну почему же
>> std::string get_realpath(std::string_view path) {
>>   char buf[8192];
>>   return buf;
> Тут "спрятанно" какое-то копирование buf в возвращаемый std::string (которого не будет
> в си)?

Тут переполняется стек при "нестандартном" значении PATH_MAX.

Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру