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

V>>...навороченное может получиться объявление, но тут и макросами разбавить не грех.
U>Макросы сами по себе грех. Хуже этого только ms specific

макросы довольно мощная и полезная вещь, просто нужно ими пользоваться с умом.
чего только один boost::preprocessor стоит

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

Y>макросы довольно мощная и полезная вещь, просто нужно ими пользоваться с умом.
Y>чего только один boost::preprocessor стоит

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

это, знаете, как в том анекдоте — "осадок остался"

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

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

Y>>макросы довольно мощная и полезная вещь, просто нужно ими пользоваться с умом.
Y>>чего только один boost::preprocessor стоит

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

U>1) Страуструп, куда же без него

Problem #3
"I'd like to see Cpp abolished." — Bjarne Stroustrup.
Solution
The C/C++ preprocessor will be here for a long time.
In practice, preprocessor metaprogramming is far simpler and more portable than template metaprogramming [Czarnecki].

U>2) как-то раз обнаружил, что не могу определить метод с названием max в своем классе. был в шоке.

это аргумент против VC6 а не против макросов и это просто говорит о том, что Microsoft не умее т пользоваться макросами

U>это, знаете, как в том анекдоте — "осадок остался"

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

U>>это, знаете, как в том анекдоте — "осадок остался"

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

Сишный препроцессор — очень убогий по сравнению с макро-ассемблерным. Керниган и Ричи просто схалтурили в этом месте.

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

U>2) как-то раз обнаружил, что не могу определить метод с названием max в своем классе. был в шоке.

Экие мы нежные...
Так же не рекомендуется использовать "and", "or", "not" и другие ключевые слова...

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

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

U>>2) как-то раз обнаружил, что не могу определить метод с названием max в своем классе. был в шоке.

MS>Экие мы нежные...
MS>Так же не рекомендуется использовать "and", "or", "not" и другие ключевые слова...

а с каких пор max ключевое слово?

Я не говорю, что препроцессор лишен достоинств.
Просто меня его недостатки убивают.
Чую зафлеймим

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

MS>>Экие мы нежные...
MS>>Так же не рекомендуется использовать "and", "or", "not" и другие ключевые слова...

U>а с каких пор max ключевое слово?

Это была провокация
В каком месте я утверждаю, что max — это ключевое слово?

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

U>>>это, знаете, как в том анекдоте — "осадок остался"

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

MS>Сишный препроцессор — очень убогий по сравнению с макро-ассемблерным. Керниган и Ричи просто схалтурили в этом месте.

ничего страшного, contributor'ы boost неплохо поработали, чтобы наверстать упущенное этими двумя халтурщиками

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

U>Я не говорю, что препроцессор лишен достоинств.
U>Просто меня его недостатки убивают.
U>Чую зафлеймим

судя по твоему нику, препроцессор уже давно тебя убил

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

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

MS>>>Экие мы нежные...
MS>>>Так же не рекомендуется использовать "and", "or", "not" и другие ключевые слова...

U>>а с каких пор max ключевое слово?

MS>Это была провокация
MS>В каком месте я утверждаю, что max — это ключевое слово?

я подумал об этом прежде чем написать, но все равно захотелось

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

U>>>это, знаете, как в том анекдоте — "осадок остался"

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

MS>Сишный препроцессор — очень убогий по сравнению с макро-ассемблерным. Керниган и Ричи просто схалтурили в этом месте.

есть немного... если речь о вложенности объявлений,
однако шаблоны в С++ в нынешнем виде "немного" смягчают ситуацию, не так ли?

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

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

V>есть немного... если речь о вложенности объявлений,
V>однако шаблоны в С++ в нынешнем виде "немного" смягчают ситуацию, не так ли?

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

Есть вещи, которые не реализовать ни препроцессром ни шаблонами. Например, аналог макроассемблерного REP с константным аргументом.

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

MS>Есть вещи, которые не реализовать ни препроцессром ни шаблонами. Например, аналог макроассемблерного REP с константным аргументом.

А что он делает?

http://boost.org/libs/preprocessor/doc/ref/repeat.html

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

MS>Есть вещи, которые не реализовать ни препроцессром ни шаблонами. Например, аналог макроассемблерного REP с константным аргументом.

