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

AD>А что если статические объекты в конструкторе создают потоки?

А что если за это руки оторвать?

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

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

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

ME>function static — хороший способ создания проблем в многопотоковом коде. Сегодня у тебя этот static инициализирует один поток, завтра — ?, и компилятор здесь тебе не поможет никакой диагностикой.

Интерфейс важнее реализации, IMHO.
functional static — хорошее ср-во инкапсуляции подробностей обеспечения гарантированного порядка создания объектов, в данном случае — по мере их использования друг-другом.

никто не мешает потом сделать нечто вроде:

template<typename T, T* (*unique_func)(bool) >
struct fstatic_body 
{
    static T* obj;
    static mutex mt;

    // вызываем этот метод в теле многопоточной программы
    static T* get_mt() {
        if(!obj) {
            guard lock(mt);
            if(!obj)
                obj = new T();
        }

        return obj;
    }

    // вызываем этот метод в теле конструкторов глобальных объектов
    static T* get() {
        if(!obj)
            obj = new T();

        return obj;
    }

    ~fstatic_body() { if(obj) delete obj; } // грохаем статический объект в деструкторе экземпляра :)
};

template<typename T, T* (*unique_func)(bool)> 
T* fstatic_body<T, unique_func>::obj = NULL;

template<typename T, T* (*unique_func)(bool)> 
mutex fstatic_body<T, unique_func>::mt;

struct SomeType {};

SomeType* get_some_obj(bool from_ctor = false) {
    static fstatic_body<SomeType, get_some_obj> st;
    if(from_ctor)
        return st.get();     // :)
    else
        return st.get_mt();
}

// можно макросом подсобить
#define DEF_SGTON(type, name) \
// тут переписать ф-ию get_some_obj с подстановкой type и name

Автору топика — бери как решение.

vdimas wrote:

> ME>function static — хороший способ создания проблем в многопотоковом коде. Сегодня у тебя этот static инициализирует один поток, завтра — ?, и компилятор здесь тебе не поможет никакой диагностикой.
>
> Интерфейс важнее реализации, IMHO.

Согласен, что интерфейс очень важен. Не согласен что его важность можно сравнивать с важностью реализации — на мой взгляд эти вещи несравнимы.

> functional static — хорошее ср-во инкапсуляции подробностей обеспечения гарантированного порядка создания объектов, в данном случае — по мере их использования друг-другом.

[]

У меня противоположное мнение: функции с состоянием (со static) в С и С++, на мой взглад, плохая вещь из-за проблем с multithreaded code и из-за неявной зависимости инициализации/изменения этого состояния от последовательности вызовов (пример — strtok).

--
Maxim Yegorushkin

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

>> Интерфейс важнее реализации, IMHO.

ME>Согласен, что интерфейс очень важен. Не согласен что его важность можно сравнивать с важностью реализации — на мой взгляд эти вещи несравнимы.

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

ME>У меня противоположное мнение: функции с состоянием (со static) в С и С++, на мой взглад, плохая вещь из-за проблем с multithreaded code и из-за неявной зависимости инициализации/изменения этого состояния от последовательности вызовов (пример — strtok).

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

там код, который выглядит как fuctional static, но таковым не является

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

А>Как мне добиться, чтобы во время создания объекта класса MyClass
А>(вообще говоря, в другом модуле) объект mutex уже был создан?

Может воспользоваться статическим mutex? Работает под виндой:

/// Static mutex.
template<class T>
class static_mutex
{
public:
    /// Scoped lock.
    class scoped_lock: boost::noncopyable
    {
    public:
        /// Constructor. Lock.
        scoped_lock() { while(InterlockedExchange(&X, 1)) Sleep(1); }
        /// Destructor. Unlock.
        ~scoped_lock() { InterlockedExchange(&X, 0); }    
    };
private:
    static volatile LONG X;
};

template<class T>
volatile LONG static_mutex<T>::X = 0;

Твой код будет выглядеть так:

class MyClass {
public:
  MyClass();
};

А использование так:

    {
        static_mutex<MyClass>::scoped_lock Lock;
        ...
    }

P.S. Удобно для синглтонов.

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

ME>>У меня противоположное мнение: функции с состоянием (со static) в С и С++, на мой взглад, плохая вещь из-за проблем с multithreaded code и из-за неявной зависимости инициализации/изменения этого состояния от последовательности вызовов (пример — strtok).

V>похоже, ты таже не взглянул на приведенный код... жаль, зря старался.

V>там код, который выглядит как fuctional static, но таковым не является

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

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

V>>там код, который выглядит как fuctional static, но таковым не является

ME>Не волнуйся, видел я твой код. О его применимости сказать ничего не могу — подобные синглтоны я не использую.

Да речь не о синглтонах, разумеется. Синглтон — это лишь реализация. Дело в том, что подобные ф-ии, инкапсулирующие способ создания статических объектов сами по себе выглядят как API. На этапе начальной разработки (или разработки под 1 тред) можно накидывать это тело из 2-х строчек, т.е. юзать обычный functional static. Если позже требования ужесточаются, то одно из решений я привел.