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

C>>Правда — тебе надо вернуться вниз и дописать код в finally. Это элементарно можно забыть (видел не раз).
N>Забыть, что данные действия надо вернуть назад, ещё проще — тогда не надо создавать никаких обёрточных классов.
Понимаешь, я при написании кода и соблюдении простейших правил вообще в принципе не могу забыть освободить ресурсы. Ну разве что если не постараюсь и не сделаю циклические ссылки где-нибудь, но это уже ошибка логики.

C>> Деструкторы вообще пофиг где находятся — нам их видеть не обязательно.
N>Что, в другом файле, чем конструктор? Вот за это точно канделябром.
Я имею в виду про деструкторы ресурсов. Мне абсолютно пофиг при использовании boost::scoped_lock иди file_handle_t в каком файле оно определено. Главное, что мне гарантировано их освобождение.

N>>>Кто такой ON_BLOCK_EXIT? И всё равно это означает код, угнанный куда-то далеко за пределы непосредственной видимости.
C>>Мда. http://www.ddj.com/dept/cpp/184403758
N>Ага, ну если такой изврат, то ещё как-то терпимо.
Изврат — это писать в стиле С

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

N>Попросите у ближайшего эрланговца эпохальный диссер Армстронга про устойчивость сетевых приложений в телекоммуникационной сфере Специфика есть, и она именно в том, что даже если какой-то один модуль глюкает и отработка звонка (соединения, etc.) обломалась — остальное должно работать и с минимальной завязкой на проблемы того уровня. В случае такой защиты и подложки с собственным управлением памятью (i.e. c GC) я это имею (даже на Питоне, не говоря уж про Erlang). Так что — причины есть.

Погоди, но в Эрланге это все отдельными процессами сделано. Т.е. процесс умер, сделали заново и работаем. Дык кто тебе в плюсах мешает запустить код который отвечает за коммуникацию в отдельный процесс? Вот и получим надежность на уровне Эрланга.

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

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

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

N>>Попросите у ближайшего эрланговца эпохальный диссер Армстронга про устойчивость сетевых приложений в телекоммуникационной сфере:))) Специфика есть, и она именно в том, что даже если какой-то один модуль глюкает и отработка звонка (соединения, etc.) обломалась — остальное должно работать и с минимальной завязкой на проблемы того уровня. В случае такой защиты и подложки с собственным управлением памятью (i.e. c GC) я это имею (даже на Питоне, не говоря уж про Erlang). Так что — причины есть.

DC>Погоди, но в Эрланге это все отдельными процессами сделано. Т.е. процесс умер, сделали заново и работаем. Дык кто тебе в плюсах мешает запустить код который отвечает за коммуникацию в отдельный процесс? Вот и получим надежность на уровне Эрланга.

Мешает то, что если это настоящие системные процессы, то подход крайне дорог и слабо масштабируем (то что в Erlang зовётся "процессами" это отнюдь не системные сущности), а если что-то внутри среды управления — то управление памятью со стороны программиста, а не исполняющей среды (как в C, C++ и так далее) — убьёт надёжность за счёт memory leaks, если не чего-то похуже. И синхронизация на общих объектах невозможна (не смог освободить мьютекс => опаньки).

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

Вот именно. Erlang берёт здесь тем, что на уровне среды исполнения отграничивает эти "процессы". Это тоже не всегда работает (например, при взаимодействии с железом), но в большинстве случаев — да. Система другого рода, но с GC и исключениями, даёт некоторое приближение к такой надёжности (не идеальное, но меня устраивает). Но если мне, как давешний оппонент, чуть ли не запрещают перехватывать исключения — я ничего не получаю.

N>Вот именно. Erlang берёт здесь тем, что на уровне среды исполнения отграничивает эти "процессы". Это тоже не всегда работает (например, при взаимодействии с железом), но в большинстве случаев — да. Система другого рода, но с GC и исключениями, даёт некоторое приближение к такой надёжности (не идеальное, но меня устраивает). Но если мне, как давешний оппонент, чуть ли не запрещают перехватывать исключения — я ничего не получаю.

