Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Глупости какие. Твоё утверждение опровергается простейшим примером — в ST есть метасистема, но нет сопоставлений с образцом.

Метасистема есть даже в C#. С помощью эмита, bltoolkit'а и такой-то матери я могу делать практически всё. Вопрос лишь в трудозатратах и пределеах возможностей. Про метасистему ST с удовольствием бы чего-нибудь почитал научно популярного, чтобы оценить простоту и мощь.

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

IT>Здравствуйте, lomeo, Вы писали:
L>>А как же LISP?
IT>А как там?

Там все как всегда — только s-выражения. Но, поскольку они просты по своей структуре, нужда в паттерн матчинге не столь очевидна.

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

L>>А как же LISP?

IT>А как там?

Ну, в основном, без паттерн матчинга.

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

Q>Там все как всегда — только s-выражения. Но, поскольку они просты по своей структуре, нужда в паттерн матчинге не столь очевидна.

А когда она очевидна? По моему, всё таки паттерн-матчинг не настолько важная вещь как её разрисовавыют на рсдн. Я вот списки в Хаскеле использую часто, а паттерн матчинг над ними нет, т.к. стандартные функции над списком представляют гораздо более мощный интерфейс.

L>А когда она очевидна? По моему, всё таки паттерн-матчинг не настолько важная вещь как её разрисовавыют на рсдн. Я вот списки в Хаскеле использую часто, а паттерн матчинг над ними нет, т.к. стандартные функции над списком представляют гораздо более мощный интерфейс.

имхо Влад как обычно превозносит до небес то, чем Немерле отличается от явы/с#. был бы там playching shatterle — он бы и в нм души не чаял

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

L>А когда она очевидна? По моему, всё таки паттерн-матчинг не настолько важная вещь как её разрисовавыют на рсдн. Я вот списки в Хаскеле использую часто, а паттерн матчинг над ними нет, т.к. стандартные функции над списком представляют гораздо более мощный интерфейс.

Паттерн-матчинг нужен всегда, когда надо извлекать значения из сложных структур данных (более сложных чем int). Хотя бы с той точки зрения, что не надо писать горы if'ов. В том же Лиспе постоянно можно видеть ступенчатые проверки типов и извлечения значений:

(if (my-super-struct? p) (my-super-f (my-super-struct->mega-field p))
   (if (my-super-struct2? p) ....))

Но в Лиспе эта проблема не столь значительна, поскольку нет мощных конструкторов данных.

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

BZ>имхо Влад как обычно превозносит до небес то, чем Немерле отличается от явы/с#.

Да если бы только Влад. Я как то тоже самое сказал, так мне кучу минусов понаставили. Ну, нравится людям паттерн-матчинг, а я говорю, что есть вещи вкуснее, конечно, кому понравится?

BZ>был бы там playching shatterle — он бы и в нм души не чаял

Ой, блин, а это что за штука? что то французское?

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

[]

BZ>я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет

что-что, простите? Вы не опечатались? Так вот почему вы его не любите!

Если серьезно, то придумать писать трэдсейфные конструкторы копирования — это че надо курить или пить или колоть? Я в ауте...

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

Q>Паттерн-матчинг нужен всегда, когда надо извлекать значения из сложных структур данных (более сложных чем int).

Я постараюсь описать своё имхо. Я согласен с тем, что после описания нашего типа данных (например какого нибудь Map), нам нужно описать его интерфейс в виде функций put/get и т.д. Все они гораздо проще записываются с помощью паттерн матчинга, да. После чего потроха этой структуры можно закрыть — в дальнейшей работе функций, и особенно функций высшего порядка, работающих над этим типом более чем достаточно.

Т.е. если мы работаем с чьим-то типом данных, обычно (часто!) паттерн-матчинг по этой структуре не нужен. Для своего типа данных — да, обычно нужен.

Извлечение же значений имеет какую то цель, которую часто можно достичь другими средствами. Пример — какой нибудь перебор, трансформация, изменение одного значения.

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

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

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

КЛ>[]

BZ>>я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет

КЛ>что-что, простите? Вы не опечатались? Так вот почему вы его не любите!

КЛ>Если серьезно, то придумать писать трэдсейфные конструкторы копирования — это че надо курить или пить или колоть? Я в ауте...

читай http://rsdn.ru/Forum/Message.aspx?mid=2315912&only=1

Автор: Anatolix
Дата: 24.01.07

