>Кто сможет обойтись без него.

#include <iostream> using namespace std;

#define REPEAT(n,OP) REPEAT ## n(OP) #define REPEAT0(OP) #define REPEAT1(OP) OP #define REPEAT2(OP) REPEAT1(OP); OP ..... #define REPEAT10(OP) REPEAT9(OP); OP

int main(int argc,char* argv[]) { REPEAT(10,std::cout << "hello world!" << std::endl); return 0; }

Гы-гы :))

C форматированием

#include <iostream> 
using namespace std;

#define REPEAT(n,OP) REPEAT ## n(OP) 
#define REPEAT0(OP) 
#define REPEAT1(OP) OP 
#define REPEAT2(OP) REPEAT1(OP); OP 
..... 
#define REPEAT10(OP) REPEAT9(OP); OP

int main(int argc,char* argv[]) 
{ 
  REPEAT(10,std::cout << "hello world!" << std::endl); 
  return 0; 
}

Гы-гы :)) 

REPEAT256 ? LIST345 ? Ы?

>Кстати, хороший пример того, как С++ провоцирует на ошибки. Ладно, в этом случае Вы бы получили ошибку компиляции.

То, что плюсы провоцируют на ошибки, равно как и плюсов многословность -- ни для кого не секрет. Ну дык, не бывает серебряной пули, за все надо платить. Типа, за выразительную мощь :) Сколькими способами можно hello world 10 раз вывести :))

>REPEAT256 ? LIST345 ? Ы?

Для 256 и 345 _эффективней_ сделать цикл, не правда ли? Ы? Явно, или в аналог generate его запрятать. А для пары тройки десяток можно и заголовок сгенерить.

> Для 256 и 345 _эффективней_ сделать цикл, не правда ли? Ы?

Может да, может нет.

> А для пары тройки десяток можно и заголовок сгенерить.

То есть средствами С++ этого сделать нельзя и надо обязательно писать генератор (т.е. компилятор свого ЯП в с++) ?

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

>То есть средствами С++ этого сделать нельзя

Средствами C++ сгенерировать на этапе компиляции заголовок для REPEATX для любого X -- да, нельзя. Однако, средствами C++ можно написать библиотеку для Template Metaprogramming (абстракцию:) для кода Captain) и пользовать ее когда надо. Можно даже сделать так, чтобы до заданного N разворачивалось в шаблоны, а после -- в цикл.

>надо обязательно писать генератор (т.е. компилятор свого ЯП в с++) ?

Если считать генератором библиотеку для Template Metaprogramming, или генератор заголовка для REPEAT, то да -- без него не обойтись.

>Про исключения - мы уже договорились, что исключения в первой версии не
>обрабатываются нормально

В первой версии чего?

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

Все обрабатывается нормально.
Если в конструкторе произошло исключение во время инициализации
глобальнго или статического экземпляра - будет вызвана или
std::unexpected() или std::terminate(). Не стоит утверждать
того, чего не знаешь!

>о мы же измеряли скорость ОО подхода в ОО языке против не-ОО подхода >в не-ОО языке

Глупости. Вы меряете производительность различных реализаций и даже не
одного и того же!

До свидания.

Captain.

> Типа крутая язва. Мальчуган иди не зли дядей.

(В режиме Tex paragraphs игнорируются переносы строк. Пустая строка (два раза Enter) начинает новый абзац.

Иди, изобретай тип byte (скоко в не хоть битов?)

1) Не затруднит привести реализацию, способную повторить любой кусок ++ кода заднное число раз? Т.е. типа (cout && (cout << "AAA")) x 10?

2) Что и требовалось доказать.

В первой версии программы "улучшенной", для С++.

Про std::unexpected я действительно не знал. Спасибо. Правда, в коде программы оно все равно никак не используется:) Вообще, выделять память, когда можно спокойно передать просто адрес строки в сегменте статических данных - не очень красиво, правда? Хотя и более ОО.

Я измеряю производительность программ при выполнении одной и той же задачи - созданных на основе разных технологий. По-моему, измерение проведено корректно. Кстати, до сих пор никто мне не посоветовал хороших ключей для оптимизации...

> Не затруднит привести реализацию, способную повторить любой кусок ++ кода заднное число раз?