разница имхо в том, что эрланговская порграмма в приницпе не может изгадить память. в эрланге просто нет указателей сужу по своему опыту работы с haskell'ом — за 3 года только однажды я что-то непотребное сотоворил. соответственно крах эпланговой нити не означает, что она изгадит общее пространство памяти, разделяемое с другими нитями — это чисто алгоритмический крах из-за того, что алгоритм не предусматривает обработку какой-либо ситуации

в С++ это конечно тоже будет работать, и от алгоритмических недоделок защитит. проблема в том, что в C++ есть ошибки и другого рода — когда похабится память. и для того, чтобы защититься от них, надо или использовать исключительно высокоуровневый подход к программированию (никакой ссылочной арифметики) ии вообще другой язык

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


N>Мешает то, что если это настоящие системные процессы, то подход крайне дорог и слабо масштабируем (то что в Erlang зовётся "процессами" это отнюдь не системные сущности), а если что-то внутри среды управления — то управление памятью со стороны программиста, а не исполняющей среды (как в C, C++ и так далее) — убьёт надёжность за счёт memory leaks, если не чего-то похуже. И синхронизация на общих объектах невозможна (не смог освободить мьютекс => опаньки).

Что касается настоящи мьютексов, то

If a thread terminates without releasing its ownership of a mutex object, the mutex object is considered to be abandoned. A waiting thread can acquire ownership of an abandoned mutex object, but the wait function's return value indicates that the mutex object is abandoned.

X>>1. А нафига вы юзаете VSS ведь это отстой по определению, и все нормальные конторы юзают либо CVS либо Subversion?

MSS>Вы точно уверены, что хотите на ходу посреди проекта менять сорс-контрол?

Конечно, это задача не самого высокого приоритета, но я тем не менее выделил бы пару человеко-дней чтобы этим заняться. Поскольку если в проекте ещё планируется несколько человеко-месяцев, то эти затраты окупятся со 100% вероятностью. Переход на SVN с различных VCS довольно хорошо обкатан, есть куча руководств и рекомендаций в инете. Всего, конечно, не предусмотришь — но не так страшен чёрт.

MSS>Не в сорс-контроле дело тут, а в руках и мозгах. Можно и на VSS работать на порядок качественнее, чем обсуждаемая команда. А можно и на TFS запутаться.

Аргумент из разряда "нафиг C, если есть мозги то можно и на asm-е писАть". Мастера узнают по инструментам. SVN реально более прогрессивный инструмент, который по фичерам и удобству кроет VSS как бык овцу. Для небольших или уже законченых (в стадии поддержки) проектов я готов смириться с отсталым VCS. Проект в стадии активной разработки — должет лежать в нормальной современной VCS (читай — SVN ) — потому что удобство + фичеры (даже если они поначалу кажутся копеешными и не такими уж нужными) — в итоге дадут значительную экономию времени (читай — денег ).

MSS>Мдаа... расскажите нам (аудитории форума), в чем смысл версио-мании и гонки за последними версиями, особенно в условиях, когда речь о большом объеме старого кода.

Конечно, гнаться за последними версиями — это не зло, поскольку обрекаешь себя на хождение по неразведанным граблям. Но и плестись в хвосте тоже нет смысла — в конце концов такие вещи как runtime checks или дебажные версии STL могут помочь найти довольно трудноуловимые в других условиях баги. К тому же опять же — опыт показывает что не так уж сложен переход с 6-ки на 2003(2005)-ю студию.

MSS>На 5 человек?
5 >= 2. Да, на 5 человек — уже оправдано. Это ещё для одного можно было бы подумать.

MSS>Вот это — дело. Тут скорее вопрос — "почему вообще терпите такого слабого девелопера".
Не, тут вопрос скорее административный всё же. Девелопер может быть и хорошим, просто не привык работать в команде или нет культуры работы с VCS.

MSS>На моей бывшей работе codestyle вырабатывали 4 лида целый рабочий день минимум (или два, не помню уж), и консенсусу — кроме совсем основополагающих вещей — не пришли.
Ага. Не пришли. Я сам в таком шабаше учавствовал пару раз. Но плохой codestyle — хуже полного его отсутствия. Ну, кроме клинических случаев, конечно

