Что значит "своего рода"? Если это индексы, то можно использовать обычный итеративный for. Честно говоря, проблема мне вообще кажется надуманой, хотя я и не пишу на kotlin. Если это не итерация, то нефиг использовать для этого for.
Имхо, за использование цикла for для чего-либо кроме итерации по элементам коллекции надо бить по рукам во всех языках. По семантике и смыслу for это именно цикл итерирования. Всё остальное и должно делаться через while.
Или в принципе не может это сделать, т.к. они лежат в отдельной dll-е.
Если у вас функция деинициализации лежит в отдельно библиотеке то вы и в C будете бессильны.
Ну если вы не увидели разницы между приведенными двумя примерами кода, значит ее нет, а я во всем неправ.
Ну я признаю, что если у вас перед вызовами close() идёт, например, особождения массива динамически выделенных объектов, то данные могут действительно уйти из кэша. Просто когда я представляю себе гипотетически такую ситуацию и представляю, что я пишу этот код на C, я понимаю что не знаю как его лучше написать. Вообще не представляю, какой вариант будет быстрее. И вряд ли вам кто-то скажет точно кроме серии бенчмарков. Отсюда вывод — потенциально вы может и можете написать на C более быстрый код. На практике, не изучая конкретный случай, компилятор, процессор — нет, не можете.
Во-первых, в том же C++ деструкторы не всегда инлайнятся.
Если они не инлайнятся — значит, компилятор считает, что так будет быстрее и вполне возможно, что он прав.
Т.е. если в коде на C++ между вызовами деструкторов a и b пройдет вызов еще нескольких деструкторов, то данные и код для вызова деструктора b уже могут уйти из кэша.
Какая-то странная ситуация. Если там столько всего произошло между этими двумя вызовами то у вас и на С данные точно так же "остынут". Какая разница, как это записать?
Вообще, понятно, что микрооптимизациями можно кое-каких выигрышей добиться. Только мне кажется, в местах, где такие мелочи играют значение, используют даже не C, а asm.
Но ведь в C вы всё-равно будете освобождать ресурс тогда, когда он вам не нужен. Имеено об этом идёт речь, когда говорят о zero-cost abstractions. То есть, корректная программа на C не будет ничем быстрее корректной программы на, например, C++ с деструкторами. Просто если вы используете C вам придётся те же самые деструкторы вызывать в явном виде, что намного сложнее, или же и вовсе невозможно.
Мне кажется, вы всё же немного не справедливы. Генераторы удобны для заполнения коллекций, но не для алгоритмов. Если вам просто надо проивести ряд вычислений или операций над некой последовательностью, тогда запись
for (auto num : numbers(4, 10)) {
...
}
намного удобнее, чище, нагляднее и несколько безопаснее, нежели что-то вроде
auto generator = numbers(4, 10);
for (i = 0; i < generator.size(); ++i) {
auto num = generator();
...
}
Да главный вопрос, зачем вообще было убирать этот ряд кнопок? Там же ещё есть место — поместилось бы и то и другое. Очень странный ход, как по мне. Такими темпами, они отдалят мак от всех остальных остальных компов так, что перейти на него с ПК будет нереально. Ну или очень больно. Непонятно, зачем это делать.
Не очень-то удобно, если я совершаю по 5-10 интернет покупок в неделю. Да и лимит в 3000 не всегда удобен. А если в магазине надо одеждой/обувью закупиться? 3000 тут никак не хватит. Да и вообще, мало ли какие непредвиденные траты могут возникнуть? Что делать?
Ну, программисту за многим приходится следить самому — например, за уникальностью имён переменных, классов и функций, так что я не стал бы причислять это к серьёзным недостаткам.
Она не то чтобы очень проблемная, в большинстве случаев она работает так как надо. Вот только вносить в стандарт то что «в большинстве случаев работает так как надо» — плохое решение. К тому же сама возможность полностью корректной имплементации под вопросом, и при этом есть решение, лишённое недостатков pragma once. Поэтому отсутствие её в стандарте — закономерно и правильно, как по мне.
Что значит "своего рода"? Если это индексы, то можно использовать обычный итеративный
for. Честно говоря, проблема мне вообще кажется надуманой, хотя я и не пишу на kotlin. Если это не итерация, то нефиг использовать для этогоfor.Так для
std::stringтоже не гарантируется же. В чём принципиальная разница?Тоже заинтересовал этот вопрос.
Имхо, за использование цикла
forдля чего-либо кроме итерации по элементам коллекции надо бить по рукам во всех языках. По семантике и смыслуforэто именно цикл итерирования. Всё остальное и должно делаться черезwhile.Назвать синтаксис Rust'а си-подобным можно лишь с очень большой натяжкой.
Если у вас функция деинициализации лежит в отдельно библиотеке то вы и в C будете бессильны.
Ну я признаю, что если у вас перед вызовами close() идёт, например, особождения массива динамически выделенных объектов, то данные могут действительно уйти из кэша. Просто когда я представляю себе гипотетически такую ситуацию и представляю, что я пишу этот код на C, я понимаю что не знаю как его лучше написать. Вообще не представляю, какой вариант будет быстрее. И вряд ли вам кто-то скажет точно кроме серии бенчмарков. Отсюда вывод — потенциально вы может и можете написать на C более быстрый код. На практике, не изучая конкретный случай, компилятор, процессор — нет, не можете.
Если они не инлайнятся — значит, компилятор считает, что так будет быстрее и вполне возможно, что он прав.
Какая-то странная ситуация. Если там столько всего произошло между этими двумя вызовами то у вас и на С данные точно так же "остынут". Какая разница, как это записать?
Вообще, понятно, что микрооптимизациями можно кое-каких выигрышей добиться. Только мне кажется, в местах, где такие мелочи играют значение, используют даже не C, а asm.
Но ведь в C вы всё-равно будете освобождать ресурс тогда, когда он вам не нужен. Имеено об этом идёт речь, когда говорят о zero-cost abstractions. То есть, корректная программа на C не будет ничем быстрее корректной программы на, например, C++ с деструкторами. Просто если вы используете C вам придётся те же самые деструкторы вызывать в явном виде, что намного сложнее, или же и вовсе невозможно.
Del
Извините за невнимательность, ответ не вам
Мне кажется, вы всё же немного не справедливы. Генераторы удобны для заполнения коллекций, но не для алгоритмов. Если вам просто надо проивести ряд вычислений или операций над некой последовательностью, тогда запись
намного удобнее, чище, нагляднее и несколько безопаснее, нежели что-то вроде
Подозреваю, что
operator(), возвращающий следующий элемент.