Никаких проблем. Однако, чтобы пользоваться этой реализацией, пользователю придется приложить определенные усилия -- ручками обернуть свой любой кусок кода в функциональный объект. Иначе никак. Однако, бесплатных пирожных никто не обещал.

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

А как на С++ создать анонимный функциональный объект анонимного класса? И почему это должен делать _я_, да еще и вручную каждый раз?

> Иначе никак. Однако, бесплатных пирожных никто не обещал.

Бесплатные - не нужны, нужны съедобные и вкусные (желательно).

>А как на С++ создать анонимный функциональный объект анонимного класса?

Есть например Lambda Library.

>И почему это должен делать _я_, да еще и вручную каждый раз?

Потому что С++ -- такой язык. Предоставляемые им возможности ограниченны, что-то приходится делать руками. Однако, С++ позволяет реализовать это довольно эффективно.

>нужны съедобные и вкусные (желательно).

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

2. Однако, поскольку С++ позволяет, извиняюсь, писать в разных парадигмах, иногда (и часто) проще сделать на нем и весь проект, чем возиться с несколькими языками. Тут яву то с плюсами сопрягать замаешься, столько нужно мусора писать, и эффективность падает.

3. Никто и не позиционирует C++ для Rapid Application/Algorithm Development. Для этого есть Matlab с Maple :))

C++ apology

Ну вот, докатились. Я вот еще больше заступаюсь за ОО и за С++, при этом окончил мехмат с красным дипломом, точнее с одной всего четверкой и защитил там кандидатскую. Ну, математик, значит я тоже - гуманитарий религиозный? Я не хочу мериться кто что сделал, я просто хочу сказать, СНИМИТЕ ШОРЫ и признайте, что у людей могут быть разные взгляды и пристрастия. Адью

C++ apology

Я имел в виду мехмат МГУ, конечно.

C++ apology

А можно и так:

#include <iostream>
using namespace std;

void mama_rodnaya(int n)
{
  if(n>0)
    cout << 10-n << " :Mama rodnaya, do chego ze mi dokatilis!" << endl;
  else return;
  mama_rodnaya(n-1);
}

int main()
{
  mama_rodnaya(10);
}

Для прикола, просто. Нету циклы. ;)

>Для прикола, просто. Нету циклы. ;)

На рантайме и дурак рекурсию напишет. Идея сделать рекурсию во время компиляции. :)

> Попробовал. Извините, под винюки перегружаться было влом - использовал gcc (уже вижу летящую в меня кучу камней). Без оптимизаций вообще (вторая куча камней показалась в воздухе). Тест - элементарный - 1е6 раз вывел Hello World на стандартый выход. Очевидно, при тестировании в качестве оного использовал /dev/null. Для измерения использовал старый добрый time.

...

> Принимаются предложения по ключам оптимизации - как для С, так и для С++.

нечего там оптимизировать. могу предположить большую часть от real 0m2.918s заняла подгрузка libstdc++ (если до запуска теста не работало ни одной плюсовой программы). в случае с сишной программой время на загрузку libc не тратилось.

Не угадали. Тот же самый тест, но на 10 проходов (вместо 1е6) дает цифры 0, 0, 0. Все-таки Пентиум М 1.6 - быстрый проц. И библиотеки все уже сто лет в кэше (например, благодаря мозилле). Так что загрузка libstdc++ непричем. Другие идеи есть? И неужели ничего соптимизировать, синлайнить "до предела" низзя? Как-то уж очень велика разница - на порядки...

2anonymous (*) (20.11.2003 19:31:09): "Иди, изобретай тип byte (скоко в не хоть битов?)"

Как два пальца... http://www.ada-ru.org/V-0.3w/part_1/ch_02.html#s2.2.7

2 anonymous (*) (20.11.2003 18:14:06)
2 anonymous (*) (20.11.2003 18:22:03)

Ну вы блин пацаны даете!

=========================================
#include <algorithm>
#include <iostream>
#include <iterator>

using namespace std;

int main()
{
fill_n(ostream_iterator<const char*>(cout, "\n"), 10, "Hello World");
return 0;
}
=========================================

Bce.

C++ apology

Вот она, истина. Действительно ВСЕ. обалдеть как можно заколотить маленький гвоздик электронным микроскопом. :)

