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

S>>Эта проблема появится не раньше, чем у нас в конторе заведётся человек,
S>>который выставит размер табуляции отличный от 4 и начнёт на это
S>>жаловаться. Пока таких не было.
RO>А это — очень плохой подход. Из той же серии, что и «оставим как есть, пока не придет человек с броузером, отличным от Microsoft Internet Explorer, и не начнет жаловаться».
Отнюдь.
В CodingStandard вносится правило tab == 4 пробела.
И на этом проблема исчерпывается.
Все остальные заморочки решаются настройкой редакторов в единый стиль.

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

E>Чтобы не быть голословным, вот пример из проекта, который я пишу прямо сейчас:
E>

E>so_add_destroyable_traits(
E>        new so_msg_templ_postman_t< msg_send_finish >(
E>                so_query_name(),
E>                "msg_send_finish",
E>                and_analyzer(
E>                        dest_equality_analyzer( 
E>                                mbox_dest_t( cfg.m_listening_mbox ) ),
E>                        not_rerouted_by_analyzer( so_query_name() ) ),
E>                cfg.m_interception_priority,
E>                intercept_msg ) );
E>

Ой блин каша какая!
Долго бить по рукам кувалдой и заставлять разбивать на строки.
Хотя бы так:

auto var1 = dest_equality_analyzer (mbox_dest_t (cfg.m_listening_mbox));
auto var2 = not_rerouted_by_analyzer (so_query_name());
auto var3 = and_analyzer (var1, var2);

so_add_destroyable_traits
(
        new so_msg_templ_postman_t< msg_send_finish >
        (
                so_query_name(), "msg_send_finish",
                var3, cfg.m_interception_priority, intercept_msg
        )
);

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

CC>Хотя бы так:

CC>

CC>auto var1 = dest_equality_analyzer (mbox_dest_t (cfg.m_listening_mbox));
CC>auto var2 = not_rerouted_by_analyzer (so_query_name());
CC>auto var3 = and_analyzer (var1, var2);
CC>

Мы говорим о C++98, C++0x (который в топке, бо ни жывы яще) или D?

Да, и кстати говоря, стиль не выдержан. Настоящий Ъ-вэй так:

auto var0 = mbox_dest_t (cfg.m_listening_mbox);
auto var1 = dest_equality_analyzer (var0);
auto var2 = not_rerouted_by_analyzer (so_query_name());
auto var3 = and_analyzer (var1, var2);

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

E>Мы говорим о C++98, C++0x (который в топке, бо ни жывы яще) или D?

не в топке, а в печи, бо печётся

а почему С++03 за бортом? С++98 устарел 5 лет назад

E>Настоящий Ъ-вэй так:

"Ъ-вэй" — это что? И как произносится?

You will always get what you always got
  If you always do  what you always did

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

J>а почему С++03 за бортом? С++98 устарел 5 лет назад

А в C++03 есть автоматический вывод типов переменных? Дайте два!

E>>Настоящий Ъ-вэй так:

J>"Ъ-вэй" — это что? И как произносится?

True-way. Ну типа конкретно единственно правильный путь, чиста для реальных пацанов.
На LOR часто употребляется просто "Ъ", например, "это не-Ъ" или "а настоящий Ъ -- это..."

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

NB>>>Google C++ Style Guide

D>>Процентов 30 наивно.

MS>Если так рассуждать, то в ПДД вообще все наивно.


MS>Думаю, что этот guide написан опытом ведения больших проектов

Ты забыл добавить слово "опенсорсных"

А что ты думаешь по поводу запрещения множественного наследования, например?
И связано ли это с ПДД?

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

E>Мы говорим о C++98, C++0x (который в топке, бо ни жывы яще) или D?
Ну я не знаю какой там у тебя тип возвращают эти функции, вот и написал так, чтоб было понятно.

E>Да, и кстати говоря, стиль не выдержан. Настоящий Ъ-вэй так:
Нет, там уже другая крайность.

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

E>>Мы говорим о C++98, C++0x (который в топке, бо ни жывы яще) или D?
CC>Ну я не знаю какой там у тебя тип возвращают эти функции, вот и написал так, чтоб было понятно.

Вообще-то между записями:

std::auto_ptr< dest_equality_analyzer_t< mbox_dest_t > > > var1 = dest_equality_analyzer( mbox_dest_t( cfg.m_listening_mbox ) );

и

auto var1 = dest_equality_analyzer( mbox_dest_t( cfg.m_listening_mbox ) );

есть, имхо, очень большая разница.

E>>Да, и кстати говоря, стиль не выдержан. Настоящий Ъ-вэй так:
CC>Нет, там уже другая крайность.

А каковы критерии определения крайностей? Почему нужно именно три varN, а четвертая -- это уже крайность?

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

A>Вот это ты классно! Одним. Словом. Всю статью разбил.
Ну что поделать если статью можно разбить одним словом?
Тем более что я показал как нужный результат получают другими методами.
Что нечем крыть чисто декларативный код?

