Сам себе отвечу. :) Мне тут подсказали, что современные люди едят намного, намного больше сахара чем наши предки. А в овощах сахаров очень мало (в отличие от фруктов которые и служили чуть ли не единственным их источником раньше). Так что овощи для современного человека чуть лучше фруктов в этом плане.
Вот что интересно, все так советуют есть овощи в огромных количествах, хотя наши далёкие предки не имели доступа к овощам. Фрукты (дикие) да. Мясо — да. Ягоды. Но овощи? Томаты и картофель вообще недавняя находка. Корнеплоды ещё найти надо. Всякие салаты и рукколы в лесу не найдёшь. С чего бы для нашего организма овощи полезней всего?
Переводя с юридического языка на нормальный, пришли к бывшему КГБшнику а ныне президенту старые товарищи и сказали:
1. В Интернете пишут про нас гадости, волнуют народ, мешают пропаганде, организовывают протесты против нас, вскрывают наши доходы и портят нам нашу тихую жизнь за высокими заборами.
2. Хотим читать всю переписку, а потом находить и публично наказывать всех этих людей, чтобы всем было страшно.
3. Хотим контролировать то, что батраки могут читать и отправлять.
4. Хотим как в Китае быстро рубить организацию митингов и протестов. Батраки должны работать, подчиняться касте правителей и приносить доход, а не бузить.
Был в музее в Валенсии. Музей науки любопытный, но (как и большинство западных научных музеев) ориентирован на школьников.
А вот океанариум просто потрясающий! Разбит на климатические зоны, от тропиков до Антарктиды,, где представлены не только морские животные, но и множество птиц. Только ради него можно приехать в Валенсию (ну и чтобы выпить прохладной Орчаты в испанскую жару).
Как житель города скажу — ужасный проект. Эти 327 метров джага-джаги господина Миллера видны отовсюду с западной стороны. Портит вид с Залива, портит вид с Васильевского острова. Никакой эстетики, просто огромное стеклянное любидло, как напоминание народу о том кто тут власть.
Зато господин Миллер сможет с 327 метров почёсывая что-нибудь радовать своё эго.
Поинтересуйтесь сколько раз скидывали власть в Южной Корее, прежде чем им удалось победить коррупцию и перепрыгнуть из «третьего мира» в «первый». И продолжают это делать чтобы там остаться, а не скатиться в «банановую родо-племенную деспотию» как Россия.
Достойный сын достойного депутата. Думаю у папаши в скором времени, как и у «агента 84» Лугового, политическая карьера в гору пойдёт. Обидели правильного пацана, надо помочь. Шоколад не виноват.
В США вообще сроки адские. Если уж поймали и доказали, то сажают надолго. Только в отличие от нашей страны у них не 99% обвинительных приговоров. Суду ещё доказать надо виновность человека, а не просто скопировать обвинение прокуратуры со всеми ошибками, протарараторить приговор «бубубу именемроссийскойфедерациипятьлетзаключения» и за 15 минут отправить человека за решётку,
Идея очень простая — отрезать от вектора слово «автоматически». Никаких автоматических скрытых аллокаций, никогда, сделать это невозможным на уровне интерфейса. Всегда только vector+reserve.
Если выделение памяти и низкоуровневый контроль не имеет значения, то нет причин писать на C++. Он чрезвычайно неудобен, очень дорог в плане программистских ресурсов, ненадёжен, требует большого количества строк для выражения элементарнейших вещей, плохо портируем, имеет длинные итерации при разработке (компиляция, линковка, повторить сначала) и тащит за собой кучу хлама из 70х годов.
И это при том что я люблю C++. Просто у него есть одна киллер-фича по сравнению с другими языками — никаких сюрпризов при выполнении программы. Вся программа выполняется дословно так, как её задумал программист.
>Сколько будет выделено памяти? Вы не знаете. И я не знаю. Для этого и сделаны структуры данных, которые выделяют память по требованию.
Опять передёргиваете, вопрос был не о количестве выделенной памяти, а о самом факте выделения. В вашем примере всё очевидно. Хотя надо заметить, что даже и в таком виде в программе должно быть ограничение «сверху», тогда мы сможем сказать «здесь точно выделится не более MAX байт памяти».
>Это идёт против самого определения структуры данных «вектор». Вы путаете вектор (не std::vector, а структура данных «вектор») с обычным массивом.
Ничего я не путаю. Вы бы по-прежнему смогли изменять размер массива как и раньше.
>Тогда вам пришлось бы при каждой вставке проверять размер и кол-во текущих элементов. В таком случае проще просто использовать обычный массив.
Это и так происходит каждый раз при push_back(), просто скрытно от программиста. В моём варианте программист бы сам проверял выделенный размер когда ему нужно.
Именно практика «не нужно думать о выделении памяти, умные дяди всё придумали за нас, будем просто лепить код» являтся порочной для C++. Ещё раз, это нормально для Java и C#, где является частью их дизайна и философии. Но не для C++, где фишкой языка является предсказуемость, из которой следует полная ответственность программиста за ход выполнения своей программы.
>Ну вообще-то могу. Я могу проверить, если capacity меньше, чем размер вектора, тогда выделения памяти не будет.
Не пердёргивайте, вопрос был без написания кода. Вы всерьёз полагали что мне неизвестно как программным способом узнать состояние std:vector?
Вы смотрите в код и видите такую строчку. Будет ли выделена память? А фиг его знает, надо (как вы сами сказали) ковырять состояние объекта на этот момент.
Не надо предлагать модифицировать код, подсовывать аллокаторы и прочее. Нужно глядя на строчку всегда (как вы сами сказали) точно знать когда будет происходить выделение памяти. Сейчас вы этого не знаете, а добрые дяди из комитета гладят вас по головке и говорят что вам не нужно беспокоится о таких глупостях.
У меня не было бы претензий к std::vector если бы его не сделали «дуракаустойчивым». То есть если бы push_back() при нехватке места вызывал бы падение, а все места выделения были бы обозначены вызовами resize(). Но нееет, у нас же тут типа Java, всё должно быть «удобно» и «автоматически», чтобы даже хреновый код от студентов-первокурсников мог как-то работать.
Вы сможете сказать, будет тут выделена память или нет? Не сможете, потому что это а) зависит от внутреннего состояния vec б) зависит от конкретной стратегии std:vector на данной платформе.
Это нормально в языках со сборкой мусора, но неприемлимо в языках с «ручным» управлением памятью. Править такой код от юных (или не очень) падаванов делающий аллокации на каждый чих — удовольствие ниже среднего. И чем дальше, тем больше становится способов вызвать скрытое выделение памяти. Тот же std::function соединённый с std::bind и вроде как невинным ссылочным типом превращается… правильно, в ещё больше аллокаций.
Зато такой код писать быстро и удобно, налепил контейнеров из библиотек, в которых лежат другие контейнеры — и пошёл чай пить. Пусть авторы ОС беспокоятся о том как код работает.
Я бы хотел доработок по части SIMD и выровненных данных (до сих пор какие-то танцы с бубном). Ещё доработанные корутины, а не то что сейчас есть (лучше пусть просто дадут стандартизированный способ сохранить стэк, дальше сами разберёмся).
Новые форматы для чисел кому-нибудь пригодятся, но очередной контейнер со скрытыми аллокациями — гадость. Хватит лепить из C++ подобие Java! Уже столько наплодили вредных сущностей для «программистов на пол-ставки» из разряда «лепи не думая, рантайм сам с памятью разберётся». std::string, std::vector, std::function… Теперь у нас даже числовые типы будут память выделять!
Преимущество C++ в предсказуемой производительности, а эти фантазёры всё пытаются догнать Java, C# и прочие «удобные» языки.
Все работы для этого в самой активной стадии — весь трафик готовятся завернуть на Ростелеком, с централизованным контролем над ним.
И ничего вы с этим не сделаете.
1. В Интернете пишут про нас гадости, волнуют народ, мешают пропаганде, организовывают протесты против нас, вскрывают наши доходы и портят нам нашу тихую жизнь за высокими заборами.
2. Хотим читать всю переписку, а потом находить и публично наказывать всех этих людей, чтобы всем было страшно.
3. Хотим контролировать то, что батраки могут читать и отправлять.
4. Хотим как в Китае быстро рубить организацию митингов и протестов. Батраки должны работать, подчиняться касте правителей и приносить доход, а не бузить.
А вот океанариум просто потрясающий! Разбит на климатические зоны, от тропиков до Антарктиды,, где представлены не только морские животные, но и множество птиц. Только ради него можно приехать в Валенсию (ну и чтобы выпить прохладной Орчаты в испанскую жару).
Зато господин Миллер сможет с 327 метров почёсывая что-нибудь радовать своё эго.
Важно где лучше людям живётся, а вот тут ни мне, ни вам, ни вашей бабушке гордится особо нечем.
Небольшой класс сверх-богатой элиты, спрятавшийся за стенами закрытых автоматизированных городов и толпы нищенствующих, живущих по законам джунглей.
И это при том что я люблю C++. Просто у него есть одна киллер-фича по сравнению с другими языками — никаких сюрпризов при выполнении программы. Вся программа выполняется дословно так, как её задумал программист.
Опять передёргиваете, вопрос был не о количестве выделенной памяти, а о самом факте выделения. В вашем примере всё очевидно. Хотя надо заметить, что даже и в таком виде в программе должно быть ограничение «сверху», тогда мы сможем сказать «здесь точно выделится не более MAX байт памяти».
>Это идёт против самого определения структуры данных «вектор». Вы путаете вектор (не std::vector, а структура данных «вектор») с обычным массивом.
Ничего я не путаю. Вы бы по-прежнему смогли изменять размер массива как и раньше.
>Тогда вам пришлось бы при каждой вставке проверять размер и кол-во текущих элементов. В таком случае проще просто использовать обычный массив.
Это и так происходит каждый раз при push_back(), просто скрытно от программиста. В моём варианте программист бы сам проверял выделенный размер когда ему нужно.
Именно практика «не нужно думать о выделении памяти, умные дяди всё придумали за нас, будем просто лепить код» являтся порочной для C++. Ещё раз, это нормально для Java и C#, где является частью их дизайна и философии. Но не для C++, где фишкой языка является предсказуемость, из которой следует полная ответственность программиста за ход выполнения своей программы.
Не пердёргивайте, вопрос был без написания кода. Вы всерьёз полагали что мне неизвестно как программным способом узнать состояние std:vector?
Вы смотрите в код и видите такую строчку. Будет ли выделена память? А фиг его знает, надо (как вы сами сказали) ковырять состояние объекта на этот момент.
Не надо предлагать модифицировать код, подсовывать аллокаторы и прочее. Нужно глядя на строчку всегда (как вы сами сказали) точно знать когда будет происходить выделение памяти. Сейчас вы этого не знаете, а добрые дяди из комитета гладят вас по головке и говорят что вам не нужно беспокоится о таких глупостях.
У меня не было бы претензий к std::vector если бы его не сделали «дуракаустойчивым». То есть если бы push_back() при нехватке места вызывал бы падение, а все места выделения были бы обозначены вызовами resize(). Но нееет, у нас же тут типа Java, всё должно быть «удобно» и «автоматически», чтобы даже хреновый код от студентов-первокурсников мог как-то работать.
Вы сможете сказать, будет тут выделена память или нет? Не сможете, потому что это а) зависит от внутреннего состояния vec б) зависит от конкретной стратегии std:vector на данной платформе.
Это нормально в языках со сборкой мусора, но неприемлимо в языках с «ручным» управлением памятью. Править такой код от юных (или не очень) падаванов делающий аллокации на каждый чих — удовольствие ниже среднего. И чем дальше, тем больше становится способов вызвать скрытое выделение памяти. Тот же std::function соединённый с std::bind и вроде как невинным ссылочным типом превращается… правильно, в ещё больше аллокаций.
Зато такой код писать быстро и удобно, налепил контейнеров из библиотек, в которых лежат другие контейнеры — и пошёл чай пить. Пусть авторы ОС беспокоятся о том как код работает.
Я бы хотел доработок по части SIMD и выровненных данных (до сих пор какие-то танцы с бубном). Ещё доработанные корутины, а не то что сейчас есть (лучше пусть просто дадут стандартизированный способ сохранить стэк, дальше сами разберёмся).
Новые форматы для чисел кому-нибудь пригодятся, но очередной контейнер со скрытыми аллокациями — гадость. Хватит лепить из C++ подобие Java! Уже столько наплодили вредных сущностей для «программистов на пол-ставки» из разряда «лепи не думая, рантайм сам с памятью разберётся». std::string, std::vector, std::function… Теперь у нас даже числовые типы будут память выделять!
Преимущество C++ в предсказуемой производительности, а эти фантазёры всё пытаются догнать Java, C# и прочие «удобные» языки.