M>class A
M>{
M> hidden[60]; //60 hidden bytes
M> int a; //public
M> int b; //public
M> virtual f(int fx)[20] //это обьявление публичной вирт функции и обьявление ее смещения в вирт таблице
M> virtual ff()[32] //еще публ.вирт функция со смещением
M>}

M>по такому описанию компилятор извне работал бы спокойно и размер типа известен и смещения виртметодов.

нет. не смог бы компилятор. надо еще общий размер вирттаблицы этого класса нарисовать ему.
M>class A
M>{
M> hidden[60]; //60 hidden bytes
M> int a; //public
M> int b; //public
M> virtabsize[80] ; //типа так!
virtual f(int fx)[20] //это обьявление публичной вирт функции и обьявление ее смещения в вирт таблице
M> virtual ff()[32] //еще публ.вирт функция со смещением
M>}

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

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

Если делать с нуля надо делать нормальные модули, ну и по желанию необязательные генерируемые хидеры, в том же D так и сделано.

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

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

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

merk пишет:

> S>Не надо ничего в куче размещать, функцию alloca никто пока не отменял.
> не настолько знаю С++ чтобы автоматически распознать, где обьявляется
> переменная данного класса.

Мы говорим о переделанном компиляторе или о чем?

> если она обьявляется глобально — скрытую часть нужно помещать в кучу.
> если локально — можно на стеке
> если делается по new — опять в куче.

Типа того.

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

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

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

Допустим (хотя насколько я помню, в том же VC спецификаторы доступа
включаются в декорацию имени. Так что скорее всего будет ошибка
линковки.) Но все равно — считаем, что так сделать можно и мы придумали
механизм для запрета. Ну и что с того — делаешь пару reinterpret_cast,
правишь в памяти что надо. Защита от "террориста" в С++ невозможна в
принципе.

>> > также будет невозможно писать реализации отдельных методов класса прямо
>> > в хидере, поскольку в нем приватных полей нет.
>
> S>Для приватных-скрытых можно ввести отдельную декларацию, типа
> S>
>
> private extern:
>
>
>
> private extern — что? нужно сделать так чтобы там не было никаких имен.

да, лучше private extern:...; — шоб было понятно, что в данном классе
есть еще какие-то скрытые потроха. А обычные private, естественно,
остаются по старому.

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

Зачем.

>
> в принципе, если б делать язык с нуля, нужно ввести модули и генерацию
> "хидера" из текста модуля. то есть интерфейс составляется автоматически
> компилятором и не пишется руками вообще.
> тогда сокрытие, по простому выражалось бы так
> в сгенерированном интерфейсе модуля стояло бы, ну например
> class A
> {
> hidden[60]; //60 hidden bytes
> int a; //public
> int b; //public
> virtual f(int fx)[20] //это обьявление публичной вирт функции и
> обьявление ее смещения в вирт таблице
> virtual ff()[32] //еще публ.вирт функция со смещением
> }
>
> по такому описанию компилятор извне работал бы спокойно и размер типа
> известен и смещения виртметодов.

Язык "с нуля" меня не интересует, их и так полно, на любой вкус почти.

Да нет никакой проблемы.
Вот смотри, если каждый класс, кроме своих методов будет экспортировать несколько констант (например размер, выравнивание и объём виртуальной таблицы). А на каждую публикуемую виртуальную функцию будет экспортировтаься константа, которая обозначает позицию её дискриптора в таблице виртуальных функций, то дальше весь код можно дотачивать на этапе линковки/загрузки. Как пожелаешь.

Например, чтобы такой, не совсем доступный на этапе линковки класс (скажем класс из DLL) использовать, то при создании объекта класса, надо будет вычислить объём его хранилища. Это вычисление можно делать на момент загрузки DLL, например. То есть в загрузчике.

Ну будет в таких классах в некоторых редких случаях лишний уровень косвенности, ну и что?

Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>Здравствуйте, merk, Вы писали:

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

ЮЖ>Т.е. мало того что клиенты зависят от "хидера", так они еще от реализации будут зависеть(в плане необходимости перекомпиляции, ведь интерфес фактически будет изменяться при каждом изменении реализации) ??
ЮЖ>Хотя некоторое рациональное зерно в этом есть, но имхо, "стандартные" интерфейсы в этом плане лучше...

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

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

G_K>Не понял вашу мысль Я вам указал на то, что переплевывание в метапрограммировании при большем количестве писанины выглядит несколько ... смешно

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