public abstract DepartmentAccessor : DataAccessor<Department, DepartmentAccessor>
{
    [Cache(MaxMinutes = 5)]
    public abstract List<Department> SelectAll();

    [ClearCache("SelectAll")]
    public abstract Department Insert([Destination(NoMap = false)]Department d);
}

A>Смешно просто. У тебя установка такая, не принимать аргументы собеседников не при каких условиях?
Нет у меня накиких установок.

A>"Кэш не обновляют, а другое решение ваще не масштабируется, поэтому нигде ничего откатывать не нужно, и не приводите мне ваших сферосценариев в вакууме!"
Ну как всегда... пошла демагогия.
Что аргументов ваще нет?

A>Тяжелый случай.
Ага.

Здравствуйте, Юрий Жмеренецкий, Вы писали:

WH>>В системах с GC тут приберется GC.
WH>>В системах без GC все будет сделано сильно иначе.
ЮЖ>GC тут нет,
Напомню фразу с которой пошол флейм:

Так что Имею Мнение Хрен Оспоришь что польза от RAII при наличии GC мягко говоря приувеличина.

И еще одну:

J>а уж захват памяти, от которого помогает GC — это еще меньшее подмножество подобных действий.
Чё? Да это 99% случаев использования RAII если не больше.

ЮЖ>а сильно иначе(для исправления этой ситуации) не получится.
Зная конкретику как правило получается.

ЮЖ>Ну получилось так, legacy и т.п.
А рефакторинг не катит?

ЮЖ>Стримы это только пример, ключевой момент я там выделил — восстановление состояния при ошибках (+ их обработка вынесена из основного кода и не бросается в глаза, как try/catch выше).
Лично я всегда обходился другими методами.

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

J>ну тебе, безусловно, по этим пяти строчкам, написанным для демонстрации возможностей RAII, видно, что вся система у меня не масштабируется
Ну да.
Шаренный стейт не масштабируется.

J>для этого на недогрузившийся мусор должны пропасть все внешние ссылки — они каким образом будут пропадать?
Лучше ответь на вопрос: Откуда они возьмутся?

J>Вот ты свой недогрузившийся мусор (ты просто еще не знаешь, что это мусор, ибо so far so good) положил в контейнер, работаешь дальше, вызываешь разнообразные функции, и тут из недр стека к тебе прилетело исключение — какую-то лажу мы грузим тут — и что, как тебе GC поможет удалить добавленный элемент из контейнера?
Даже не знаю как на это реагировать.
Лично я не кладу недосозданные объекты в контейнер.

J>да никак не зависит. Транзакционность функции — очень узкая задача (RAII существует только в контексте функции, даже еще уже — в контексте области видимости). Никакие более высокоуровневые вещи RAII сама по себе решить не может, как их не может решить ни одно локально применимое средство языка.
"Транзакционность функции" мда сильно задвинул.
У меня не бывает задач сделать транзакционную функцию.
У меня бывают задачи провести транзакцию над неким хранилищем.
И вот тут транзакционные функции ну никак не помогают.

WH>>Как мне поможет RAII если у меня процесс с этим самым RAII сдох посреди транзакции?
J>Я понятия не имею, как у тебя организован message flow, и как ты узнаешь о том, что процесс сдох, ...
Да не важно это все.
Важно то что если мы что-то меняем в совершенно любом персистентном хранилище то для обеспечения транзакций RAII абсолютно бесполезен.
Просто по тому что RAII живет только пока живет процесс.
А если вдруг процесс умер то вся информация о транзакции умрет вместе с эти процессом.
И как следствие у нас не будет информации чтобы востановить хранилище после сбоя.

Я думал что это совершенно очевидно.

J>Тебе несколько раз уже продемонстрировали, как именно RAII работает в ситуациях, не связанных с управлением критичными ресурсами.
Ну да.
Либо оно решается другими способами сильно проще.
Либо решение на RAII вобще не устойчиво к сбоям.

J>И если бы вдруг GC взял на себя все вопросы с управлением памятью объектов из кучи, область применения RAII уменьшилась бы совсем ненамного.
Практика показывает что оно ограничевается максимум парой using на метр кода.

J>Зачем при написании этого кода отказываться от возможностей, предоставляемых языком, и искуственно ограничивать область применения до управлением памятью в куче...
За тем что эти возможности для других задач бесполезны. А то и вредны.

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

E>есть, имхо, очень большая разница.
Откуда ты auto_ptr вынул то?

E>А каковы критерии определения крайностей? Почему нужно именно три varN, а четвертая -- это уже крайность?
Читабельность + разумные рамки вложенностей.

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

E>>есть, имхо, очень большая разница.
CC>Откуда ты auto_ptr вынул то?

Ну мне-то лучше знать, что мои функции возвращают

E>>А каковы критерии определения крайностей? Почему нужно именно три varN, а четвертая -- это уже крайность?
CC>Читабельность + разумные рамки вложенностей.

Не сильно объективный критерий.

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

CS>

CS>for (int i = 1; i < argc; i++) {
CS>}
CS>

а еще "i++", а не ++i.

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

CS>>

