Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, FR, Вы писали:

FR>>Влад ты слишком давно не писал на C++

VD>Он что с тех пор изменился?

VD>ЗЫ

VD>Хотелось бы все же услышать обоснование.

Компиляторы Си/С++ до недавнего времени не умели инлайнить по указателю на функцию,
шаблоный же параметр инлайнят компиляторы даже 10 летней давности.

Здравствуйте, criosray, Вы писали:

c> Влад, я пришел к выводу, что спор с господами типа Антона Батенева, вдимаса, Геннадия Васильева и т.д. — местных аппологетов С++, это пустая трата времени и сил.

Мне, конечно, приятно, что меня причисляют к апологетам С++, хотя я к таковым себя не отношу, однако...

c> К тому же спорят-то они о вкусе устриц...

... вот кто бы это говорил из заводящих разговор про моно.

Здравствуйте, samius, Вы писали:

S>По поводу сливов...
S>Их где-то меняют на деньги, или это просто трофей на стену в туалете?
S>я просто не ф теме.

Можно нарисовать очередную звёздочку на борту.

Здравствуйте, VladD2, Вы писали:

FR>>Влад ты перестал пить коньяк и бить жену по утрам?

VD>Что вопрос о статистике некорректен? Я же прошу ответить "да" или "нет". Я прошу ссылки на информацию о том какие игры (особенно топовых) скомпилированы с использованием каких компиляторов?

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

Здравствуйте, criosray, Вы писали:

ГВ>>Ух ты! А я-то думал, что мокинг нужен для отслеживания последовательности внешних вызовов.
C>Неправильно думали. Мокинг нужен в первую очередь для изоляции тестируемого объекта. Чтоб сделать возможной эту изоляцию возможной необходимо симулировать поведение внешних зависимостей тестируемого объекта.

Так. Обратимся к первоисточникам:

Mocks [...] objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

Моки — запрограммированы на ожидание вызовов в соответствии с определённой спецификацией. (Буквально: формируют спецификацию своими ожиданиями)

Где сказано, что мок обязательно изолирует тестируемый объект от окружающих?

C>>>Ассерты это всего-лишь предикат, который по-определению всегда true.

C>>>Assert.Equals(10, someObj.SomeIntProperty);
C>>>Assert.IsTrue(someObj.SomeBoolProperty);
C>>>и т.д. и т.п.

ГВ>>А по-твоему, Expect — это не тот же самый Assert в профиль? Assert — утверждение, Expect — утверждение о некотором ожидаемом событии. Тот же Assert, только специализированный.
C>К чему вопрос?

К тому, что Expect так или иначе должен превратиться в Assert. Сделает это кодогенератор или ещё что-то — не важно.

C>>>Ассерты и моки не цель. Это средство и ключевой механизм реализации юнит тестов.
ГВ>>Любое автоматическое тестирование сводится к проверке последовательности утверждений. Иначе оно совсем не нужно. Дальше только вариации способов записи этих утверждений.
C>Само собою. Весь этот спор о том, что на С++ нет даже близко сравнимых по удобству инструментов для тестирования.

Ну, если сводить "удобство тестирования" к автоматической генерации пустых объектов — соглашусь. А если не сводить, то тут очень сильно бабка надвое сказала.

ГВ>>vdimas прав в том смысле, что если логика достаточно сложная, то и полные тесты достаточно трудно записывать. Вот тебе простейший пример (псевдокод):
C>И что тут сложного?

А я и не говорю, что это сложно. Я о сопоставлении сложности теста и тестируемого кода.

C> Элементраный тест (в условиях дотнет) с условно установленными моками.

Мммм... Дотнет его сам сгенерирует? Полностью? А за пивом он сгоняет?

[...]

ГВ>>То есть нужно проверить, что указанные сообщения ушли по заданным каналам, и только после определённого входного сообщения, и только в указанной последовательности, а потом ещё и желательно выдать осмысленное сообщение об ошибке.

