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

"Опубликован набор компиляторов LLVM 19"	+/–
Сообщение от opennews (??), 17-Сен-24, 23:17
После шести месяцев разработки представлен релиз проекта LLVM 19.1.0, развивающего инструментарий (компиляторы, оптимизаторы и генераторы кода), компилирующий программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизаций). Сгенерированный псевдокод может быть преобразован в машинный код для заданной целевой платформы или использован  JIT-компилятором для формирования машинных инструкций непосредственно во время выполнения программы. На базе технологий LLVM проектом развивается компилятор Clang, поддерживающий языки программирования  C, C++ и  Objective-C. Начиная с прошлой  ветки  проект перешёл на новую схему формирования номеров версий, в соответствии с которой нулевой выпуск ("N.0") используется в процессе разработки, а первая стабильная версия снабжается номером "N.1"... Подробнее: https://www.opennet.me/opennews/art.shtml?num=61882
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

2. Сообщение от Аноним (2), 17-Сен-24, 23:21	+5 +/–
> механизм "#embed" для интеграции бинарных ресурсов; Джва года ждал.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #20, #58

4. Сообщение от Аноним (4), 17-Сен-24, 23:53	+1 +/–
Предпочитаю классику c99.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8

8. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 00:22	+6 +/–
классика - это с89
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #43

20. Сообщение от Аноним (20), 18-Сен-24, 04:08	+1 +/–
Там уже было, сам лично делал, только там нужно было делать финты пистоном. С23 очень годные изменения привнёс, второе пришествие С11.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #53

24. Сообщение от Аноним (24), 18-Сен-24, 05:23	+/–
Самый адекватный СИшный компилер. У gcc, например, нет clangd.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #25, #26, #50, #55

25. Сообщение от Хру (?), 18-Сен-24, 07:06	–2 +/–
Так возьми и запили! Будет gccd и благодарность в примечаниях к выпуску. А так же очередь из рекрутеров из топ-компаний планеты :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #61, #72

26. Сообщение от Аноним (26), 18-Сен-24, 07:28	–1 +/–
> У gcc, например, нет clangd. И не нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #62

27. Сообщение от хрю (?), 18-Сен-24, 07:54	–2 +/–
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p28... 2024-03-21 !!! @Trivial infinite loops are not Undefined Behavior@ - далеки чуваки от народа, ой как далеки.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29

29. Сообщение от Страуструп (?), 18-Сен-24, 08:28	+/–
Errorsoft, дело в том что не моя проблема, программисты пишут кривые оптимизаторы. Было дело ядро линукс не смогли собрать из за оптимизации в какой то новой GCC с флагом -o2.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #40

34. Сообщение от n00by (ok), 18-Сен-24, 09:16	+4 +/–
> В режиме C++14 включена по умолчанию поддержка функции > delete с указанием размера (sized deallocation) Кому лень ходить по ссылке и кто верует в "Си быстрее плюсов" и "free() всегда быстрее сборщика мусора": Modern memory allocators often allocate in size categories, and, for space efficiency reasons, do not store the size of the object near the object. Deallocation then requires searching for the size category store that contains the object. This search can be expensive, particularly as the search data structures are often not in memory caches.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #59

35. Сообщение от Аноним123 (?), 18-Сен-24, 09:31	+/–
>В режиме C++14 включена по умолчанию поддержка функции delete с указанием размера (sized deallocation), Кто-нибудь понял зачем это надо?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #38, #39

38. Сообщение от Аноним (-), 18-Сен-24, 09:33	+/–
Бьёрн Страуструп об этом знает?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

39. Сообщение от Аноним123 (?), 18-Сен-24, 09:34	+1 +/–
Сам спашиваю и сам отвечаю: Modern memory allocators often allocate in size categories, and, for space efficiency reasons, do not store the size of the object near the object. Deallocation then requires searching for the size category store that contains the object. This search can be expensive, particularly as the search data structures are often not in memory caches.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #77

40. Сообщение от letsmac (ok), 18-Сен-24, 09:42	+1 +/–
С флагом -O2 GCC много чего не собирается. Питон недавно пробовал собрать на плате с arm7 с -O2  - не вышло.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #83

