LINUX.ORG.RU

История изменений

Исправление Manhunt, (текущая версия) :

Твой вопрос был про то, какие design decisions в c++ определяют его нишу. Я привёл те решения, которые лично мне кажутся наиболее судьбоносными. Но не жди, что я буду тебе эти решения продавать как правильные или удачные: не люблю c++.

2. Zero overhead

Относительно чего? :-)

Другая формулировка этого принципа - «ты не платишь за то, чем не пользуешься». То есть добавление в язык очередной фичи (скажем, относительно набора фич голого Си) не должно вносить какой-либо оверхед для тех программ, которые этой новой фичей не пользуются.

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

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

Это всё всего лишь сахар над Си :-)

Так можно договориться до того, что Go — это просто сахар над шестнадцатеричными машинными кодами. Где по-твоему проходит граница между сахаром и не-сахаром?

Т.е. на языке шаблонов цепепе можно писать целые HTTP-серверы и клиенты, которые будут работать прямо в компайл-тайме :-)

Ну вот, например, в компайлтайме генерируют парсер регулярного выражения (то есть в рантайме фаза компиляции регулярного выражения будет отсутствовать): static regexes require no state tables, virtual functions, byte-code or calls through function pointers that cannot be resolved at compile time.

Люди на практике пишут compile-time algorithms.

Эта тьюринг полнота шаблонов как не пришей кобыле хвост :-)

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

Исходная версия Manhunt, :

Твой вопрос был про то, какие design decisions в c++ определяют его нишу. Я привёл те решения, которые лично мне кажутся наиболее судьбоносными. Но не жди, что я буду тебе эти решения продавать как правильные или удачные: не люблю c++.

2. Zero overhead

Относительно чего? :-)

Другая формулировка этого принципа - «ты не платишь за то, чем не пользуешься». То есть добавление в язык очередной фичи (скажем, относительно набора фич голого Си) не должно вносить какой-либо оверхед для тех программ, которые этой новой фичей не пользуются.

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

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

Это всё всего лишь сахар над Си :-)

Так можно договориться до того, что Go — это просто сахар над шестнадцатеричными машинными кодами. Где по-твоему проходит граница между сахаром и не-сахаром?

Т.е. на языке шаблонов цепепе можно писать целые HTTP-серверы и клиенты, которые будут работать прямо в компайл-тайме :-)

Ну вот, например, в компайлтайме генерируют парсер регулярного выражения (то есть в рантайме фаза компиляции регулярного выражения будет отсутствовать): static regexes require no state tables, virtual functions, byte-code or calls through function pointers that cannot be resolved at compile time.

Люди на практике пишут compile-time algorithms.

Эта тьюринг полнота шаблонов как не пришей кобыле хвост :-)

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