C>Вы опять же путаете модульные тесты с интеграционными тестами. Модульные тесты не тестируют работу сети/жесткого диска/клавиатуры/мыши и т.д. Модульные тесты не тестируют взаимодействие подсистем. ит.д. и т.д. Короче, разберитесь в вопросе для начала, ок?

Даже если говорить о приведённом примере, то где здесь тестирование сети/жёсткого диска/...? Тестируется соответствие реального и предполагаемого протокола работы (form a specification, итить!). Или ты думаешь, что под sendMessage имеется в виду send в сокет?

А потом, модульным тестированием называется тестирование модулей. Что именно мы так называем — зависит от структуры программы. Запросто может быть тестирование модуля по имени "модуль сетевого интерфейса", который запросто может предполагать одновременный запуск тестов на нескольких машинах и в то же время другой модульный тест может проверять одну-единственную функцию. Если TDD предполагает, что это неправильное употребление термина "модульное тестирование", то тем хуже для самого TDD.

C>>>Еще один ликбез: описанное Вами не является модульными тестами. Это т.н. integration tests.
ГВ>>Это зависит от того, что в данной конфигурации полагается модулем, а что — интеграцией. Поскольку структура любой сложной программы иерархическая, то модуль на одном уровне — это сборная конструкция на другом.
C>Нет, не зависит. RTFM, как говорится.

Какой M нужно R?

ГВ>>И неужто будет проще, чем аналогичная заглушка? Это если учесть, то заглушка реализуется в естественном синтаксисе, а мок — перехватом вызовов. Второе будет почти гарантированно сложнее.
C>С этой глупостью я даже спорить не стану.

Не спорь.