42. Сообщение от Аноним (42), 18-Сен-24, 09:53	–1 +/–
Почему такой жирный сорс? Сколько там линухов вместили?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #60

43. Сообщение от Аноним (43), 18-Сен-24, 10:01	–12 +/–
Платформозависимый int – главное достижение человечества. Надо по рукам бить тех, кто тащит, например, uint64_t на 8-бит микруху. Код должен быть написан так, чтобы типы были без фиксированного размера. Тогда код будет на любой архитектуре работать оптимально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #46, #47, #69, #89

44. Сообщение от Аноним (43), 18-Сен-24, 10:18	+/–
> тип char8_t для строк и символов в UTF-8. Зачем вводить отдельное название для восьмибитного unsigned int?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #45, #73

45. Сообщение от Аноним (43), 18-Сен-24, 10:23	–2 +/–
Смешнее этого, что пример не работает отсюда: https://en.cppreference.com/w/c/string/multibyte/char8_t Gcc с поддержкой c23 ругается на тип. Изменил на char – работает. В общем, любители свежевыжатого фреша придумывают лишние абстракции. Второй C++ не нужен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #48

46. Сообщение от Аноним (-), 18-Сен-24, 10:37	+4 +/–
> Платформозависимый int – главное достижение человечества. Надо по рукам бить тех, кто тащит, например, uint64_t на 8-бит микруху. А кто ему запретит)? Это же не компилятор других языков, который будет лупить по рукам за кривой код. > Код должен быть написан так, чтобы типы были без фиксированного размера. Тогда код будет на любой архитектуре работать оптимально. Отличная идея! int main(void) {     int a = +2147483647;     int b = a + 1;     return 0; } выдает разные значения на разных платформах в зависимости от размера типа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #54, #86

47. Сообщение от Аноним (43), 18-Сен-24, 10:55	+/–
> Отличная идея! Так у вас пример архитектурозависимого кода. Диды умещали в 256 всё необходимое, даже игры делали. Что изменилось? Люди обленились и не оптимизируют логически переменные. Да, некоторые переменные должны вмещать большие данные. Вот их, как единичные исключения, делать фиксированными.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #52, #57, #68

48. Сообщение от Аноним (-), 18-Сен-24, 11:01	+2 +/–
> char8_t гарантировано unsigned. А вот обычный char - как повезет. Напр. в gcc он по умолчанию signed, но не на всех платформах (можно настраивать через -funsigned-char, -fsigned-char) Так что это не "придумывают лишние абстракции", это приведение типа к однозначному поведению. Потому что в стандарте не удосужились описать каким должен быть char. > Gcc с поддержкой c23 ругается на тип. Потому что у гыцыцы поддержка с23 омно. Просто пользуйся нормальным компилятором. Например тем, что указан в заголовке новости. И все будет работать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

50. Сообщение от 12yoexpert (ok), 18-Сен-24, 11:09	–2 +/–
самый адекватный для копирастов, лицензия какбэ намекает
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #63

52. Сообщение от trolleybus (?), 18-Сен-24, 11:17	+1 +/–
> Диды умещали в 256 всё необходимое, даже игры делали. Так вот то, что в 256 помещается, и надо делать uint8_t. Кроме этого, есть всякие uint_least8_t, uint_fast8_t для оптимизации по скорости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

53. Сообщение от Аноним (53), 18-Сен-24, 12:13	+/–
Усложнять чистосишку тоже не надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

54. Сообщение от Admino (ok), 18-Сен-24, 12:14	+6 +/–
> выдает разные значения на разных платформах в зависимости от размера типа. Сей код значений не выдаёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #78

55. Сообщение от Walker (??), 18-Сен-24, 12:18	+1 +/–
Они всё у GCC слизали!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #56, #64

56. Сообщение от Аноним (56), 18-Сен-24, 12:41	–2 +/–
> Они всё у GCC слизали! Что именно? Огласите список! Они создавались со свободной лицензией, как противовес раковому GCC. Чтобы не зависеть от левой (слегка погрызаной) пятки фанатиков, которым аж в 2009 году пришлось публиковать GCC Runtime Library Exception - без которых был спор является ли результат компиляции derivative work или нет. gnu.org/licenses/gcc-exception-3.1.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #66

57. Сообщение от i (??), 18-Сен-24, 12:42	+/–
очень смешно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