G_K>Как впрочем и кроссплатформенные ассемблеры.

Например, C?

G_K>Последняя Ваша фраза просто не дошла до сознания. Видимо слишком глубока

Возьмём сферическую программу на C++. Исходники можно разделить на 2 части: определение (шаблонных) классов и бизнес-логика. Второе использует "готовые" классы — это клиентский код, чем мощнее первая часть, тем он меньше (и проще). Но первую часть кто-то должен написать. Простейший helloworld в 2 строки требует несколько мегабайт библиотечного кода.

Здравствуйте, <Аноним>, Вы писали:
А>Наглядность + не нужно возни с шаблонными параметрами как сейчас

А>

А>class A
А>{
А>private:
А>   long value;
А>public:
А>   A():value(0);
А>   void MyFunction1(long pValue){ value = pValue; };
А>   void MyFunction2(long pValue){ value -= pValue; };
А>   virtual ~A();
А>};

А>A* _a = new A();
А>public delegate void MyDelegate(long pValue);
А>MyDelegate* _delegate_ptr = 0;
А>_delegate_ptr = new MyDelegate(_a, A::&MyFunction1); 
А>*_delegate_ptr(100);
А>_delegate_ptr += new MyDelegate(_a, A::&MyFunction2);
А>*_delegate_ptr(1);
А>_delegate_ptr -= new MyDelegate(_a, A::&MyFunction1); 
А>*_delegate_ptr(10);
А>_delegate_ptr->Invoke(10);
А>delete _a;
А>

Ужос!

1. Несоответствие объявления объекта MyDelegate как указателя и работы с ним как с объектом (операторы += и -= для указателей делают совсем другое).
   
2. Неявная работа "делегата" с кучей.
   
3. Требование обязательного расположения объекта и делегатов в куче.
   
4. Неявная зависимость "делегата" от времени жизни объектов чьи функции дёргаются.
   
5. Неявное навязывание контейнера для реализации "делегата".

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

А если уж и включать в язык, то именно замыкание метода на объект, как сделпно у багланда (__closure) и gcc (extern), а уж контейнер на это и руками весело прикручивается (были бы определены операторы =, == и <) да шаблоны с произвольным числом параметров.
Т.е. в С++0х вполне реализуемо.

Здравствуйте, Erop, Вы писали:
А>>Как вы себе представляете прикручивание библиотеки скомпиленной под IA64 в проект для arm'а какого нить?
E>А собранную gcc к собранному VC предатсаляешь?
Вполне. Pure C или аля-COM и с песней.

Здравствуйте, Sergey, Вы писали:
S>Поэтому надо работать не (или не только) с хедерами/pch, а с уже
S>откомпилированными функциями. Только пихать их, грубо говоря, в один на
S>программу большой объектник. Заодно получаем в качестве бонуса
S>диагностику нарушений ODR.
А это уже входит в противоречие с предкомпилированныим библиотеками.
Даже если отвлечся от того, что объектники могут получатся из исходников на других языках.

Здравствуйте, alzt, Вы писали:
A>Немного отклонюсь от темы, и приведу то, что немного мешает:
A>1. Отсутствие стандартного типа строки. Я знаю про stl, но практически каждая крупная библиотека имеет свой тип строки, который лучше использовать при её использовании (большинство функций используют либо строки своего формата, либо Си-шные строки). Т.е. std::string стандартная только на бумаге.
Лучше работать всегда с одним типом строки не зависимо то фрэймворка.
std::string — довольно хороший выбор, хотя могут быть и варианты.

A>2. Работа с памятью. Создание\Удаление небольших объектов в С++ неэффективно. При этом можно сделать настроить операторы new\delete для своих нужд. Но сделать это достаточно сложно, есть множество ограничений, в итоге — чтобы включить какую-то свою стратегию — нужно переписать множества кода.
Множество маленьких объектов лучше сразу держать в массиве. Например в std::vector. Тогда проблем с постоянным созданием/удалением не будет.

Здравствуйте, Roman Odaisky, Вы писали:
RO>Как можно оставить возможность создания объектов на стеке и избежать перекомпиляции при изменении внутренней структуры объектов?
RO>Или, например, есть вызов std::sort с неким предикатом. Вызов предиката инлайнится. И сама std::sort (частично) инлайнится. Если кто-то меняет предикат, то как можно обойтись без перекомпиляции?
Вполне представимо: при компиляции определения шаблона/инлайна нужно сохранять некоторое представление АСД + требования на внешние сущности, при соблюдении которых сгенерённое представление остаётся корректным.
А при компиляции использования сначало проверяется корректность, а потом подставляется само тело.