L>Конечно, гнаться за последними версиями — это не зло, поскольку обрекаешь себя на хождение по неразведанным граблям. Но и плестись в хвосте тоже нет смысла — в конце концов такие вещи как runtime checks или дебажные версии STL могут помочь найти довольно трудноуловимые в других условиях баги. К тому же опять же — опыт показывает что не так уж сложен переход с 6-ки на 2003(2005)-ю студию.

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

Так и хочется сказать фразой из "IT Crowd": "Common, are you from past?"

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

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

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

N>>Мешает то, что если это настоящие системные процессы, то подход крайне дорог и слабо масштабируем (то что в Erlang зовётся "процессами" это отнюдь не системные сущности), а если что-то внутри среды управления — то управление памятью со стороны программиста, а не исполняющей среды (как в C, C++ и так далее) — убьёт надёжность за счёт memory leaks, если не чего-то похуже. И синхронизация на общих объектах невозможна (не смог освободить мьютекс => опаньки).

КД>Что касается настоящи мьютексов, то

КД>

КД>If a thread terminates without releasing its ownership of a mutex object, the mutex object is considered to be abandoned. A waiting thread can acquire ownership of an abandoned mutex object, but the wait function's return value indicates that the mutex object is abandoned.

Во-первых, Вы бы приводили источник цитаты, а то гуглить когда кто-то просто не сказал где — немного обидно.
Во-вторых, это (нашёл уж, цитата из MSDN) про виндовые мьютексы. А зачем _мне_ рассказ про винду? Для меня актуальны pthreads, или в крайнем случае SysV IPC.

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

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

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

N>>>Попросите у ближайшего эрланговца эпохальный диссер Армстронга про устойчивость сетевых приложений в телекоммуникационной сфере Специфика есть, и она именно в том, что даже если какой-то один модуль глюкает и отработка звонка (соединения, etc.) обломалась — остальное должно работать и с минимальной завязкой на проблемы того уровня. В случае такой защиты и подложки с собственным управлением памятью (i.e. c GC) я это имею (даже на Питоне, не говоря уж про Erlang). Так что — причины есть.

DC>>Погоди, но в Эрланге это все отдельными процессами сделано. Т.е. процесс умер, сделали заново и работаем. Дык кто тебе в плюсах мешает запустить код который отвечает за коммуникацию в отдельный процесс? Вот и получим надежность на уровне Эрланга.

N>Мешает то, что если это настоящие системные процессы, то подход крайне дорог и слабо масштабируем (то что в Erlang зовётся "процессами" это отнюдь не системные сущности), а если что-то внутри среды управления — то управление памятью со стороны программиста, а не исполняющей среды (как в C, C++ и так далее) — убьёт надёжность за счёт memory leaks, если не чего-то похуже. И синхронизация на общих объектах невозможна (не смог освободить мьютекс => опаньки).

Погоди тебе шашечки или ехать? Вот такой С++ инструмент, придется все самому делать. Если не хочется бери более развитый инструмент.

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

N>Вот именно. Erlang берёт здесь тем, что на уровне среды исполнения отграничивает эти "процессы". Это тоже не всегда работает (например, при взаимодействии с железом), но в большинстве случаев — да. Система другого рода, но с GC и исключениями, даёт некоторое приближение к такой надёжности (не идеальное, но меня устраивает). Но если мне, как давешний оппонент, чуть ли не запрещают перехватывать исключения — я ничего не получаю.

Ну на С++ если все в RAII заворачивать и lock-free пользовать, STM всякий, т.е. более продвинутыми возможностями, тоже можно много добиться, просто там граблей больше.

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

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

КД>>Что касается настоящи мьютексов, то

N>Во-первых, Вы бы приводили источник цитаты, а то гуглить когда кто-то просто не сказал где — немного обидно.
N>Во-вторых, это (нашёл уж, цитата из MSDN) про виндовые мьютексы.

Звиняйте

N>А зачем _мне_ рассказ про винду? Для меня актуальны pthreads, или в крайнем случае SysV IPC.

Настоящем программисту ... не помеха