58. Сообщение от Аноним (58), 18-Сен-24, 13:13	+1 +/–
#embed "/etc/shadow"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #85

59. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 15:23	+/–
Ну давай теперь покажи как язык с гц быстрее ручного управления, только на реальном примере.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #76

60. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 15:24	+/–
Там внутри жирный сотрудник анб.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

61. Сообщение от Аноним (61), 18-Сен-24, 16:23	+1 +/–
> Так возьми и запили! Моей квалификации хеллоувротщика не хватит, увы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

62. Сообщение от Аноним (61), 18-Сен-24, 16:23	+/–
Если писать хеллоуврот в nano может и не нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

63. Сообщение от Аноним (61), 18-Сен-24, 16:24	+/–
Тебя как программиста (если ты таковой) лицензия должна волновать в самую последнюю очередь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #65

64. Сообщение от Аноним (61), 18-Сен-24, 16:25	–2 +/–
Это не важно. Важно что они предоставляют фишки, которых нет у гцц. А лицензии волнуют только вахтеров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #81

65. Сообщение от Аноним (-), 18-Сен-24, 16:48	+/–
Свободное Сообщество, FSF и GNU с тобой не согласны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

66. Сообщение от Аноним (-), 18-Сен-24, 17:12	–2 +/–
1. 1990-е гг. корпорасты наивно полагали, что поскольку есть C++, то чистая Сишка уже не нужна. В те времена люди впадали в оргазм при упоминании ООП. Все как мантру повторяли три кита ООП: инкапсуляция, наследование, полиморфизм. Из всего этого следует второй пункт. 2. Просто все забили на чистый Си и поддержку его стандартов в своих коммерческих компиляторах. Из всего этого следует третий пункт. 3. И вот вдруг корпорасты остались у разбитого корыта. Не было компилятора Си, который бы поддерживал последние стандарты языка Си, все коммерческие компиляторы застряли на уровне ANSI С89. 1990-е только Линус Торвальдс и GNU знали, что чистая Сишка - это реальная тема. В нулевые GCC, был единственным рабочим компилятором чистого Си. И тут корпорасты спохватились... LLVM появился не от того, что его разработчики любят Си, а от того, что Apple боялась господства GNU, и поэтому она влила в один университетский проект много денег. За годы господства ООП новое поколение программистов тупо не могло написать процедурный код с его алгоритмами. На первых порах разработчики LLVM тупо копировали целые куски исходного текста из GCC, сейчас, сами конечно они в этом не признаются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #70

68. Сообщение от _ (??), 18-Сен-24, 19:01	+/–
>Диды умещали в 256 всё необходимое, даже игры делали. На Радио86 \ Микроша \ Sinclair *\ Yemaha MSX  int был 8 bit - surprise bro! >Что изменилось? На том, из чего ты накропал свой гениальный пост int - 64 bit ... >Люди обленились и не оптимизируют логически переменные. И правильно, пусть вон - ChatGPT с Copilot напрягаются! :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #74, #75, #87

69. Сообщение от nc (ok), 18-Сен-24, 23:04	+1 +/–
Вообще говоря типы без фиксированного размера это частный случай трейтов. Т.е. мы говорим  "нам здесь нужен какой-то целочисленный тип с такими-то свойствами" и компилятор сам выводит этот тип. Если язык в явном виде поддерживает такое - это замечательно. Но Си поддерживает нечто очень урезанное (не вывод типа а платформозависимость), просто потому что так сложилось исторически, что плохо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #71, #79

70. Сообщение от Аноним (-), 18-Сен-24, 23:14	+/–
> LLVM появился не от того, что его разработчики любят Си, > а от того, что Apple боялась господства GNU, и поэтому она влила в один университетский проект много денег. Какое господство гну? Тогда они даже однопроцентниками не были. Аппл боялась лицензионной грязности гнурака. Причем не только эпл. Вспомни по какой причине BSD с по настоящему свободной лицензией пришлось в срочном порядке менять компилятор и почему впоследствии появился GCC Runtime Library Exception. Но это было неприемлемо для всех остальных свободных проектов тоже. А гнутики один раз уже замарались и больше к ним доверия не было. Поэтому в LLVM поддержали и другие участники. > На первых порах разработчики LLVM тупо копировали целые куски исходного текста из GCC Угу... и нарушали GPL? Какой только дичи не увидишь от кекспертов... > сейчас, сами конечно они в этом не признаются. Давай пруфы в студию. История коммитов есть, так что показывай, что именно они сперли из гцц.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