Пример в студию!

Что-то мне подсказывает, что на шаблонах это не трудно.

#include "stdafx.h"

template<int i> struct quick {
    static inline int sum(const int* arr) {
        return *arr + quick<i-1>::sum(arr+1);
    }
};

template<> int quick<1>::sum(const int* arr) {
    return *arr;
}

// защита от "дурака"
template<> int quick<0>::sum(const int* arr) {
    return 0;
}

template<int i> 
inline int sum(int (&arr)[i]) { 
    return quick<i>::sum(arr); 
}

// дабы избежать оптимизации, объявим как external
// в первой версии массив был локальным в main()
// компилятор сгенерил код, который просто послает 15 на вывод :)
extern int arr1[];
int arr1[] = { 1, 2, 3, 4, 5};

int _tmain(int argc, _TCHAR* argv[])
{
    std::cout << sum(arr1);
    return 0;
}

  mov         eax,dword ptr [arr1+8 (414068h)] 
  mov         ecx,dword ptr [arr1+4 (414064h)] 
  mov         edx,dword ptr [arr1+0Ch (41406Ch)] 
  add         ecx,eax 
  mov         eax,dword ptr [arr1+10h (414070h)] 
  add         ecx,edx 
  mov         edx,dword ptr [arr1 (414060h)] 
  add         ecx,eax 
  add         ecx,edx 
  push        ecx  
  mov         ecx,offset std::cout (415210h) 
  call        std::basic_ostream<char,std::char_traits<char> >::operator<< (401320h) 
  xor         eax,eax 
  ret

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

_W>А что он делает?

Именно то...

_W>http://boost.org/libs/preprocessor/doc/ref/repeat.html

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

int array[5];
BOOST_PP_REPEAT(sizeof(array)/sizeof(array[0]), DECL, x)

Такое сработает?

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

V>Что-то мне подсказывает, что на шаблонах это не трудно.

V>

V> . . .
V>

Все это хорошо, но мы не имеем права полагаться на оптимизатор до такой степени. Потому что оптимизатор ничего не гарантирует, он только "обещает попробовать" и имеет полное право "забить".
Ркжим с выключенной оптимизацией тоже может быть важен при отладке. И если скорость в release и debug конфигурации отличается в 100 раз, то на определенных задачах отладочный режим становится практически бесполезным.

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

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

_W>>А что он делает?

MS>Именно то...

_W>>http://boost.org/libs/preprocessor/doc/ref/repeat.html

MS>Ну это хоть что-то, из разряда "сойдет для сельской местности", хотя конструкукция громоздкая, весьма ограниченная и неудобная в использовании.

MS>

MS>int array[5];
MS>BOOST_PP_REPEAT(sizeof(array)/sizeof(array[0]), DECL, x)
MS>

MS>Такое сработает?

такое не сработает, сам знаешь почему.

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


MS>Все это хорошо, но мы не имеем права полагаться на оптимизатор до такой степени. Потому что оптимизатор ничего не гарантирует, он только "обещает попробовать" и имеет полное право "забить".
MS>Ркжим с выключенной оптимизацией тоже может быть важен при отладке. И если скорость в release и debug конфигурации отличается в 100 раз, то на определенных задачах отладочный режим становится практически бесполезным.

Хе, а как я по-твоему получил этот листинг.
Включил полную оптимизацию, НО оставил отладочную информацию (дабы брейкпоинт сработал).

А Debug или там какой Release — не более чем символьные идентификаторы конфигураций проекта.

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

V>Хе, а как я по-твоему получил этот листинг.
V>Включил полную оптимизацию, НО оставил отладочную информацию (дабы брейкпоинт сработал).

V>А Debug или там какой Release — не более чем символьные идентификаторы конфигураций проекта.

Нет, это еще assert'ы и прочая лабуда. К тому же, трассировать код с включенной оптимизаций — это убиться веником.
Еще раз: Полагаться на оптимизатор нельзя, так же как нельзя полагаться на то что inline будет inlin'ом. Имеет право не быть. И вообще, если наблюдается разница в производительности более 10 раз, с оптимизацией и без, то это плохой признак. Не должно быть такого. Ну в 2 раза, ну в 3. Но в 10 раз — это перебор.