The OpenNET Project / Index page

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



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

Оглавление

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

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


203. "Проект LLVM развивает средства для безопасной работы с буфер..."  +1 +/
Сообщение от Аноним (203), 07-Окт-22, 12:05 
Как бе дааа… Если ли бы ты написал хоть одну строчку кода в жизни, то знал бы, что без проверки узнать, работает ли всё так, как хотелось, невозможно.

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

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

Поэтому доработка->деплой->тестирование это стандартный цикл при разработке софта.

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

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

206. "Проект LLVM развивает средства для безопасной работы с буфер..."  –2 +/
Сообщение от Аноним (198), 07-Окт-22, 12:58 
Ну так ты пишешь все что нужно проверить - функцию, класс, модуль, хз на чем ты пишешь - и один раз запускаешь компиляцию! Зачем ее дергать каждый раз?

> А ещё часто бывает доработка на месте, когда ты не знаешь, что нужно дописать...

Хе, вот тут у тебя проблема в компетенции или у проекта вообще. Вот тебе варианты:
- Заглянул в доку и прочитал что нужно
- Поставил breakpoint и посмотрел что нужно

Ну а если ситуация "мне бекенд что-то должен ответить, но хз что..." то это проблема явно не компилятора.

Тривиальные опечатки исправляются тривиально.
А нетривиальные - покрываются тестами (напр. ты не ту переменную на вход послал и оно все скомпилилось)
Плюс этот пример вообще не в тему - инкрементальная компиляция решает 99% таких ситуаций.

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

260. "Проект LLVM развивает средства для безопасной работы с буфер..."  +/
Сообщение от Аноним (260), 11-Окт-22, 10:56 
Проблема в компетенции тут у тебя. Просто ты манякодер, который не делал никогда, например, промышленные системы.
Ответить | Правка | Наверх | Cообщить модератору

207. "Проект LLVM развивает средства для безопасной работы с буфер..."  –1 +/
Сообщение от Аноним (198), 07-Окт-22, 13:03 
> оптимизированность и скорость не такое и высокое значение имеют, главное -- это способен ли код решать задачу, корректно ли он это делает

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

> никто никогда в своём уме не будет об этом думать раньше времени

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

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

208. "Проект LLVM развивает средства для безопасной работы с буфер..."  +1 +/
Сообщение от Аноним (203), 07-Окт-22, 13:32 
Вот так выберешь быструю сортировку вместо сортировки пузырьком, а потом окажется, что пузырьком быстрее и эффективнее (в частности, для gpgpu). Можно делать только равновероятно неверные предположения. Если какой-то код постоянно бесцельно исполняется, то это конечно лишнее. Всё остальное можно узнать только при реальном применении на платформе (и после достаточного увеличения нагрузки). А вот тратить время на, вполне вероятно, бесцельные или ошибочные оптимизации, вот это максимально не эффективно.
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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