71. Сообщение от Аноним (-), 19-Сен-24, 00:37	+/–
Дайте пожалуйста определение трейтов на С. Или вы не понимаете что такое трейты или я чего-то не понял.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

72. Сообщение от Аноним (-), 19-Сен-24, 00:40	+/–
Есть cmake. Хотя мне не нравится. Я хоть и любитель, вообще не Си программист, но могу запилить. Просто компилятор, который исследует изменение в файлах и начинает компиляцию? Это реально нужно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #82

73. Сообщение от Аноним (-), 19-Сен-24, 00:48	+1 +/–
Потому что ты есть типы зависящие от платформы, а это независящий от платформы. Он будет работать одинаково на разных платформах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

74. Сообщение от Аноним (74), 19-Сен-24, 10:42	+1 +/–
int не может быть 8 бит даже в Нарнии, даже в Гаррипоттере, даже в C89. >На том, из чего ты накропал свой гениальный пост int - 64 bit ... Модель ILP64 встречалась на том, что давно в музее, поэтому нет, не 64 битный у него инт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #91

75. Сообщение от n00by (ok), 19-Сен-24, 13:13	+/–
>>Диды умещали в 256 всё необходимое, даже игры делали. > На Радио86 \ Микроша \ Sinclair *\ Yemaha MSX  int был > 8 bit - surprise bro! Storage for individual variables is allocated in the same way. regardless of whether automatic or static storage is used. First is storage for the basic types, then for derived types: char     1 byte int      2 bytes, least significant byte at lower address unsigned 2 bytes, least significant byte at lower address pointer  2 bytes. least significant byte at lower address. Contains address of pointed-to object Page 38 HiSoft ZX C User Manual https://worldofspectrum.org/pub/sinclair/games-info/h/HiSoft...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #90

76. Сообщение от n00by (ok), 19-Сен-24, 13:22	–1 +/–
>> кто верует в ... "free() всегда быстрее сборщика мусора" > Ну давай теперь покажи как язык с гц быстрее ручного управления, только > на реальном примере. То есть ты полагаешь, что какой-то ноунейм может меня взять на "слабо". Хорошо, поиграем по твоим правилам. Например, у меня на гитхапе лежит ВМ OCaml со сжимающим сборщиком мусора, и интерпретатор Рефал с автоматическим управлением памятью, что можно считать частным случаем сборщика мусора. Они есть и работают. Ну давай теперь на выбор что-то из этого сделай с ручным управлением памятью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

77. Сообщение от n00by (ok), 19-Сен-24, 13:36	+/–
Помимо этого, есть вопрос "архитектуры". Допустим, получили от пользователя некое число n и аллоцировали n байт. Теперь это n хранится в двух местах: в менеджере кучи и в приложении. Зачем хранить джважды? С одной стороны, если уж хранится, можно было бы при освобождении проверять размер, отлавливать часть мелких ошибок. С другой, можно писать свой простейший аллокатор через mmap() и munmap().
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #84, #88

78. Сообщение от Bottle (?), 19-Сен-24, 14:23	–1 +/–
Хорошо, он забыл написать printf, но ты понял его мысль, а это главное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

79. Сообщение от Bottle (?), 19-Сен-24, 14:27	+1 +/–
Это не случай трейтов. Это называется по другому: беззубый комитет стандартизаторов пытался написать стандарт, который будет соответствовать всем коммерческим компиляторам. А различия в компиляторах обусловлены тем, что Ритчи стучал своим слоником по PDP-11, так и не написав точную спецификацию языка, а лишь обрывочные фантазии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

81. Сообщение от Аноним (-), 19-Сен-24, 18:42	+/–
И какие же это фишки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

82. Сообщение от Аноним (-), 19-Сен-24, 18:44	+/–
Если я не верно понял - дайте пожалуйста определение clangd.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #92

83. Сообщение от Аноним (-), 19-Сен-24, 18:46    Скрыто ботом-модератором	+/–
Я думал это только у меня так. А это у всех компиляторов такая проблема?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

