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

E>>Или ты уже и так с ними расстался настолько, что не рискнёшь предложить коллегам по 100 баксов за каждый уникальный случай нарушения гарантий?..
X>вы мусолите коня в вакууме. сами придумываете несуществующие проблемы, и сами их решаете. КПД 0%.
Интересно, из чего ты сделал такой вывод?..
Если ты не понял, то я утверждаю, что пока что ещё не видел большого проекта, в котором пытались обеспечить базовую гарантию, но при этом смогли это сделать на самом деле...

То есть я НЕСКОЛЬКО раз проверял то, что гарантия якобы обеспечена, и КАЖДЫЙ раз выяснялось, что она очень во многих местах не обеспечена на самом деле...
Просто я несколько раз переносил довольно большие проекты между платформами/компиляторами/ендианами/битностями и т. д. При таком переносе гамно из кода лезет только в путь. И я больше не верю заверениям типа того, "ну тут у нас везде жеж базовая гарантия"...

Ты, насколько я тебя понял, думаешь, что веришь в то, что обеспечение базовой гарантии достижимо.
Вот я и предлагаю тебе простой эксперемент, возможно мысленный, что бы проверить кропость и обоснованность твоей веры.
Насколько я тебя понял, ты не готов предлагать по 100 баксов за обнаружения нарушения гарантий? Видимо это обозначает, что вера твоя не так уж и крепка
А какую суммы то готов предложить, кстати? Ну хотя бы 10 баксов-то готов? Правда я сомневаюсь, что за 10 баксов много елающих будет что бы искать...

X>успехов.
Спасибо...

Взаимно.

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

_>Ни примера правильной реализации через коды

Код покажи, чтобы начать разговор. Хорошо?

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


L>Что это за метод такой, который не принимает параметров и ничего не возвращает? Это private, который вызывается только из конструктора? Тогда никаких проблем, пусть себе кидает.
L>Если нет, то это — говнокод без вариантов, по сути версия метода Construct обсуждаемого фреймворка. Period.

это псевдокод, удивись ещё точке после this, умник, может ты суть будешь читать? можешь не отвечать, с тобой диалог тоже закончен.

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

E>То есть я НЕСКОЛЬКО раз проверял то, что гарантия якобы обеспечена, и КАЖДЫЙ раз выяснялось, что она очень во многих местах не обеспечена на самом деле...
E>Просто я несколько раз переносил довольно большие проекты между платформами/компиляторами/ендианами/битностями и т. д. При таком переносе гамно из кода лезет только в путь. И я больше не верю заверениям типа того, "ну тут у нас везде жеж базовая гарантия"...

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

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

L>Вообще-то вся темя — это обсуждение новомодного фреймвор.. нет, framewreck-а. Где из-за отказа от исключений внедрили передовые технологии "двухфазной инициализации" и революционный подход "объект после вызова конструктора может оказаться в черт-те каком состоянии". Правда, как оказалось, конструктор копирования инновациями не удостоили, поэтому ждем следующей версии.

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

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

MTD>Код покажи, чтобы начать разговор. Хорошо?

Вот, первый человек по делу что-то сказал. Хотя там в принципе был кусок кода, который обсуждали и можно было с ним поработать... Но он слишком громоздкий и кривой, поэтому для начала возьмём что-то совсем простое, типа такого:

void OnInit()
{
    ...
    string name=GetName();
    if(!ReadProfile(name)) CreateNewProfile(name);
    ...
}

Думаю логика работы очевидна, да? Так вот как будет выглядеть подобный код, если переписать его через исключения (их тогда бросает функция ReadProfile)? Он будет удобнее приведённого выше или нет?

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

X>доказательств в теме полно. начиная от несуществующих проблем, и заканчивая тотальным словоблудием о несуществующих проблемах.
X>повторюсь: КПД 0%

Если уж сливаться из дискуссии, то хотя бы по нормальному, а не с таким пафосом...

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

_>как будет выглядеть подобный код, если переписать его через исключения (их тогда бросает функция ReadProfile)? Он будет удобнее приведённого выше или нет?
тут нет исключительной ситуации. думаю, ответ очевиден.

зы
ппц, когда люди начнут понимать, от какого слова появилось слово исключения в ЯП %)

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

_>Вот, первый человек по делу что-то сказал. Хотя там в принципе был кусок кода, который обсуждали и можно было с ним поработать... Но он слишком громоздкий и кривой, поэтому для начала возьмём что-то совсем простое, типа такого:
_>

_>void OnInit()
_>{
_>    ...
_>    string name=GetName();
_>    if(!ReadProfile(name)) CreateNewProfile(name);
_>    ...
_>}
_>

_>Думаю логика работы очевидна, да? Так вот как будет выглядеть подобный код, если переписать его через исключения (их тогда бросает функция ReadProfile)? Он будет удобнее приведённого выше или нет?

Очевидна, но:
1. Отсутствие профиля не является исключительной ситуацией
2. А вот функция создания профиля вполне может столкнуться с исключительной ситуацией и ты эту ситуацию не обрабатываешь.

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