Мне кажется, вполне реально сделать такое с современными компиляторами. Причём, если эти отрывки индексировать, то компиляция может существенно ускорится.
А если собирать это в библиотеки получатся export template.

Здравствуйте, remark, Вы писали:
R>Что Вам мешает в С++?
1) Отсутствие лямбд, замыканий, частичных применений — без этого не удобно использовать стандартные алгоритмы.
Есть в Haskell, Python, C# и многих других. Эмулируется функторами

2) Отсутствие автоматического вывода типов — приходится явно выписывать типы промежуточных и временных переменных — например тип итератора часто не интересен.
Есть в Haskell. Эмулируется шаблонами.

3) Ограничения на неклассовые типы шаблонных параметров — нельзя инстанцировать шаблон массивом, сторкой, float-ом, пользовательским типом.
Из за этого приходится выносить во время выполнение код, который вполне возможно выполнить во время компиляции (например построение конечного автомата по регулярному выражению).

4) Недостаток CTTI — хотелось бы уметь для произвольного типа получать список данных/функций/базовых классов и как-то с ним манипулировать.
На этой основе пишется любая кастомная RTTI, сериализация и т.п. Эмулируется макросами.

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

NBN>Чем не устраивает вижалка?

Дорогая... Express для win32-разработки как-то не особо приспособлен.

Не знаю как последние версии, а в 7.1 далеко не всегда stl контейнеры можно в дебаге посмотреть.

В последних версиях убрали поддержку win9x, т.е. писать программы, которые будут в win9x работать — нельзя. ИМХО рано еще.

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

T>Вполне. Pure C или аля-COM и с песней.
А если я таки хочу С++ интерфейс + исключения, напрмиер?

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

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

Единственный известный мне понт в метапрограммировании — уменьшение ручной работы (и тем самым уменьшение количества ошибок)
Если Вам исзвестен еще какой-то, не жадничайте, делитесь

G_K>>Как впрочем и кроссплатформенные ассемблеры.
GN>Например, C?

Приведите пожалуйста (серьезный) источник, в котором C упоминается в качестве ассемблера

GN>Возьмём сферическую программу на C++. Исходники можно разделить на 2 части: определение (шаблонных) классов и бизнес-логика. Второе использует "готовые" классы — это клиентский код, чем мощнее первая часть, тем он меньше (и проще). Но первую часть кто-то должен написать. Простейший helloworld в 2 строки требует несколько мегабайт библиотечного кода.

Понятно
К сожалению я не занимаюсь сферическими хеллоуворлдами

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

R>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.

R>Что Вам мешает в С++?

1. Отсутствие стандартных кросс — платформенных библиотек.
2. Отсутствие относительно простых стандартных решений с простой семантикой, типа списков типов, например. Или деревьев.
3. Часто приходится слишком много усилий затрачивать на синтаксис (например в бусте семантика часто странно выглядит), вместо того, чтобы думать о дизайне/алгоритмах.

Здравствуйте, Аноним, Вы писали:

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

R>>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.

R>>Что Вам мешает в С++?

А>1. Отсутствие стандартных кросс — платформенных библиотек.
А>2. Отсутствие относительно простых стандартных решений с простой семантикой, типа списков типов, например. Или деревьев.
А>3. Часто приходится слишком много усилий затрачивать на синтаксис (например в бусте семантика часто странно выглядит), вместо того, чтобы думать о дизайне/алгоритмах.

В общем, если кратко, то это слишком уж разнообразная семантика и отсутствие должной стандартизации. (С) Или это уже где то было?

Вольности в объявелнии шаблонов.

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


concept class comparable
{
bool operator < (...);
};


template<comparable t>
bool less(comparable t1, comparable t2)
{
return t1 < t2;
}


class myClass{
....
};

less(myClass(), myClass());

comlile error: class myClass not satisfy comparable conсept cause:
bool operator < not defined

А>Delete == C# Dispose, можна удалить сразу или поставить в очередь на удаление в зависимости от состояния сборщика в текущий момент.
Мы, С++сники привыкли, что delete это всегда удаление, а иначе неудобно