Анонимусу, который производительность тестировал
посвящается ;-)

=====[1.c]========
#include <stdio.h>

int main()
{
    double d=0.0;
    
    for(;d<1e6;d+=0.6781)
	printf("%6.2f ",d);
    
    return 0;
}
==================

#gcc -o 1 1.c
#time ./1 > /dev/null
real    0m5.892s
user    0m4.950s
sys     0m0.018s
 
====[1.cpp]=======
#include <iostream>

using namespace std;

int main()
{
    cout.sync_with_stdio(false);
    for(double d=0.0;d<1e6;d+=0.6781)
    {
	cout.width(6);
	cout.precision(2);
	cout.setf(ios::left,ios::adjustfield);
	cout << d << ' ';
    }
    
    return 0;
}
===================
#g++ -o 1.p 1.cpp
#time ./1.p > /dev/null
real    0m2.835s
user    0m2.266s
sys     0m0.009s

#gcc --version2.95.4
#uname -sr
FreeBSD 4.9-STABLE

Стыдно товарищи про sync_with_stdio не знать...
Страуструпа читать быстро!!!!

Большое спасибо за подсказку. Хорошая оптимизация:). Правда, у меня С все равно быстрее (0.190s vs 0.255s). Но это уже совсем другая разница. Ею даже пренебречь, в общем, можно. Да, моя система - Федора. gcc 3.3.2

Ура. Честь потоков С++ в области производительности, в общем, восстановлена. Чего я, соббсно, и ожидал - не мог я поверить, что они ТАК плохи. Правда, на мое личное отношение к этому языку это мало повлияет. Не за это я его не люблю... И Строструпа читать, извините, не побегу - не хочу возвращаться в плюсовый мир.

Люблю С++, это самый гибкий и мощный язык на сегодня, и нехер тут писать что он устарел и выдвигать всякие интерпретируемые безделушки в качестве альтернативы. Вообще давно пора начать писать системы на С++. Все-таки ИМХО лучше сначала подумать головой, грамотно все спроектировать, и потом не иметь количество багов и неэффективного кода, возрастающее по экспоненте (типичный большой проект на С). Особенно блевать тянет от API Гнома. Просто люди всеми силами пытались избежать изучения С++ и реализовали имитацию объектов на С. Жалко бедняг, и тех кому под этот API приходится писать.

Ух. Заявление прямо-таки программное!

1. Я не помню, говорил ли кто-нибудь тут про устаревание С++. Я утверждал только, что он по ряду причин плох (и не говорил, что он был хорош в момент рождения). Причины - во многих случаях низкая эффективность, провоцирование ошибок. Причем проблема в том, что да, можно написать хороший и эффективный код на С++. Можно даже написать хороший ОО код на С++. Но это совсем непросто. И знаете почему? Этот язык _провоцирует_ на написание кода, который сложно поддерживать - и на написание медленного кода. Тут на ЛОР потребовался ДЕНЬ, чтобы понять, почему Hello World на С++ на порядки медленнее. Да, можно сказать - тут все чайники, ничего не знают. Но я думаю, дело не только в этом. Далее, про провоцирование ошибок. Переопределение операторов, конструкторы копирования - все это страшные силы, направленные _против_ разработчика. А как реализована рефлексия? А такой механизм, как exceptions? Скорость, понятное дело, идет побоку... А ведь люди думают - раз С++, то будет быстро. И давай лепить typeof...

2. Подумать головой - это прекрасно - это для любого языка полезно.

3. Ваши ... физиологические трудности от API гнома - это следствие Вашего личного опыта, системы ценностей и пр. Т.е. явление глубоко индивидуальное. На самом деле, и гномовские, и винюковские, и обычные иксовые API - нормальное применение ОО-подхода для не ОО-языка. И не надо жалеть тех, кто их использует - нам не так уж и плохо:) Вы действительно верите, что люди начали писать гном на С от незнания С++? Тот же вопрос про win32, про OpenGL (правда, его API не очень ОО) и пр. C-based ОО API (которых, халва аллаху, сегодня на порядки больше, чем API на С++).

Человечество выработало некий стандарт де-факто на публичные API. И этот стандарт - С. Чтобы имена были простыми (а не замангленными до неузнаваемости). Чтобы не пришлось думать, как транслировать семантику exceptions в языки, в которых их нет.