P>Мой поинт в том, что тот уровень обработки ошибок, который обеспечивает "сферический программист в вакууме" за которого так болеет тролльErop, с помощью исключений обеспечивается проще и приятнее.

Не согласен. На мой взгляд исключение действительно удобны только для очень узкого вида ошибок, которые должны приводить к глубокой раскрутке стека. Для большинства же случаев (а чаще всего какая-то минимальная обработка ошибок идёт уже на предыдущем уровне стека вызовов) на практике исключения привносят только увеличение сложности и объёма кода.

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

_>Если уж сливаться из дискуссии, то хотя бы по нормальному, а не с таким пафосом...
если уж и пытаться выдавать себя за человека знающего сабж, то как минимум следовало прочитать хотя бы вводной курс про исключения, дабы не производить "то", что ты выдал выше.

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

_>на практике исключения привносят только увеличение сложности и объёма кода.
конечно, если их использовать в качестве кодов возврата

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

[]

_>Думаю логика работы очевидна, да? Так вот как будет выглядеть подобный код, если переписать его через исключения (их тогда бросает функция ReadProfile)? Он будет удобнее приведённого выше или нет?

Имхо, приведенный код в данном контексте просто квинэссенция не понимания "для этого их и придумали".
1. Зачем его переписывать через исключения, что було?
Если ты можешь обработать "ошибку" на этом уровне, ее и нужно там обработать. Для данного случая это не ошибка, это нормальная ситуация.
Исключением это будет если ты на этом уровне не можешь вызвать CreateNewProfile, тогда логично кинуть исключение,
которое поймает тот уровень который может сделать CreateNewProfile.
2. Или ты хочешь поговорить о том, нужно ли ф-и ReadProfile кидуть исключение вместо кода возврата?

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

MTD>Очевидна, но:
MTD>1. Отсутствие профиля не является исключительной ситуацией
MTD>2. А вот функция создания профиля вполне может столкнуться с исключительной ситуацией и ты эту ситуацию не обрабатываешь.

Т.е. ошибки работы с файловой системой мы обрабатываем без исключений, так? Отлично! У меня такое же мнение. А то мне в этой теме заявляли что вполне нормально ВСЕ ошибки обрабатывать через исключения и это будет всё равно лучше кодов возврата. Похоже что наши позиции не так уж сильно и отличаются... Теперь осталось только определиться, что же тогда на практике нам удобно обрабатывать через исключения? Ошибки выделения памяти видимо. А ещё что? )

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

P>Имхо, приведенный код в данном контексте просто квинэссенция не понимания "для этого их и придумали".

Ну так я о том и говорю)

P>2. Или ты хочешь поговорить о том, нужно ли ф-и ReadProfile кидуть исключение вместо кода возврата?

Естественно и вообще то это прямо и написано в том моём сообщение.

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

_>Т.е. ошибки работы с файловой системой мы обрабатываем без исключений, так? Отлично!
я единственный не понимаю, из чего последовал этот вывод?

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

MTD>>1. Отсутствие профиля не является исключительной ситуацией
MTD>>2. А вот функция создания профиля вполне может столкнуться с исключительной ситуацией и ты эту ситуацию не обрабатываешь.

_>Т.е. ошибки работы с файловой системой мы обрабатываем без исключений, так? Отлично! У меня такое же мнение. А то мне в этой теме заявляли что вполне нормально ВСЕ ошибки обрабатывать через исключения и это будет всё равно лучше кодов возврата. Похоже что наши позиции не так уж сильно и отличаются... Теперь осталось только определиться, что же тогда на практике нам удобно обрабатывать через исключения? Ошибки выделения памяти видимо. А ещё что? )

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

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

_>>Т.е. ошибки работы с файловой системой мы обрабатываем без исключений, так? Отлично! У меня такое же мнение. А то мне в этой теме заявляли что вполне нормально ВСЕ ошибки обрабатывать через исключения и это будет всё равно лучше кодов возврата. Похоже что наши позиции не так уж сильно и отличаются... Теперь осталось только определиться, что же тогда на практике нам удобно обрабатывать через исключения? Ошибки выделения памяти видимо. А ещё что? )

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

Т.е. я правильно понимаю, что вот этот http://www.rsdn.ru/forum/cpp/5082668

Автор: MTD
Дата: 26.02.13

пример вы бы переписали через исключения? Т.к. никакой перформанс там совсем не требуется...

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

_>Т.е. я правильно понимаю, что вот этот http://www.rsdn.ru/forum/cpp/5082668

Автор: MTD
Дата: 26.02.13

пример вы бы переписали через исключения? Т.к. никакой перформанс там совсем не требуется...

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

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

T>Пока что не было никаких указаний, что это за код, на сервере, на клиенте, какие требования по перформансу и тд. Покажи все ограничения, тогда модно будет подумать. Если исключение создает проблему с перформансом, то этот код должен вызваться наверное миллион раз в секунду или чаще.

Я же говорю, никаких ограничений в этом смысле...

Т.е. как я понял стали бы использовать, да?

А какие преимущества (по сравнению с приведённым кодом) в данном конкретном случае вы от этого видите?