CS>>// Store list of input files into "spec"
CS>>for (int i = 1; i < argc; i++) {
[]
CS>>}
CS>>

MSL>а еще "i++", а не ++i. Фубля.

Дааа, это важно в данном случае

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

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

J>>ну тебе, безусловно, по этим пяти строчкам, написанным для демонстрации возможностей RAII, видно, что вся система у меня не масштабируется
WH>Ну да.
WH>Шаренный стейт не масштабируется.
ну, до сих пор прекрасно масштабировался.
Посмотри, например, на FIX Protocol — там тот самый "шаренный стейт".
Подход, вкратце, элементарный — стейт однозначно кодируется последовательностью сообщений, все сообщения в системе упорядочены и все компоненты получают их в одном и том же порядке. Стало быть, расшаренный стейт у всех будет одинаковый.
Ну, либо мы говорим о разных вещах и друг друга не понимаем.

J>>для этого на недогрузившийся мусор должны пропасть все внешние ссылки — они каким образом будут пропадать?
WH>Лучше ответь на вопрос: Откуда они возьмутся?
WH>Лично я не кладу недосозданные объекты в контейнер.

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

J>>да никак не зависит. Транзакционность функции — очень узкая задача (RAII существует только в контексте функции, даже еще уже — в контексте области видимости). Никакие более высокоуровневые вещи RAII сама по себе решить не может, как их не может решить ни одно локально применимое средство языка.
WH>"Транзакционность функции" мда сильно задвинул.

Это не я задвинул, это вполне устоявшийся термин. А именно: если у тебя есть объект какого-то класса и ты зовешь какой-то его метод, то метод называется транзакционным (другой термин — дает strong exception safety guarantee), если при в случае вылета из метода по исключению состояние объекта не меняется. Basic exception safety guarantee — это когда состояние объекта может измениться, но при этом оно останется корректным (т.е. все инварианты будут выполнены).
Все тут, кроме тебя, говорят исключительно об этой транзакционности и о том, что RAII помогает именно с этой транзакционностью.

WH>У меня не бывает задач сделать транзакционную функцию.
WH>У меня бывают задачи провести транзакцию над неким хранилищем.
WH>И вот тут транзакционные функции ну никак не помогают.

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

WH>>>Как мне поможет RAII если у меня процесс с этим самым RAII сдох посреди транзакции?
J>>Я понятия не имею, как у тебя организован message flow, и как ты узнаешь о том, что процесс сдох, ...
WH>Да не важно это все.
WH>Важно то что если мы что-то меняем в совершенно любом персистентном хранилище то для обеспечения транзакций RAII абсолютно бесполезен.
WH>Просто по тому что RAII живет только пока живет процесс.
WH>А если вдруг процесс умер то вся информация о транзакции умрет вместе с эти процессом.
WH>И как следствие у нас не будет информации чтобы востановить хранилище после сбоя.

WH>Я думал что это совершенно очевидно.

Я тоже думал, что я написал в удаленном тобой моем тексте именно это и ты эти мои слова прочитал.
Теперь не уверен.

WH>Либо решение на RAII вобще не устойчиво к сбоям.
Пример в студию, когда RAII неустойчиво к сбоям.

J>>И если бы вдруг GC взял на себя все вопросы с управлением памятью объектов из кучи, область применения RAII уменьшилась бы совсем ненамного.
WH>Практика показывает что оно ограничевается максимум парой using на метр кода.
Ну естественно, это верно в случае твоей практики, когда RAII больше ни для чего не применяется
Было бы странно, если было бы наоборот.

J>>Зачем при написании этого кода отказываться от возможностей, предоставляемых языком, и искуственно ограничивать область применения до управлением памятью в куче...
WH>За тем что эти возможности для других задач бесполезны. А то и вредны.

You will always get what you always got
  If you always do  what you always did

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

MSL>>а еще "i++", а не ++i.
A>Дааа, это важно в данном случае

Вы разбазариваете такты процессора! Подозреваю, что также не бережете и межгаллактический запас скобок )))))) На самом деле режет глаз. Как и когда в сравнениях константы не слева.

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

CS>>>>

CS>>>>// Store list of input files into "spec"
CS>>>>for (int i = 1; i < argc; i++) {
A>>[]
CS>>>>}
CS>>>>

MSL>На самом деле режет глаз. Как и когда в сравнениях константы не слева.

Т.е. на Ваш взгляд должно быть так?

for (int i = 1; argc >= i; ++i) {
}

Ну что ж, о вкусах не спорят.

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

E>>>есть, имхо, очень большая разница.
CC>>Откуда ты auto_ptr вынул то?
E>Ну мне-то лучше знать, что мои функции возвращают
В таком случае для C++0x auto это как раз то самое применение.

E>>>А каковы критерии определения крайностей? Почему нужно именно три varN, а четвертая -- это уже крайность?
CC>>Читабельность + разумные рамки вложенностей.

E>Не сильно объективный критерий.
Та каша с дикой вложенностью имеет более объективное обоснование?

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

MSL>а еще "i++", а не ++i. Фубля.
Для int-а абсолютно параллельно...