я в терминах ошибся поскольку эта область от меня далека. суть дела в том, что даже конструктор значений становится такой штукой, которую без хороших знаний языка не напишешь. для того, чтобы понять, насколько это смешноЮ надо прсто знать один из языков в algebraic data types

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

BZ>>я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет

КЛ>что-что, простите? Вы не опечатались? Так вот почему вы его не любите!
А что тебя так удивляет?
Возьмем например всеми любимый boost::intrusive_ptr

    intrusive_ptr(intrusive_ptr const & rhs): p_(rhs.p_)
    {
            //!!!
        if(p_ != 0) intrusive_ptr_add_ref(p_);
    }

    intrusive_ptr & operator=(intrusive_ptr const & rhs)
    {
        this_type(rhs).swap(*this);
        return *this;
    }

его конструктор компирования не является потокобезопасным.
Удивлен?
Объясняю:
Если в точке !!! произойдет переключения потока и в это время в другом потоке случится присваивание объекту на который ссылается rhs и этот объект держал последнею ссылку то когда поток переключится обратно в p_ окажется указатель на удаленный объект.
Все! Приехали.

У меня одно такое место есть. Поставил там mutex.

КЛ>Если серьезно, то придумать писать трэдсейфные конструкторы копирования — это че надо курить или пить или колоть? Я в ауте...
Оно и видно.

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

BZ>Здравствуйте, Константин Л., Вы писали:

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

КЛ>>[]

BZ>>>я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет

КЛ>>что-что, простите? Вы не опечатались? Так вот почему вы его не любите!

КЛ>>Если серьезно, то придумать писать трэдсейфные конструкторы копирования — это че надо курить или пить или колоть? Я в ауте...

BZ>читай http://rsdn.ru/Forum/Message.aspx?mid=2315912&only=1

Автор: Anatolix
Дата: 24.01.07

BZ>я в терминах ошибся поскольку эта область от меня далека. суть дела в том, что даже конструктор значений становится такой штукой, которую без хороших знаний языка не напишешь. для того, чтобы понять, насколько это смешноЮ надо прсто знать один из языков в algebraic data types

Да ты не в терминах ошибся. Ты ошибся тогда, когда принял решение написать о языке, которого, судя по всему, совсем не знаешь. И опять говоришь лабуду (выд.). Прости, конечно, но не пора ли говорить о тех областях, которые для тебя близки? Я уверен на 100%, что никто из знающих с++ людей не пишут потокобезопасные конструкторы копирования. "потокобезопасный конструктор копирования" как должен отсутствовать как термин. Я надеюсь, с++-ники меня поняли.

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

[]

WH>его конструктор компирования не является потокобезопасным.

WH>Удивлен?

представь себе, нет.

WH>Объясняю:

ты тут всех за идиотов держишь?

[]

WH>Все! Приехали.

Приехал ты, тк ты используешь его НЕПРАВИЛЬНО. Как правильно — объяснять не буду.

WH>У меня одно такое место есть. Поставил там mutex.

КЛ>>Если серьезно, то придумать писать трэдсейфные конструкторы копирования — это че надо курить или пить или колоть? Я в ауте...
WH>Оно и видно.

ну-ну

WolfHound wrote:
> Если в точке !!! произойдет переключения потока и в это время в другом
> потоке случится присваивание объекту на который ссылается rhs и этот
> объект держал последнею ссылку то когда поток переключится обратно в p_
> окажется указатель на удаленный объект.
> Все! Приехали.
Пример плохой. У нас тут самый обычный race condition —
несинхронизированая работа с объектом. То что при этом у нас получится
premature deletion — это уже просто детали.

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

КЛ>Приехал ты, тк ты используешь его НЕПРАВИЛЬНО. Как правильно — объяснять не буду.
О великий гуру! Свет всего сущего! Снизойди до убогого! Просвети меня не разумного! Как решить призренную задачку недостойную внимания такого великого программиста как ты!

Призренная задачка: Нужно расшарить неизменяемый объект (карта кластера) между потоками (Потоков много. Машина 4х процессорная.). Причем этот объект иногда обновляется (модифицировать по месту нельзя ибо будет нарушена целостность транзакции да и всеравно придется все внутренности объекта синхронизировать короче проблем будет очень много). При старте транзакции его нужно каждый раз перезапрашивать из централизованного хранилища. Просто удалить объект нельзя ибо его еще могут использовать запросившие рание потоки.

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

WH>Здравствуйте, Константин Л., Вы писали:

