C> Странно, что линковщик. А вообще, к члену надо обратиться где-нить в конструкторе. Делаться при этом все равно ничего не будет.
К>Ага. А потом — в каждом статическом методе. Потом в каждом энуме и тайпдефе. И так далее.

Не понял. Ты о чем?

C> А вообще, к члену надо обратиться где-нить в конструкторе.
ssm>Конструкторов может быть несколько, надо в деструктор

Ну да, согласен.

N>Проверку валидности посредством синтаксиса можно делать в любой ф-ии после return, в твоем случае:

Тогда придется избавляться от warning 'unreachable code'...

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

ssm>Конструкторов может быть несколько, надо в деструктор

А если у класса был тривиальный деструктор? Тогда получим проигрыш в скорости

Большое всем спасибо!

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

~Array() { (void) sizeof(Assert<(size > 0)>); }

Естественно, это не единственной способ статической проверки.

--
Дмитрий

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

C>> Странно, что линковщик. А вообще, к члену надо обратиться где-нить в конструкторе. Делаться при этом все равно ничего не будет.
К>>Ага. А потом — в каждом статическом методе. Потом в каждом энуме и тайпдефе. И так далее.

C> Не понял. Ты о чем?

Если ты сделаешь compile-time assert (CTA) статическим членом (методом, переменной — не важно), то это не помешает клиентам обращаться к тем членам шаблона, которые от CTA не зависят.

template<bool> struct A;
template<> struct A<true> {};


template<bool b>
struct B
{
  static A<b> aaa;
  
  static void hello() { };
  
  ~B() { void* a = &aaa; }
};

main()
{
  B<false>::hello(); // без проблем.

  B<false> b; // здесь законно огребем.
}

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

N>А если у класса был тривиальный деструктор? Тогда получим проигрыш в скорости

О каком проигрыше идет речь, если проверка выполняется в compile-time?

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

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

ssm>Конструкторов может быть несколько, надо в деструктор

N>А если у класса был тривиальный деструктор? Тогда получим проигрыш в скорости

Врядли.
Xуже то, что возникают сложности с использованием SEH.
Такой код уже компилироваться не будет из-за явно объявленного деструктора.

template<int size> struct Array {
     ~Array() {}
};
// . . .
__try {
     Array<3> a;
}
__finally {
}

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

--
Дмитрий

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

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

N>>А если у класса был тривиальный деструктор? Тогда получим проигрыш в скорости

ssm>О каком проигрыше идет речь, если проверка выполняется в compile-time?

При удалении массива подобных об'ектов будет сделан цикл вызова деструкторов (которые подставятся inline и будут пустыми), и тут останется уповать только на оптимизацию, сможет ли она убрать цикл без побочных эффектов. Не все компиляторы проводят такую оптимизацию
В случае тривиального деструктора такого цикла не будет вовсе

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

N>В случае тривиального деструктора такого цикла не будет вовсе

Это твое IMHO?

Здравствуйте, Дмитро, Вы писали:
Loki рулит
Ипользовать так

template<int size>
class Array
{
    STATIC_CHECK(size>0, invalide_size);
};

////////////////////////////////////////////////////////////////////////////////
// The Loki Library
// Copyright (c) 2001 by Andrei Alexandrescu
// This code accompanies the book:
// Alexandrescu, Andrei. "Modern C++ Design: Generic Programming and Design 
//     Patterns Applied". Copyright (c) 2001. Addison-Wesley.
// Permission to use, copy, modify, distribute and sell this software for any 
//     purpose is hereby granted without fee, provided that the above copyright 
//     notice appear in all copies and that both that copyright notice and this 
//     permission notice appear in supporting documentation.
// The author or Addison-Welsey Longman make no representations about the 
//     suitability of this software for any purpose. It is provided "as is" 
//     without express or implied warranty.
////////////////////////////////////////////////////////////////////////////////

// Last update: June 20, 2001

#ifndef STATIC_CHECK_INC_
#define STATIC_CHECK_INC_

namespace Loki
{
////////////////////////////////////////////////////////////////////////////////
// Helper structure for the STATIC_CHECK macro
////////////////////////////////////////////////////////////////////////////////

