template< typename T >
struct can_be_on_stack
: mpl::bool_c< (sizeof(T) <= sizeof(double)) >
{
};
// use 'if_' to choose where to store 'T' membertemplate< typename T >
struct lightweight
: private mpl::if_<
can_be_on_stack<T>
, stack_holder<T>
, heap_holder<T>
>::type
{
// ...
};
На мой взгляд такие "syntax mixin" еще хуже чем старые добрые #define
В качестве альернативы я бы предложил ввести в язык нечто типа
типизированных meta функций, например приведенный пример можно записать так:
meta
bool can_be_on_stack(typename T) {
return (sizeof(T) <= sizeof(double));
}
meta
typename optimal_holder(typename T)
{ return can_be_on_stack(T)? tack_holder<T>:heap_holder<T>; }
template< typename T >
struct lightweight : private optimal_holder<T>
{
};
Я не уверен в синтасической полноте / гармоничности такого рода конструкций
поэтому давайте помечтаем вместе: "как оно должно быть на самом деле?"
Как дополнить синтаксис template<> что бы получить meta if, meta switch и т.д.
Ваши предложения?
27.10.04 23:51: Перенесено модератором из 'C/C++. Прикладные вопросы' — Павел Кузнецов
Если Дэвид дополирует изложенное, и перейдет от презентации к proposal. А это, в свою очередь, зависит от того, как много времени у него на это будет...
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, Павел Кузнецов, Вы писали:
ПК>>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1471.pdf
MS>Круто! А есть шансы это все это будет рассмотрено и принято хотя бы в этом веке? "и реализовано в широкодоступном компиляторе?" -- захотелось мне добавить...
Здравствуйте, Павел Кузнецов, Вы писали:
>> Круто! А есть шансы это все это будет рассмотрено и принято хотя бы в этом веке?
ПК>Если Дэвид дополирует изложенное, и перейдет от презентации к proposal. А это, в свою очередь, зависит от того, как много времени у него на это будет...
Ну если сказал "А", так надо говорить и "Б". Насколько я понимаю, его презентация народу понравилась? А раз так, то если не сам Дэвид, то кто-нибудь другой мог бы помочь и "по-пинговать" комитет. Павел Кузнецов, например
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Спасибо за ссылку, Павел.
Я попал с точностью до имен сущностей.
Радостно сознавать что нас мало но мы есть
Мысль/рассуждение/вопрос хорошо ли совмещать и в метаязыке
и в самом языке одни и те же синтаксические конструкции?
Я имею ввиду то что уж сильно близко выделенноое к
синтаксису самого C.
template<typename T> metacode
T power(T b, unsigned n) {
T r = 1;
for (int k = 0; k<n; ++k) r *= b;
return r;
}
float a1[power(2, 3)]; // OK: Same as a1[8]
Мне почему-то кажется что метаконструкции должны быть расчитаны на
intellisense и раскраску кода. Либо сама нотация должна быть такова
чтобы легко отличалась на глаз человеком. "Не человек для субботы,
а суббота для человека" как справедливо считают в одной восточной стране.
Авторы нотации #define,#endif, etc. думаю имели ввиду этот аспект в том числе.
Я фантазирую:
meta
typename $power(b, unsigned n)
{
$typeof(b) r = 1;
for (int k = 0; k<n; ++k) r *= b;
return r;
}
float a1[$power(2, 3)]; // OK: Same as a1[8][/b]
McSeem2:
> Ну если сказал "А", так надо говорить и "Б". Насколько я понимаю, его презентация народу понравилась? А раз так, то если не сам Дэвид, то кто-нибудь другой мог бы помочь и "по-пинговать" комитет.
Дело не в "пинговании". Дело в проработке спецификации и обкатке этого дела на одном из компиляторов. Будучи одним из давних членов комитета и разработчиком EDG, Дэвид имеет для этого наиболее подходяющую квалификацию Однако, судя по давно застывшим "новостям" на его сайте http://vandevoorde.com/Daveed/News/, со временем у него не ахти...
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
c-smile:
> Спасибо за ссылку, Павел. > Я попал с точностью до имен сущностей. > Радостно сознавать что нас мало но мы есть > > Мысль/рассуждение/вопрос хорошо ли совмещать и в метаязыке > и в самом языке одни и те же синтаксические конструкции? > Я имею ввиду то что уж сильно близко выделенноое к > синтаксису самого C. >
> template<typename T> metacode
> T power(T b, unsigned n) {
> T r = 1;
> for (int k = 0; k<n; ++k) r *= b;
> return r;
> }
> float a1[power(2, 3)]; // OK: Same as a1[8]
> > > Мне почему-то кажется что метаконструкции должны быть расчитаны на > intellisense и раскраску кода. Либо сама нотация должна быть такова > чтобы легко отличалась на глаз человеком. "Не человек для субботы, > а суббота для человека" как справедливо считают в одной восточной стране.
Послушай, что говорят в одной восточной стране, и сделай наоборот
> > Авторы нотации #define,#endif, etc. думаю имели ввиду этот аспект в том числе. > > Я фантазирую: > >
> meta
> typename $power(b, unsigned n)
> {
> $typeof(b) r = 1;
> for (int k = 0; k<n; ++k) r *= b;
> return r;
> }
> float a1[$power(2, 3)]; // OK: Same as a1[8][/b]
>
> > Может еще какие варианты будут?
У меня фантазии с точностью до наоборот. Значение функции power может понадобиться как рантайме, так и в компайлтайме (функция "чистая", ее аргументы известны на момент компиляции), и ее определение может быть одно для обоих таймов. Для этого нужно избегать всяких особостей вроде $ и @ при определении функций (по крайней мере таких как эта).
Не скажу, что все продумал, но мой поинт в том, что надо обобщать, а не разделять описания. Понятно что для этого понадобится почти полноценный интерпретатор С++ при компиляции.
F>...Значение функции power может понадобиться как рантайме, так и в компайлтайме (функция "чистая", ее аргументы известны на момент компиляции), и ее определение может быть одно для обоих таймов....
Что-то меня глажут сомнения что множество compile time множество функций преркрывается хоть как-то с runtime.
Следуя твоей логике template<> тоже нужно переводить в runtime эквивалент (generics?).
c-smile:
> F>...Значение функции power может понадобиться как рантайме, так и в компайлтайме (функция "чистая", ее аргументы известны на момент компиляции), и ее определение может быть одно для обоих таймов.... > > Что-то меня глажут сомнения что множество compile time множество функций преркрывается хоть как-то с runtime.
Например твоя же функция power и все подобные математические, строковые и т.д. чистые функции. Вообще говоря, все функции, работающие не с типами, а со значениями, не имеющие side-effects, и значение которых зависит только от переданных аргументов.
> Следуя твоей логике template<> тоже нужно переводить в runtime эквивалент (generics?).
Нет.
> Акдемически интересно — практически нет, imho.
Вот пример из практики. Тут по соседству обсуждают, является ли static CString s; потокобезопасным. Я не помню точно, как устроен CString, но если предположить что конструктор по умолчанию является чистой функцией (с возвращаемым значением CString), то этот конструктор может быть выполнен в компайлтайме — получаем статическую инициализацию и безопасность.
Собственно говоря, к метафункциям это отношения не имеет, общее лишь то, что выполнение происходит во время компиляции. Ну так и твоя power не является метафункцией (функцией над исходным кодом). Проще говоря, мне не нравится идея привносить "метасинтаксис" в не-метафункции.
Здравствуйте, folk, Вы писали:
F>У меня фантазии с точностью до наоборот. Значение функции power может понадобиться как рантайме, так и в компайлтайме (функция "чистая", ее аргументы известны на момент компиляции), и ее определение может быть одно для обоих таймов. Для этого нужно избегать всяких особостей вроде $ и @ при определении функций (по крайней мере таких как эта).
Как я смотрю идеи витают в воздухе... F>Не скажу, что все продумал, но мой поинт в том, что надо обобщать, а не разделять описания. Понятно что для этого понадобится почти полноценный интерпретатор С++ при компиляции.
ИМХО не трудно сделать даже оптимизирующий интерпритатор ибо будут использованы теже механизмы что и для обычной оптимизации. А можно и вобще до JIT'а прокачать..., а какие собственно пролемы?... за то с какой скоростью это будет работать
ЗЫ с одной стороны хочется свой язык сделать, а с другой стороны как представлю объем работы...
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, c-smile, Вы писали:
MS>>Да, кстати, символы '$' и '@' в C++ совсем не задействованы. Целых 2 ASCII-символа!
CS>В принципе некоторые злые пиявки разрешают $ в идентификаторах но речь не об этом.
Речь не компиляторах, а о спецификации языка.
CS>#define со товарищи имхо имеет одно неоспоримое достоинство: синтаксисическая, м... , CS>изолированность. CS>Т.е. при взгляде на них сразу становится понятно что это метаконструкция.
Не согласен, точнее не совсем. Это должно быть ясно не при взгляде на метаконструкцию, а на использование метаконструкции. Вот есть define-macro. Не зря принято соглашение, что в их именах должны быть прописные буквы. Для чего это надо? Именно для того, чтобы отличать макро от функции в момент использования.
То же самое с матаконструкциями:
template<typename T> T power(T b, unsigned n) // doesn't need any additional keywords
{
T r = 1;
for (int k = 0; k<n; ++k) r *= b;
return r;
}
float a1[$power(2, 3)]; // Same as a1[8], meta
. . .
double v1 = power(2.76, 3); // runtime, 2.76^3
. . .
const int v1 = 10;
const int v2 = $power(2, v2); // meta
. . .
int v1 = 10;
int v2 = $power(2, v1); // Compile error
То есть, в соответствии с концепцией "code reuse". Конечно же, на практике в большинстве случаев конструкция может быть только runtime или только метакодом. Но метаконструкции все равно надо индицировать именно в момент использования.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Может быть так? Если говорить про макропроцессор.
Его ж все равно никто не отменит.
template<typename E>
E from_string(const char* str)
{
#for each m in E.$enum_member doif( stricmp(##m.$literal, str) == 0 ) return m;
else
#endforreturn E.$enum_member[0];
}
Может просто оставить templates уак они есть,
добавить compile time reflection (E.$enum_member)
И еще раз творчески взглянуть на макро-конструкции?
Имхо, подход последовательной трансформации стандарта имеет
больше шансов быть имплементированным.