84. Сообщение от Аноним (-), 19-Сен-24, 18:52	+/–
Давно не имел дело с С++. Удивлен что появился сборщик мусора. А две ссылки нужны именно для его адекватной работы. В C# точно также 2 ссылки, но для более простого понимания придумали сказку о поколениях объектов - можете почитать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #93

85. Сообщение от Аноним (-), 19-Сен-24, 19:40	–1 +/–
> #embed "/etc/shadow" Билдуете под рутом? Ну так вам и надо тогда! Скажите спасибо что не "rm -rf /usr /bin/wtflol" в makefile :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

86. Сообщение от Аноним (-), 19-Сен-24, 19:42	+/–
Отличная идея! int main(void) {     int a = +2147483647;     int b = a + 1;     return 0; } выдает разные значения на разных платформах в зависимости от размера типа. Этот код вроде бы везде только возвращает ОС нулевой код возврата и отваливает в туман. Вон то оптимизатор вообще может в ноль грохнуть. Side effects же нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

87. Сообщение от Аноним (-), 19-Сен-24, 19:46	+/–
>> Диды умещали в 256 всё необходимое, даже игры делали. > На Радио86 \ Микроша \ Sinclair *\ Yemaha MSX  int был 8 bit - surprise bro! Про int в стандарте сказано не менее 16 бит. Так что если у вас было вон то, это не по стандарту и сами там с своим самопалом разбирайтесь. На сях вон тех не особо програмили так то. В основном выбор был из васика да ассеблирования в машинных кодах. > На том, из чего ты накропал свой гениальный пост int - 64 bit ... Это без гарантий, мягко говоря. >> Люди обленились и не оптимизируют логически переменные. > И правильно, пусть вон - ChatGPT с Copilot напрягаются! :) Ну как бы рутинную работу на машины спихнуть - почему бы и нет? Машины для этого и делали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

88. Сообщение от Аноним (-), 19-Сен-24, 20:25	+/–
И почитать можно в книге CLR via C#, Рихтера вроде
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

89. Сообщение от Аноним (89), 19-Сен-24, 20:30	+1 +/–
> Платформозависимый int – главное достижение человечества. Надо по рукам бить > тех, кто тащит, например, uint64_t на 8-бит микруху. Намного лучше когда, получив обрубленый int, код втихаря делает подляну - обрубив вычисления - при этом может не быть никаких warning'ов, и вот вы получаете на своем 8-бит уродце - какие-то баги. Если не повезет - через годик его работы (на 8-бит AVR бывают и управляющие штуки). В целом это ведет к НЕПОРТАБЕЛЬНОМУ коду который дико багует - и хрен поймешь где и когда. Ибо запустить на AVR ubsan тоже вроде не судьба (на cortex M легкий вариант даже можно). А вот явное указание битности - эту проблему решает. А заодно и хайлайтит "жиртреста" с потенциально тормозной математикой или жором оперативы. > Код должен быть написан так, чтобы типы были без фиксированного размера. > Тогда код будет на любой архитектуре работать оптимально. Он на практике на половине вообще работать не будет - или будет дико баговать, в хучшем случае еще и далеко не сразу. А корректно сишным "int" не полузуется чуть менее чем никто, достаточно -Wconversion вкатить и подивиться сколько потенциальных фапаков в типовом коде бывает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

90. Сообщение от _ (??), 19-Сен-24, 23:46	+/–
Да лопухнулся я, чего там. Надо больше пить :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

91. Сообщение от _ (??), 19-Сен-24, 23:49	+/–
> int не может быть 8 бит даже в Нарнии, даже в Гаррипоттере, даже в C89. Ну да - не может, лопухнулся :) Я его (Си) на такой технике почти не встречал, там BASIC + Asm и это всё что надо :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

92. Сообщение от _ (??), 19-Сен-24, 23:55	+/–
О LSP слышал? Дык вот: clangd is a language server implementation.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

93. Сообщение от n00by (ok), 20-Сен-24, 08:45	+1 +/–
Не две ссылки, а дважды хранится размер блока в куче. А "сборщик мусора" в плюсах всегда "был", как и в Си - кому нужен, те писали сами или брали BoehmGC.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

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

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