    template<bool CompileTimeAssertion>
    struct CompileTimeError;

    template<> 
    struct CompileTimeError<true> 
    {
        typedef void type;
    };
}

////////////////////////////////////////////////////////////////////////////////
// macro STATIC_CHECK
// Invocation: STATIC_CHECK(expr, id)
// where:
// expr is a compile-time integral or pointer expression
// id is a C++ identifier that does not need to be defined
// If expr is zero, id will appear in a compile-time error message.
////////////////////////////////////////////////////////////////////////////////

#define STATIC_CHECK(expr, msg) \
typedef char ERROR_##msg[1][(expr)]

////////////////////////////////////////////////////////////////////////////////
// Change log:
// March 20, 2001: add extra parens to STATIC_CHECK - it looked like a fun 
//     definition
// June 20, 2001: ported by Nick Thurn to gcc 2.95.3. Kudos, Nick!!!
// July 09, 2002: improved for favor of VC diagnostic and usage 
////////////////////////////////////////////////////////////////////////////////

#endif // STATIC_CHECK_INC_

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

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

N>>В случае тривиального деструктора такого цикла не будет вовсе

ssm>Это твое IMHO?

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

C> Не понял. Ты о чем?
К>Если ты сделаешь compile-time assert (CTA) статическим членом (методом, переменной — не важно), то это не помешает клиентам обращаться к тем членам шаблона, которые от CTA не зависят.

Не, ну эт-то ясно. Но чаще всего статический метод либо имеет дело с экземплярами класса, либо экземпляры класса вообще нигде не создаются, либо где-то рядом есть вызов нормальных методов. А если ничего из этого не верно, то... как-то мне трудно такое представить для _шаблонного_ класса...:)
А в исходном письме имхо вообще просто массив хотелось сделать с размером, определяемым на этапе выполнения. Зачем там какие-то дикие статические методы?

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

C>> А зачем наследовать? Почему не объявить статический член типа Assert?

К> А зачем захламлять сегмент данных?

А его вовсе не обязательно определять, т.к. обращений к нему не будет.

Здравствуйте, Павел Кузнецов, Вы писали:

C>>> А зачем наследовать? Почему не объявить статический член типа Assert?

К>> А зачем захламлять сегмент данных?

ПК>А его вовсе не обязательно определять, т.к. обращений к нему не будет.

Не будет обращений — не будет и проверки
Или я чего-то не догоняю? (тогда примером кинься, пожалуйста).

Здравствуйте, ssm

Рано я радовался, запихивая свой Assert в деструктор. Деструктор хоть и один, но он может и не вызываться (и как следствие, не инстанцироваться). Например, если объект создался по new, а delete ему забыли сделать, либо обращение идет к статическим членам данных.

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

--
Дмитрий

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

Д>Сергей, мог бы ты дать ссылку на Саттера, который советует проверку делать в деструкторе?

Саттера(More Exceptional C++) в электронном можешь взять у Anatolixa.Смотри главу Item 4. Extensible Templates: Via Inheritance or Traits?
Если у тебя есть бумажный вариант, то читай с 51 страницы

Д>Рано я радовался, запихивая свой Assert в деструктор. Деструктор хоть и один, но он может и не вызываться (и Д>как следствие, не инстанцироваться). Например, если объект создался по new, а delete ему забыли сделать,

Ну, знаешь... "delete забыли сделать" — это тоже глюк, который надо исправлять. Правда, это уже не обнаружить
на этапе компиляции...

Д>либо обращение идет к статическим членам данных.

Насчет этого я уже говорил.

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

ПК>> А его вовсе не обязательно определять, т.к. обращений к нему не
ПК>> будет.

К> Не будет обращений — не будет и проверки

Тоже верно.

К> Или я чего-то не догоняю? (тогда примером кинься, пожалуйста).

Лучше использовать какой-нибудь typedef с массивом неправильной длины.

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

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

Да, но это уже другой глюк. А если один глюк (отсутствие вызова delete) скрывает другой (неверные парамеры шаблона), то это совсем плохо.

Д>либо обращение идет к статическим членам данных.

C> Насчет этого я уже говорил.

Я это помню.

--
Дмитрий