The OpenNET Project / Index page

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



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

Оглавление

Проект LLVM развивает средства для безопасной работы с буферами в C++, opennews (?), 06-Окт-22, (0) [смотреть все]

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


51. "Проект LLVM развивает средства для безопасной работы с буфер..."  –5 +/
Сообщение от Аноним (40), 06-Окт-22, 13:15 
Как раз таки классы самое ненужное в цпп. Когнитивная нагрузка раза в 1.5 снижается, когда не нужно думать об иерархиях классов и связях между ними. Бессмысленная вещь, только отнимающая время.
Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

62. "Проект LLVM развивает средства для безопасной работы с буфер..."  +2 +/
Сообщение от Аноним (61), 06-Окт-22, 13:44 
Классы позволяют перегружать операторы например и писать vec1 + vec2 + vec3 вместо add_vec(add_vec(vec1, vec2), vec3). А ненужное - это твое никчемное мнение
Ответить | Правка | Наверх | Cообщить модератору

63. "Проект LLVM развивает средства для безопасной работы с буфер..."  +4 +/
Сообщение от Аноним (-), 06-Окт-22, 14:08 
В нормальных языках пишут vec1.add(vec2).add(vec3)
И редактор кода сможет указать где этот метод реализован, а не просто + какой-то
Ответить | Правка | Наверх | Cообщить модератору

154. "Проект LLVM развивает средства для безопасной работы с буфер..."  +/
Сообщение от ndshu (?), 06-Окт-22, 22:56 
У вас синтаксис подразумевает vec1 += vec2 + vec3 или vec1 + vec2 + vec3
???

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

273. "Проект LLVM развивает средства для безопасной работы с буфер..."  +/
Сообщение от Аноним (-), 12-Окт-22, 16:12 
> У вас синтаксис подразумевает vec1 += vec2 + vec3 или vec1 +
> vec2 + vec3
> ???

А у вас сложение не коммутативное чтоли? Когда оно именно так - это всяко отдельный случай требующий отдельного внимания.

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

70. "Проект LLVM развивает средства для безопасной работы с буфер..."  +2 +/
Сообщение от Анонимemail (70), 06-Окт-22, 14:41 
Перегрузка операторов как раз самая отвратительная вещь в плюсах.
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

72. "Проект LLVM развивает средства для безопасной работы с буфер..."  +/
Сообщение от Аноним (98), 06-Окт-22, 14:51 
А ничё, что эта вещь не только в Плюсах имеется? Значит, востребована.
Ответить | Правка | Наверх | Cообщить модератору

197. "Проект LLVM развивает средства для безопасной работы с буфер..."  –1 +/
Сообщение от _kp (ok), 07-Окт-22, 11:17 
> Перегрузка операторов как раз самая отвратительная вещь в плюсах.

Это если применять куда попало, что бы было.
А бывает, что и необходимо, и при этом ещё и изящно.

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

76. "Проект LLVM развивает средства для безопасной работы с буфер..."  –3 +/
Сообщение от Аноним (40), 06-Окт-22, 14:56 
Типичный ответ приплюснутой макаки. Ровный пацан для математики оптимизированный код на интрисинках напишет, а не вот это вот.
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

250. "Проект LLVM развивает средства для безопасной работы с буфер..."  +/
Сообщение от Neon (??), 08-Окт-22, 18:30 
Зато потом ровного пацана забивают лопатой, когда код нужно будет перенести на другую архитектуру процессора)))
Ответить | Правка | Наверх | Cообщить модератору

71. "Проект LLVM развивает средства для безопасной работы с буфер..."  +1 +/
Сообщение от Аноним (98), 06-Окт-22, 14:49 
Я бы, наоборот, хотел бы найти утилитку, которая анализирует плоскосишный код и строит квази-UML диаграммы.
Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

190. "Проект LLVM развивает средства для безопасной работы с буфер..."  +/
Сообщение от bOOster (ok), 07-Окт-22, 10:28 
> Как раз таки классы самое ненужное в цпп. Когнитивная нагрузка раза в
> 1.5 снижается, когда не нужно думать об иерархиях классов и связях
> между ними. Бессмысленная вещь, только отнимающая время.

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

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

253. "Проект LLVM развивает средства для безопасной работы с буфер..."  +/
Сообщение от Аноним (253), 09-Окт-22, 04:05 
Классы очень полезны, когда они изолированы и не связаны с остальным кодом (как vector или string, илм complex и даже элементы графического интерфейса в какой-то степени).

Когда классы проникают в ЛОГИКУ работы прогаммы (в какой-нибудь основной цикл приложения/потока/сервера tcp) - это очень и очень плохо. Нужно от такого избавляться!!! Вынуждает использовать всякие inversion of control (и прочую лабуду), как следствие - логика работы программы разбросана по нескольким разным модулям и работать с таким кодом становится невозможно.

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

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

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




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

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