V>>>>В декларативном синтаксисе мокков это выглядит как удаление гландов через Ж, и чем осмысленнее логика — тем более глубокое погружение в эту Ж. А если процедура внешняя, то это лишняя тестирующая сущность и все такое.
C>>>Демагогия.
ГВ>>Боюсь, что реальность. Хотя я в курсе, разумеется, что самая надёжная основа своей позиции — искусное отрицание очевидного.
C>Можете продолжать бояться. Как все-таки доберетесь до RTFM`а, то поймете, что я был прав.

О! Я прозрю истину. Ну дай же мне волшебный мануал! Я буду его R, R и ещё раз R.

ГВ>>Угу. А ещё программы должны быть простыми. Это и называется искать решение сложных проблем простыми средствами, сиречь — руководствоваться лозунгами.

C>Да, тестируемые участки кода должны быть простыми. В этом суть дизайна под названием Test Driven Development. Используя алгоритм write failing test -> write code -> until test succeed -> refactor ... добиваемся прекрасного качества кода с соблюдением всех правил современного программирования: DRY, SRP, и т.д. Если Ваш код на столько сложный и запутанный, что Вы не можете написать серию простых тестов для него, значит Ваш код — плохой. Вот Вам и пища для размышлений.

А если пользователь поставил задачу, которая не имеет простого решения? Значит, я не смогу написать простой тест и не смогу руководствоваться современными правилами программирования?

Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>>Ух ты! А я-то думал, что мокинг нужен для отслеживания последовательности внешних вызовов.
C>>Неправильно думали. Мокинг нужен в первую очередь для изоляции тестируемого объекта. Чтоб сделать возможной эту изоляцию возможной необходимо симулировать поведение внешних зависимостей тестируемого объекта.

ГВ>Так. Обратимся к первоисточникам:

ГВ>

Mocks [...] objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

ГВ>Моки — запрограммированы на ожидание вызовов в соответствии с определённой спецификацией. (Буквально: формируют спецификацию своими ожиданиями)

ГВ>Где сказано, что мок обязательно изолирует тестируемый объект от окружающих?

Даже и не знаю как Вам объяснить, что 2+2=4.

Даю наводящий вопрос: С какой целью создаются "objects pre-programmed with expectations which form a specification of the calls they are expected to receive"?

Можете мне не отвечать. Я ответ знаю. Ответьте себе. Если сможете, то поймете о чем идет речь. А не сможете — ну да и Бог с Вами.

C>>Само собою. Весь этот спор о том, что на С++ нет даже близко сравнимых по удобству инструментов для тестирования.

ГВ>Ну, если сводить "удобство тестирования" к автоматической генерации пустых объектов — соглашусь. А если не сводить, то тут очень сильно бабка надвое сказала.

Тестируются не пустые объекты, а поведение объектов в фиксированных (изолированных) условиях.

ГВ>>>vdimas прав в том смысле, что если логика достаточно сложная, то и полные тесты достаточно трудно записывать. Вот тебе простейший пример (псевдокод):
C>>И что тут сложного?

ГВ>А я и не говорю, что это сложно. Я о сопоставлении сложности теста и тестируемого кода.

И? Не вижу к чему Вы клоните.

C>> Элементраный тест (в условиях дотнет) с условно установленными моками.

ГВ>Мммм... Дотнет его сам сгенерирует? Полностью? А за пивом он сгоняет?

Полностью. Сгенерирует. Не вижу причину сарказма.

ГВ>[...]

ГВ>>>То есть нужно проверить, что указанные сообщения ушли по заданным каналам, и только после определённого входного сообщения, и только в указанной последовательности, а потом ещё и желательно выдать осмысленное сообщение об ошибке.

C>>Вы опять же путаете модульные тесты с интеграционными тестами. Модульные тесты не тестируют работу сети/жесткого диска/клавиатуры/мыши и т.д. Модульные тесты не тестируют взаимодействие подсистем. ит.д. и т.д. Короче, разберитесь в вопросе для начала, ок?

ГВ>Даже если говорить о приведённом примере, то где здесь тестирование сети/жёсткого диска/...? Тестируется соответствие реального и предполагаемого протокола работы (form a specification, итить!). Или ты думаешь, что под sendMessage имеется в виду send в сокет?

Если не предполагается, то RhinoMocks прекрасно справится с мокингом в этом случае. В чем проблема?

ГВ>А потом, модульным тестированием называется тестирование модулей. Что именно мы так называем — зависит от структуры программы. Запросто может быть тестирование модуля по имени "модуль сетевого интерфейса", который запросто может предполагать одновременный запуск тестов на нескольких машинах и в то же время другой модульный тест может проверять одну-единственную функцию.
Демагогия. Вы пытаетесь рассуждать логически, строя ложные выводы, основываясь не на реальных знаниях и опыте, а на дедукции и том, что Вы считаете логичным в меру Ваших познаний.
Почитайте Мартина Фоулера, почитайте Бекка... Да хотя бы, потратьте 10 минут да прочтите http://en.wikipedia.org/wiki/Unit_testing


ГВ>Если TDD предполагает, что это неправильное употребление термина "модульное тестирование", то тем хуже для самого TDD.

Тем хуже для Вас, а не для TDD.


C>>>>Еще один ликбез: описанное Вами не является модульными тестами. Это т.н. integration tests.
ГВ>>>Это зависит от того, что в данной конфигурации полагается модулем, а что — интеграцией. Поскольку структура любой сложной программы иерархическая, то модуль на одном уровне — это сборная конструкция на другом.
C>>Нет, не зависит. RTFM, как говорится.

ГВ>Какой M нужно R?

Смотрите выше.

ГВ>>>Угу. А ещё программы должны быть простыми. Это и называется искать решение сложных проблем простыми средствами, сиречь — руководствоваться лозунгами.

C>>Да, тестируемые участки кода должны быть простыми. В этом суть дизайна под названием Test Driven Development. Используя алгоритм write failing test -> write code -> until test succeed -> refactor ... добиваемся прекрасного качества кода с соблюдением всех правил современного программирования: DRY, SRP, и т.д. Если Ваш код на столько сложный и запутанный, что Вы не можете написать серию простых тестов для него, значит Ваш код — плохой. Вот Вам и пища для размышлений.

ГВ>А если пользователь поставил задачу, которая не имеет простого решения?

Знакомы с понятием "декомпозиция"?

ГВ>Значит, я не смогу написать простой тест и не смогу руководствоваться современными правилами программирования?

Сможете.

Здравствуйте, VladD2, Вы писали:

IID>>P.S.: подсказка: сам CLR написан на C/С++, и скорость выполнения .NET кода это, в определённом смысле, скорость выполнения некоторой С++ программы. Которую всегда можно, как минимум, не замедлить.

VD>Замечательная логика! Точнее ее полное отсутствие.

VD>Из этой предпосылки можно сделать вывод, что если написать компилятор, скажем, С на Руби, то получаемые программы будут иметь "в определенном смысле" (не знаю что за этим скрывается) скорость Руби (т.е. будут тормозными).

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

Здравствуйте, hattab, Вы писали:

VD>>Из этой предпосылки можно сделать вывод, что если написать компилятор, скажем, С на Руби, то получаемые программы будут иметь "в определенном смысле" (не знаю что за этим скрывается) скорость Руби (т.е. будут тормозными).

H>Ну, если исполняющей средой для таким образом скомпилированных приложений будет выступать Руби, то таки да, логично, что они будут тормозами.
Из чего сделано выделенное предположение?
Что мешает компилятору на Руби выдавать под LLVM, или сразу в машинные инструкции?

Здравствуйте, FR, Вы писали:

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

Мне кажется надо отделять треп на форумах и реальное применение.

Здравствуйте, hattab, Вы писали:

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

Уважаемый, ты точно правильно понимаешь значение слова компилятор?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, FR, Вы писали:

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

VD>Мне кажется надо отделять треп на форумах и реальное применение.

Так я вполне разделяю, лень просто статистику искать, из этого трепа вполне ясно что Intel'овский широко используется игроделами, мы не использовали, но интрисики и тотальную оптимизацию применяли широко, так что и у нас не было бы массива double в std::vector

Здравствуйте, hattab, Вы писали:

VD>>Из этой предпосылки можно сделать вывод, что если написать компилятор, скажем, С на Руби, то получаемые программы будут иметь "в определенном смысле" (не знаю что за этим скрывается) скорость Руби (т.е. будут тормозными).

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

О! Еще один перл в коллекцию. Второй за сегодня. Спасибо!

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:

G>>Я имею ввиду не использование компилятора С, а неиспользование возможностей C++ — классов, шаблонов, динамической памяти и прочего.
G>>Для числомолотилок оно и не нужно.

V>Во-первых, ты так и не объяснил мотивы, во-вторых, без нормального инлайна любая числомолотилка отсосет. Вот возьми класс complex, не представляю себе код для него без переопределённых инлайн операций. Вызывать что-ли ф-ии типа complex_add_double(arg1, arg2)? Это будет уже не числомолотилка, а тормозилка.

Если complex_add_double — макрос, то будет умеренно быстро с любым компилятором, кроме того никто не запрещает брать современный C++ компилятор и отключать манглинг для экспортируемыхметодов.
А мотив очень простой. Голый C интеропается с программой на любом языке. Если не использовать динамическое выделение памяти, указатели, наследование, полиморфизм и шаблоны и прочую высокоуровневую лабуду, то пропадают все проблемы, присущие C++.
Кроме того, повышается переносимость кода. При удачном стечении обстоятельств можно взять код на С и запустить его на видеокарте с помощью CUDA.

Здравствуйте, vdimas, Вы писали:

G>>С учетом этих ускорений код на .NET, который проигрывал плюсовому в 1,5-2 раза стал выигрывать у плюсовго по скорости.
G>>И это даже бех перекомпиляции программ.

V>Это от сценариев зависит, там, где была нагрузка на GC, общая производительность действительно выросла. Лично я ожидал оптимизаций по доступу к массивам, тем более, что о возможностях подобной оптимизации JIT-компилятора тогда не говорил только ленивый, однако никаких изменений в этом плане не было, поэтому на числомолотилках C# продолжает сосать.
Проснись, оптимизация дотупа к массивам давно сущесвует.

В цикле такого вида JIT выкидывает проверки границ

for(int i=0; i<array.Length; i++)
{
}

Если нужет произвольный быстрый доступ, то есть unsafe.

Что касает числомолотилок, то в самых тупых линейных случаях (как md5 например), при использовании uncheked, .NET будет проигрывать на проценты. Что в реальной программе погоды не сделает.
Кроме того такие случаи элементарно оптимизируются заменой на Сшный код или распараллеливаются (в .NET далется очень легко).

ЗЫ. Я ещ не упоминул такие оптимизации, которые делает mono. См Mono.Simd

Здравствуйте, criosray, Вы писали:

ГВ>>Где сказано, что мок обязательно изолирует тестируемый объект от окружающих?
C>Даже и не знаю как Вам объяснить, что 2+2=4.

Никак, потому что в упомянутом мной фрагменте из фаулеровской писанины ни о каких изоляциях речи не было.

C>Даю наводящий вопрос: С какой целью создаются "objects pre-programmed with expectations which form a specification of the calls they are expected to receive"?

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

C>Можете мне не отвечать. Я ответ знаю. Ответьте себе. Если сможете, то поймете о чем идет речь. А не сможете — ну да и Бог с Вами.

Ну и как, смог?

C>>>Само собою. Весь этот спор о том, что на С++ нет даже близко сравнимых по удобству инструментов для тестирования.

ГВ>>Ну, если сводить "удобство тестирования" к автоматической генерации пустых объектов — соглашусь. А если не сводить, то тут очень сильно бабка надвое сказала.
C>Тестируются не пустые объекты, а поведение объектов в фиксированных (изолированных) условиях.

"Пустые объекты" в смысле "тестовое окружение из пустых объектов". Ну или вырожденные до шлюзов к стабам (фейкам) и другим объектам окружения.

ГВ>>>>vdimas прав в том смысле, что если логика достаточно сложная, то и полные тесты достаточно трудно записывать. Вот тебе простейший пример (псевдокод):
C>>>И что тут сложного?

ГВ>>А я и не говорю, что это сложно. Я о сопоставлении сложности теста и тестируемого кода.
C>И? Не вижу к чему Вы клоните.

Прямо к тому, о чём сказал — к сравнению сложности теста и тестируемой программы. Поднимись на пару сообщений вверх, там всё написано. Тест иной раз принципиально не может быть проще тестируемой программы.

C>>> Элементраный тест (в условиях дотнет) с условно установленными моками.

ГВ>>Мммм... Дотнет его сам сгенерирует? Полностью? А за пивом он сгоняет?
C>Полностью. Сгенерирует. Не вижу причину сарказма.

Что он сгенерирует и на основе чего? Как сгенерировать пустой мок — понятно (пробежались по списку внешних вызовов и ссылок, и автоматом получили "пустой мок"). Вопрос — как сгенерировать наполнение этого мока, представляющее собой ту самую спецификацию, которую мок ожидает.

ГВ>>[...]

ГВ>>Даже если говорить о приведённом примере, то где здесь тестирование сети/жёсткого диска/...? Тестируется соответствие реального и предполагаемого протокола работы (form a specification, итить!). Или ты думаешь, что под sendMessage имеется в виду send в сокет?

C>Если не предполагается, то RhinoMocks прекрасно справится с мокингом в этом случае. В чем проблема?

Все нужные Expect(sendMessage ...) RhinoMocks сам напишет?

ГВ>>А потом, модульным тестированием называется тестирование модулей. Что именно мы так называем — зависит от структуры программы. Запросто может быть тестирование модуля по имени "модуль сетевого интерфейса", который запросто может предполагать одновременный запуск тестов на нескольких машинах и в то же время другой модульный тест может проверять одну-единственную функцию.
C>Демагогия. Вы пытаетесь рассуждать логически, строя ложные выводы, основываясь не на реальных знаниях и опыте, а на дедукции и том, что Вы считаете логичным в меру Ваших познаний.

Интересно, откуда уверенность в оценке моих реальных знаний и опыта? Считай, что мне это просто любопытно.

C>Почитайте Мартина Фоулера, почитайте Бекка... Да хотя бы, потратьте 10 минут да прочтите http://en.wikipedia.org/wiki/Unit_testing

Хорошо. Википедия ближе всего для цитирования:

Модульное тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы. Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода.(Глупость в википедии никогда не надо искать долго, достаточно двух предложений. — прим. Г.В.) Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже написанных и оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.

Собственно, вот здесь даны несколько более корректные объяснения феномену модульного тестирования. Почитай на досуге.

ГВ>>Если TDD предполагает, что это неправильное употребление термина "модульное тестирование", то тем хуже для самого TDD.

C>Тем хуже для Вас, а не для TDD.

Да нет, именно что для TDD. Жонглирование и произвольная реинтерпретация терминов ещё никого до добра не доводила.

C>>>Да, тестируемые участки кода должны быть простыми. [...]
ГВ>>А если пользователь поставил задачу, которая не имеет простого решения?
C>Знакомы с понятием "декомпозиция"?

Я надеюсь, тебе не придёт в голову отсылать меня в википедию по этому поводу?

ГВ>>Значит, я не смогу написать простой тест и не смогу руководствоваться современными правилами программирования?
C>Сможете.

Группа маленьких модулей логически объединена в общий модуль, с которым программа работает через некоторый интерфейс. Этот сборный модуль тестируется отдельным набором тестов... Как называется это тестирование?

Здравствуйте, samius, Вы писали:

VD>>>Из этой предпосылки можно сделать вывод, что если написать компилятор, скажем, С на Руби, то получаемые программы будут иметь "в определенном смысле" (не знаю что за этим скрывается) скорость Руби (т.е. будут тормозными).

H>>Ну, если исполняющей средой для таким образом скомпилированных приложений будет выступать Руби, то таки да, логично, что они будут тормозами.
S>Из чего сделано выделенное предположение?

Это не предположение, это этакая параллель... .NET core библиотеки-то насквозь C++'сные.

S>Что мешает компилятору на Руби выдавать под LLVM, или сразу в машинные инструкции?

Ничего не мешает.

Здравствуйте, VladD2, Вы писали:

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

VD>Уважаемый, ты точно правильно понимаешь значение слова компилятор?

Не сомневайся. Но вот о чем следует подумать, так это о том, что исполняющийся код будет работать не в вакууме. Или вы тут копья ломаете по поводу перформанса кода вида "x + y"?

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, samius, Вы писали:

VD>>>>Из этой предпосылки можно сделать вывод, что если написать компилятор, скажем, С на Руби, то получаемые программы будут иметь "в определенном смысле" (не знаю что за этим скрывается) скорость Руби (т.е. будут тормозными).

H>>>Ну, если исполняющей средой для таким образом скомпилированных приложений будет выступать Руби, то таки да, логично, что они будут тормозами.
S>>Из чего сделано выделенное предположение?

H>Это не предположение, это этакая параллель... .NET core библиотеки-то насквозь C++'сные.
(я бы сказал, что местами)
Так вот откуда ноги растут у тормознутости дотнета

Здравствуйте, hattab, Вы писали:

H>Это не предположение, это этакая параллель... .NET core библиотеки-то насквозь C++'сные.

Да, ну? А почему 99% из них декомпилируется Рефлектором?

S>>Что мешает компилятору на Руби выдавать под LLVM, или сразу в машинные инструкции?

H>Ничего не мешает.

Ну, так ты понял, что спорол чушь?

Здравствуйте, hattab, Вы писали:

H>Не сомневайся. Но вот о чем следует подумать, так это о том, что исполняющийся код будет работать не в вакууме.

Думаю понятие вакуума к коду вообще не применимо. Код будет исполняться процессором.
В остальном есть такие вещи как бутсрапинг. Слышал про такое?

H>Или вы тут копья ломаете по поводу перформанса кода вида "x + y"?

Да, в общем-то любой код состоит из ряда примитивных операций.