Большие, сложные приложения с красивым интерфейсом для конечного пользователя - прекрасная ниша для С++. А системные, платформообразующие модули должны бы иметь API в терминах С (разумеется, это не исключает bindings в другие языки). Это мое ИМХО, конечно. И, опять же ИМХО, С++ слишком гибок и слишком мощен. Чтобы обуздать мощь этого мустанга, нужно очень хорошо знать его повадки - и на каких местах он может отлягать...

> Анонимусу, который производительность тестировал посвящается ;-)

Спасибо.

> cout.sync_with_stdio(false);

Учел ваше замечание, вот результаты с его учетом :)

$ time ./testout_c > /dev/null

4.97user 0.02system 0:04.99elapsed 99%CPU

$ time ./testout_cc > /dev/null

10.27user 0.01system 0:10.27elapsed 100%CPU

$time ./testout_cc2 > /dev/null

10.18user 0.00system 0:10.18elapsed 99%CPU

>Стыдно товарищи про sync_with_stdio не знать...

Мне ОЧЕНЬ стыдно.

> Страуструпа читать быстро!!!!

Нет, лучше смерть.

C++ apology

1. Ну здрасте. В С++ есть и стдио.х для экономных. Это, кстати, уже говорили здесь.

Потоки - это целая накрутка... хотя, в потоках есть много всего... Так, есть очень быстрые приемы для файловых потоков, например. Я не стану писать здесь код. Но у меня есть опыт ускорения реальной программы на порядок (или около того), когда я просто стал использовать потоковые методы типа pubseekoff, sgetn и тому подобные.

2. Полностью поддерживаю. Вообще, давайте решим раз и навсегда: язык - это дело вкуса (если речь не идет о фортране-77, это у меня наболело здесь в компьютерном центре).

3. Это тоже верно. В конце концов, паскаль - это тоже здорово ;). Мне эстетически нравится код на С++, а есть люди, считающие Дельфей - верхом совершенства.

Однако, я прекрасно пишу сложные научные и не только приложения на С++ и далеко не я один, даже здесь, в Штатах. А главное, это выходит довольно успешно. ;)

СТЛ вектор, кстати, говорит Страуструп, также эффективен как С-шные массивы-указатели. ;) И когда все приходится писать для бооольшущей машины с МПИ, то С++ (впрочем, С тоже) гораздо лучше стыкуется с МПИ, чем фортран, не к ночи будет помянут.

2 atoku (*) (21.11.2003 6:48:59)

>СТЛ вектор, кстати, говорит Страуструп, также эффективен как С-шные массивы-указатели. ;)

,) Согласно Страуструпу сортировка векторов std::sort'ом на длинных векторах на 25%-50% быстрее чем сортировка C array'я C'шным qsort'ом из-за отсутствия overhead'а вызова функции-компаратора.

Это маааленький такой камешек в огород людей которые свято верят что ничего совершеннее plain C в этом мире нет ,)

> ,) Согласно Страуструпу

Ага.

> сортировка векторов std::sort'ом на длинных векторах на 25%-50% быстрее чем сортировка C array'я C'шным qsort'ом из-за отсутствия overhead'а вызова функции-компаратора.

Векторов чего? int? Для сортировки вектора целых и в Си можно написать сортировку без "функции-компаратора".

ЗЫ Антихриста на вас нету.

>А нук-ка Жабу не трож! Что в одну кучу валишь? Что общего у С++ с java?

Тем, что обои не умеют расширять свой синтаксис /немогут использоваться в качестве мета-языка для создания своего проблемно-ориентированного языка/, и обои имеют сходную убогую ОО-модель. Пример неубогой - CLOS (или его почти полнофункциональная реинкарнация в виде GOOPS)

>Все-таки ИМХО лучше сначала подумать головой, грамотно все спроектировать

Как показывает практика - это невозможно. Теоритеческое обоснование - у того же Г. Буча. Что-то типа "почему программа является сложной системой".

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

Про сльтернативы "проектированию сверху вниз" читать у Грэхэма: http://paulgraham.ru

2dsa (*) (21.11.2003 9:08:46)

