Курить вредно =)

Пох

Все вредно, в тои или иной степени

)

Мне здоровье позволяет

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

Тупо забываешь поесть когда увлекаешься.

Вообще над (очень) интересными тебе проектами вредно заниматься.

=)

Так что ладно, кури, если нравится =)

Я, в отличие от нескольких друзей "некурильщиков", в поликлинике последний раз был лет семь назад

Ну, не будем об этом

Сойдемся на том, что это личное дело каждого

Ура, 9!

Я пошел до магаза)

То есть если у тебя в коде исключения могут случаться сотнями или тысячами в секунду — ты неправильно используешь исключения.

Вообще накладные расходы есть. Вот накидал код смотри: https://godbolt.org/g/Hc3Qge

Я специально не хочу в том коде обрабатывать каких-то исключительных ситуаций. К примеру в моём случае ОС 100% выдаст мне запрашиваемую память и я в этом уверен

Не совсем корректное сравнение, функционал у printf и cout сильно разный, например.

Идея в том, что ты можешь написать код с ООП и без — и если функциональность этого кода будет одинаковой (не только видимая снаружи, но и внутри используемых библиотек) — то производительность будет той же.

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

Строки сишные (asciiz) не хранят свой размер. strlen очень медленный. Можно сильно быстрее.

Я вернулся)

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

Это называется временной константой)

Не совсем корректное сравнение, функционал у printf и cout сильно разный, например.

Разный, да. Но я же хочу грубо говоря просто стандартными средствами языка всё сделать. Ведь те кто пользуются ЯП они будут именно так писать.

Ну в мире сиплюсплюс всё не так.

Даже при равной цене алгоритма один может быть быстрее другого из-за временной константы

Посмотри сколько есть разных фреймворков, которые не опираются на стандартную библиотеку.

Qt одно чего стоит.

MFC и прочие древности вообще молчу.

Всегда можно переписать всё как нравится если что-то не нравится =)

Разный, да. Но я же хочу грубо говоря просто стандартными средствами языка всё сделать. Ведь те кто пользуются ЯП они будут именно так писать.

Вот я и думал, что мы сейчас про стандартные средства говорим

А не про библиотеки и фреймворки

Мы говорили про накладные расходы от ООП =)

изначально

Мы говорили про накладные расходы от ООП =)

Ага

Ну так без ООП код быстрее. Это факт. Другое дело, что код будет сложно читаем. А рекламируешь ты хорошо. Гляну

Вот с этого сообщения началось.

И в плюсах просто ООП, если писать ровно тот же код что и на сишечке со структурками, только в другом синтаксисе — будет практически бесплатным (или разница будет в пределах погрешности).

И я говорил, и еще раз повторю. Они нивелируются с ростом программы.

ООП "просто так" нахер не нужен, есть другие парадигмы, более удобные для небольших приложений

/hp

/hp

Greck2908 Greck2908: 291 hp

Ну в нормальном ООП код просто порой читать приятнее и понятнее.

Только в плюсах тут не доработано, увы.

Но если ты строишь что-то крупное, то ни линейкой, ни функционалкой ты не обойдешься

unified call syntax так и не завезли

Модулей до сих пор нет и есть риск что их не завезут до 2023 года — это вообще потеря =(

Тебе придется все проектировать объектами и на основе этого писать

Только в плюсах тут не доработано, увы.

Я на плюсы, как-то, положил

Сейчас на раст делаю ставку

На расте работы нет совсем пока что.

На го есть, но го недостаточно низкоуровневый =)

Сборка мусора, все дела.

На расте работы нет совсем пока что.

По этому и сказал, что "делаю ставку"

Доброе утро, @MirBrat! В чем специализируешься в сфере I.T.? Какие ожидания от чата? Ты можешь либо ответить, либо подписаться на канал @habrapub

Просто, он мне нравится

Из того что я видел — мне тоже многое понравилось =)

Сборка мусора, все дела.

На расте сборка мусора не требуется

Он мусора не оставляет, и не позволяет кодеру делать так, что бы он оставался

Доброе утро, @MirBrat! В чем специализируешься в сфере I.T.? Какие ожидания от чата? Ты можешь либо ответить, либо подписаться на канал @habrapub

linix/unix/php/bash/sql/java

fn is_divisible_by(lhs: u32, rhs: u32) -> bool { //... } А можно ли сразу результату имя присвоить? Типа "-> result: bool {"

Кажется это могло бы быть приятной фичей =)

Я когда увидел этот синтаксис объявления функции, сразу подумал что круто было бы круто иметь возможность сразу создавать и переменные для результата =)

Кажется это могло бы быть приятной фичей =)

Вряд ли)

Иногда удобно.

И компилеру проще оптимизировать было бы

Не забывай, Rust - это язык выражений)

Чтобы сразу конструировать результат там где он будет храниться после выхода из функции (если это какая-то сложная структурка, например).

Из функции он просто возвращает результат последнего выражения, куда уж красивее и проще)

Это да, но это могло бы быть просто сахарком к объявлению result: bool первой строкой и на выходе из всех веток автоматическому подставлению result без точки с запятой.

Зачем тебе лишняя переменная в памяти?

Которая, РЕАЛЬНО, лишняя

Иногда результат формируется долго, для его формирования заводят переменную, а потом уже её возвращают, когда результат готов.

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

Если этого нет, надо подучить раст получше и написать пропозал =)

Иногда результат формируется долго, для его формирования заводят переменную, а потом уже её возвращают, когда результат готов.

В таком случае тебе никто не запрещает писать в переменную, а потом ее вернуть

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

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

Знаешь, как я отношусь к функциям?

А если мы сразу укажем компилятору, что вот эта вот переменная — результат, компилер сможет сразу это оптимизировать, и формировать результат сразу на стеке вызывающей функции.

Если функция делает что-то, кроме своей непосредственной задачи, то это плохая функция

То есть в машинном коде в функцию будет передан некий указатель в edi, куда нужно поместить результат — и код сразу будет обращаться в edi при каждом обращении к переменной по имени result, так как заранее известно, что это именно то что вернёт эта функция, а не что-то другое.

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

Функция - как мистер Мисикс

Глупое ограничение =) Для простого кода конечно оно годится, но не весь код может быть таким же простым.

Но не в этом суть.

Она должна быстро выполнить задачу и умереть

Вот у тебя код поиска минимального значения в массиве — и ему уже нужна переменная для хранения текущего результата в процессе поиска значения.

Как можно быстрее

Она и выполнит задачу, и умрёт, но результат сразу окажется там где ожидает родительская функция.

Вот у тебя код поиска минимального значения в массиве — и ему уже нужна переменная для хранения текущего результата в процессе поиска значения.

И?

И?

-39 hp (Alexanderes Teterevlyov)

Без временных переменных.

Пример не оч, но суть в том, что во время выполнения функции результат меняется.

Без временных переменных.

Да что значит "без временных"

Пока идёт поиск подходящего.

Все переменные временные

Постоянные только константы

Функция отработала и ушла из стека вместе со всеми своими переменными

std::string get_some_result() { std::string result; // some complicated logic return result; } std::string val = get_some_result();