> Mystic ©   (29.08.08 14:58) [75]


> 1) Количество таких переменных плодится и размножается,
> в результате вся выгода от многопоточности теряется: потоки
> последовательно ждут когда прочитается эта переменная.

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

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


А вобще наверное возьму пример с Владимира Кладова, и переквалифицируюсь на Delphi - удобнее он просто. :)

В последнем примере, возможно, погорячился. Надо поднять Страуструпа и посмотреть, можно ли нужным образом перегрузить операцию точка. Я с этим не сталкивался, вот так сразу сказать не могу. Помнить особенности перегрузки каждого оператора это дополнительные ячейки памяти в моей голове, а они так просто не наращиваются... Но даже в этом случае данное решение не позволяет вот так сразу забыть об своих особенностях поведения данного шаблона.

Т. е. работать с этим шаблоном не напрягаясь не получится, нужно все время помнить, что к этой переменной доступ имеют несколько потоков... В случае Lock/Unlock ситуация такая же. Но в особо спорных случаях надо в уме быстренько развернуть все шаблоны и посмотреть, а прокатит? Имхо, это только дополнительный напряг.


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


Имхо, тут лучше с самого начала думать о том, как лучше всего синхронизировать доступ, как организовать вычисления. Начнем с того, что предложенная схема, имхо, проблем синхронизации почти не решает. Более ощутимый прирост даст эскалация блокировок, объединение совместно используемых переменных в одну критическую секцию и вообще минимализация вызовов EnterCriticalSection. Это уже вопросы более высокого порядка.

> В последнем примере, возможно, погорячился. Надо поднять
> Страуструпа и посмотреть, можно ли нужным образом перегрузить
> операцию точка. Я с этим не сталкивался, вот так сразу сказать
> не могу. Помнить особенности перегрузки каждого оператора
> это дополнительные ячейки памяти в моей голове, а они так
> просто не наращиваются... Но даже в этом случае данное решение
> не позволяет вот так сразу забыть об своих особенностях
> поведения данного шаблона.

Насколько я помню - точку нельзя перегружать.
За то, что разжевали - спасибо! Есть над чем подумать.

Вообще у нас этот шаблон применяется в точках, где главное, чтобы переменная не ломалась.
Тоесть два потока:
ОДин только на чтение, второй - работа с переменной полная.
Соответственно надо дать гарантию, что первый прочитает не поломанную переменную. Что приведенный шаблон вполне себе сносно реализует... А вот что-то сложнее... Хорошо что здесь привел код... НЕ напорюсь, когда усложнять будем. :)

Да, точку перегрузить нельзя. Можно перегрузить
, но эта перегрузка только вернут некий объект, для которого будет вызвано еще раз
. Поскольку возможности выполнить некоторое действия после возврата значения нет, то этот метод также неприменим. Более того, я пришел к выводу, что я абсолютно не представляю во во что развернется

> [74] @!!ex ©   (29.08.08 14:52)

в данном случае Interlocked* функции рулят, например InterlockedExchange, InterlockedIncrement и т.д.

> в данном случае Interlocked* функции рулят, например InterlockedExchange,
>  InterlockedIncrement и т.д.


Ну хочется же через шаблоны. И чтобы любой тип...

> [87] Mystic ©   (29.08.08 16:52)

Ну так ничего не мешает приделать эти функции к шаблонам.

Удалено модератором
Примечание: Не ругайся

> >[82] Mystic © (2008-08-29 15:37:00)
> >можно ли нужным образом перегрузить операцию точка.
> нет. только ->


Значит скоро выйдет новый стандарт и будет всем счастье

>[90] Mystic © (2008-08-29 18:24:00)
угу. счастье ловить баги в реализациях стандарта разными компиляторами.

вообще, давно пора писать в резюме не «знаю C++», а «знаю m$ C++», «знаю borland C++», «знаю gnu C++», etc.

---
Do what thou wilt shall be the whole of the Law.

> [91] ketmar ©   (29.08.08 18:28)

Почему? Если писать нормально, то результат будет одинаковым на любом компиляторе.

> ketmar ©   (29.08.08 18:28) [91]

Ты преувеличиваешь.
Я на работе пишу код который должен собираться 5-6 разными компиляторами.
Так что о состоянии дел с совместимостью компиляторов я знаю. Совместимость между production quality решениями хорошая.

>[92] @!!ex © (2008-08-29 19:47:00)
>[93] Alkid (2008-08-29 20:10:00)
угу. пока не выходишь за subset, реализованый везде.

я уж молчу о том кайфе, который добавляют разные оптимизаторы — это занятная игра «что, где, когда» получается.

---
Understanding is not required. Only obedience.

А мне C# нравится :-)

А мне - девушки :)

> Alkid   (28.08.08 22:42) [37]
> typedef  void (A::*ClassAFuncPtr)() ; // тип указатель на функцию-член класса A
И имеем мы жесткую привязку к классу. Сойдет, но не всегда.

> XentaAbsenta ©   (29.08.08 13:20) [64]
> хз..., а насчёт редактора кода - посмотри на VCPP + VisualAssist
Глянем, спасибо.

> ketmar ©   (30.08.08 04:06) [94]
> угу. пока не выходишь за subset, реализованый везде.
Часто приходится? :)

> KilkennyCat ©   (30.08.08 14:02) [96]
>
> А мне - девушки :)


Ты ж понимаешь, что интересоваться только одними девушками, и больше ни чем есть признак скудного ума. :)

> ketmar ©   (30.08.08 04:06) [94]

Опять преувеличиваешь.
Мы на работе весьма полно используем С++ с его шаблонными наворотами и проч. Проблем не было. Самая большая проблема - разные варнинги на разных компиляторах.


> Asteroid ©   (30.08.08 14:02) [97]



> И имеем мы жесткую привязку к классу. Сойдет, но не всегда.

Это не большая проблема. А вообще - шаблоны, мой друг :)