>не умеют расширять свой синтаксис /немогут использоваться в качестве >мета-языка для создания своего проблемно-ориентированного языка/

Ты серьезно счетаешь этот бред достоинством??? Ты что-нибудь слышал про "правильность программ"?

>>не умеют расширять свой синтаксис /немогут использоваться в качестве мета-языка для создания своего проблемно-ориентированного языка/

>Ты серьезно счетаешь этот бред достоинством???

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

>Ты что-нибудь слышал про "правильность программ"?

Много чего. Настолько много, что не могу понять, именно ты имеешь в виду.

Серёжа ты не вовсёи прав, CLOS хорошая вещь спору нет.

Но в прикладном применении "хреновый" C++ даёт фору "хорошим языкам", за счёт того что на нем относительно легко реализовывается всё. Драйвера на C++ я бы писать не стал (asm, c), а прикладухи пишу с удовольствием.

Кто-то говорил про провоцирование ошибок. Ошибки провоцирует плохая голова и отсутствие проектирования. По молодости я сам ни хрена не проектировал и не документировал. А теперь с сотрудников три шкуры снимаю за отсутствие проектной документации к программным продуктам. Это как некоторым кажется пустое занятие окупается эффективностью взаимодействия подсистем и отсутствием проблем при увольнении некоторых сотрудников. както в форумах проскальзовало - указатели это беда (сплошные ошибки дают). Херня скорость и удобство неоспоримы.

Серёж, поддерживал когда-нибудь чужие продукты, приличной весомости?

Мне приходилось с этим очень часто возится.

И опять таки всё дело вкуса и ЗАДАЧ.

Книжка Буча весьма неплоха, а картинки просто класс.

>Причины - во многих случаях низкая эффективность,

Низкая эффективность по сравнению С ЧЕМ? По сравнению с Си? а) не всегда б) а чем в Си за эффективность платим? Кошмаром форматной строки и sprintf ? (это для нашего примера с выводом)? А как насчет других "языков высокого уровня", обладающих примерно такими же возможностями?

>конструкторы копирования - все это страшные силы, направленные _против_ разработчика.

Ну, что такого злого в конструкторах копирования? А вопрос о полезности переопределения операторов -- чисто религиозный. Не аргумент.

>А такой механизм, как exceptions? Скорость, понятное дело, идет побоку...

А как exceptions реализованы в Java ? Вот уж где скорость идет побоку...

>А ведь люди думают - раз С++, то будет быстро. И давай лепить typeof.

Что люди лепят на Java, вообще страшно подумать. Между List и ArrayList половина разницы не видит.

>не умеют расширять свой синтаксис /немогут использоваться в качестве >мета-языка для создания своего проблемно-ориентированного языка/

C++ -- умеет. В виде переопределения операторов например. Только зачем это расширение синтаксиса нужно? Фетиш? Когда это реально помогает? Тут люди от примитивных возможностей в виде перегрузки операторов шарахаются как черт от ладана. С, во многих случаях, резонным вопросом "а что здесь этот плюсик означает"?

> Пример неубогой - CLOS

И сколько эта неубогая модель стоит?

> Кошмаром форматной строки

Форматная строка не кошмар, а замечательный встроенный язык для форматирования, после которого от (много|пусто)словия cout.width(), cout.precision() ios::blah-blah-blah ТОШНИТ.

>а замечательный встроенный язык для форматирования

Без каких бы то ни было проверок корректности.

>ТОШНИТ.

А меня тошнит от процентиков-точечек-слешей форматной строки. Театр закрывается -- нас всех тошнит.

>Серёжа ты не вовсёи прав, CLOS хорошая вещь спору нет.

Не. Уже нет. Без closures и continuations лисп совсем не интересен. Да пытаться вписаться в голую функциональщину - себя не любить, а попускаться, и писать в процедурном стиле на нём как-то против шерсти.

А CLOS - писать на нём сейчас смысла особого нет, но знать необходимо - как одну из двух полноценных реализаций ОО-подхода (вторая - очевидно smalltalk)

>Но в прикладном применении "хреновый" C++ даёт фору "хорошим языкам",за счёт того что на нем относительно легко реализовывается всё