КЛ>>Приехал ты, тк ты используешь его НЕПРАВИЛЬНО. Как правильно — объяснять не буду.
WH>О великий гуру! Свет всего сущего! Снизойди до убогого! Просвети меня не разумного! Как решить призренную задачку недостойную внимания такого великого программиста как ты!

WH>Призренная задачка: Нужно расшарить неизменяемый объект (карта кластера) между потоками (Потоков много. Машина 4х процессорная.). Причем этот объект иногда обновляется (модифицировать по месту нельзя ибо будет нарушена целостность транзакции да и всеравно придется все внутренности объекта синхронизировать короче проблем будет очень много). При старте транзакции его нужно каждый раз перезапрашивать из централизованного хранилища. Просто удалить объект нельзя ибо его еще могут использовать запросившие рание потоки.

процессоры продать. деньгит пропить. буьтылки сдать. на вырученные деньги купить любую толковую книжку по потокам и не морочить голову великому гуру

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

C>Пример плохой. У нас тут самый обычный race condition — несинхронизированая работа с объектом. То что при этом у нас получится premature deletion — это уже просто детали.
Тем не мение тут нужен либо внешний mutex либо конструктор копирования и оператор присваивания написанные в расчете на работу в разных потоках.
В системах с GC (если не вспоминать про того жутика у которого запись/чтение указателей не атомарно) такой проблемы нет.

А вобще в данном случае я наверное утечку памяти сделаю. Всеравно конфигурация кластера меняется реже чем обновляется ПО. Да и информация эта занимает всего несколько килобайт памяти.

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

BZ>процессоры продать. деньгит пропить. буьтылки сдать. на вырученные деньги купить любую толковую книжку по потокам и не морочить голову великому гуру
А если серьезно есть ли варианты кроме того чтобы общию ссылку лочить?

WH>А если серьезно есть ли варианты кроме того чтобы общию ссылку лочить?

использовать сообщения и отдельный тред который из обрабатывает?

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

WH>Здравствуйте, Константин Л., Вы писали:

КЛ>>Приехал ты, тк ты используешь его НЕПРАВИЛЬНО. Как правильно — объяснять не буду.
WH>О великий гуру! Свет всего сущего! Снизойди до убогого! Просвети меня не разумного! Как решить призренную задачку недостойную внимания такого великого программиста как ты!

да ладно тебе. Просто зачем ждать от класса того, для чего он не предназначен? Извини, если до этого ответил заносчиво, но и ты не был мил

WH>Призренная задачка: Нужно расшарить неизменяемый объект (карта кластера) между потоками (Потоков много. Машина 4х процессорная.). Причем этот объект иногда обновляется (модифицировать по месту нельзя ибо будет нарушена целостность транзакции да и всеравно придется все внутренности объекта синхронизировать короче проблем будет очень много). При старте транзакции его нужно каждый раз перезапрашивать из централизованного хранилища. Просто удалить объект нельзя ибо его еще могут использовать запросившие рание потоки.

просто есть типы (читай классы), которые не нуждаются во внутренней потокобезопасности (т.е. написании тех самых thread-safe copy ctors), а должны лочиться снаружи. И то, что ты поставил мьютекс снаружи, есть правильно.

В твоей задачке недостаточно данных для меня.

Я вместо написания этих thread-safe copy ctors использую часто такой хэлпер:

template <typename T>
    class LockedObject
    {
        typedef ATL::CComAutoCriticalSection    Mutex;
        typedef ATL::CComCritSecLock<Mutex>        Lock;

        mutable Mutex    mutex_;
        T                object_;

        template <typename T> friend class LockedObject;        

    public:

        LockedObject()
            : object_()
        {}

        explicit LockedObject( const T& object )
            : object_(object)
        {}

        LockedObject( const LockedObject& other )
            : object_(other.GetValue())
        {}

        LockedObject& operator =(  const LockedObject& other )
        {
            SetValue(other.GetValue());
        }

        template <typename U>
        explicit LockedObject& operator =(  const U& other )
        {
            SetValue(other);
            return *this;
        }

        template <typename U>
        explicit LockedObject( const LockedObject<U>& other )
            : object_(other.GetValue())
        {}

        template <typename U>
        LockedObject& operator =(  const LockedObject<U>& other )
        {
            SetValue(other.GetValue());
        }

        T GetValue() const
        {
            Lock lock(mutex_);
            return object_;
        }

        void SetValue( const T& object )
        {
            Lock lock(mutex_);
            object_ = object;
        }

        operator T() const
        {
            Lock lock(mutex_);
            return object_;
        }
    };