А и не надо реализовывать "всё". Emacs отнюдь не "весь" написан на Elisp. Для каждого уровня лучше свой язык. И комбинации c+Scheme,c+tcl,c+Ocaml,c+Slang(Slrn!) как раз дадут фору чему угодно - тут тебе и эффективность, и надёжность, и полноценное ОО (а не кастрированый обрезок имени г-на Страуструпа) и возможности, которые предоставляет, метаязыка и нормальные тулкиты.

> Кто-то говорил про провоцирование ошибок. Ошибки провоцирует плохая голова и отсутствие проектирования.

Да бог с ним - "провоцирует". Достаточно того, что не помогает. Ну глупо это писать программы на тысячи-десятки тысяч строк на языке, в котором нужно самому следить за памятью и указателями. Да плюс ещё зубодробительные темплейты, которые по читабельности приближаются к sendmail.cf. А проектирование - это отдельная тема. Если коротко - оно или невозможно в принципе, или требует бешенных денег и умных голов, которых по меру наберётся буквально хорошо, если несколько тысяч. В реальной жизни, как раз нужна именно уникальная особенность CL быть "программируемым языком программирования", что бы писать полностью в терминах предметной области одновременно минимизируя стоимость ошибок проектирования (которые просто неизбежны) и повышая производительность кодёров (стоимость строчки кода).

>Книжка Буча весьма неплоха,

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

>Серёж, поддерживал когда-нибудь чужие продукты, приличной весомости?

К счастью ли, к несчастью - сейчас уже в стадии, когда я такие продукты покупаю и пользую. И качество того с чем приходится жить - ужасает. Вон OpenView'шные клиенты, что плюсовые, что жабные... это ж слёзы. Кровавые. И такого же качества ~ те самые 70% программ, которые якобы написаны на C++. А рядом - Emacs, который тянет груз 20-летней давности и необходимости поддерживать десяток платформ, но работать с котороым - одно удовольствие и минимум затрат.

>не умеют расширять свой синтаксис /немогут использоваться в качестве мета-языка для создания своего проблемно-ориентированного языка/

>C++ -- умеет. В виде переопределения операторов например.

Хи-хи. Мне пожалуйста реализацию простенькой синтаксической конструкции, назвём её or2, которая принимает операндами два выражения, вычисляет превое, и, если оно не нулевое - возвращает полученное значение, в противном случае просто возвращает значение второго выражения.

>Только зачем это расширение синтаксиса нужно?

Если путать создание новых _операторов_ с возможностью определения одноимённых _функций_ способных принимать разные аргументы, то ты ответа на свой вопрос никогда не получишь. А первое нужно, чтобы получить настоящий высокоуровневый предметно-ориентированный язык, который повысит производительность и снизит требования к квалификации кодёров/саппорта. См. языки на которых пишут программисты 1C, R3, Elisp, всевозможных CAD'ов и т.п.

> Пример неубогой - CLOS И сколько эта неубогая модель стоит?

А сколько может стоить модель? Сколько стоит COM? Или CORBA? Нисколько не стоит. Равно как и несколько её реализаций.

>Ну, что такого злого в конструкторах копирования?

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

вот вам смеешная цитата "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind."- Alan Kay

dsa - respect, так их ;))))

> Без каких бы то ни было проверок корректности.

Корректности чего?

Ну так что, кстати, ответа на то почему при написании OS/400 использовался именно С++ так и не будет? :)

> dsa: "См. языки на которых пишут программисты 1C, R3,.."

да, в 1С без базара рульный язык. ;)

>Корректности чего?

Соответствия форматной строки типам аргументов.

>Мне пожалуйста реализацию простенькой синтаксической конструкции, назвём её or2,

А зачем вам такая конструкция? И чем вас в таком случае не устраивает || ? Опять будем надуманные задачи ставить -- hello-world 10 раз на этапе компиляции, и чтоб в одну строку и чтоб без шаблонов?

>Если путать создание новых _операторов_ с возможностью определения одноимённых _функций_ способных принимать разные аргументы

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

>А первое нужно, чтобы получить настоящий высокоуровневый предметно-ориентированный язык,

Зачем все это нужно В ОДНОМ языке?

>А сколько может стоить модель?

Сколько может стоить _поддержка_ модели? В какие накладные расходы на рантайме это обходится. Сколько нужно платить за фичи, которые реально нужны в одном случае из 100?