C++: каждый класс в своём модуле. В чём прикол? (23 стр)

DevilDevil
> Прекрасно если это будет

Особенно, если это будет вот так

vladislav
ага, проблема из разяряда "а что если пользователь внезапно выключит компьютер" =)

Ogra

видео не видел
но процитирую себя

Ogra
> Вот до слов "удалим его" все было правильно ;)
что, удалять его не будем? он же не правильно загрузился. а что мы в finally будем делать тогда?

Ogra
> Пример - в менеджере ресурсов 2000 объектов, нужно добавить еще 10.000,
> загрузив их по сети, но на 5.000 возникает исключение - "Нельзя прочитать файл"
Кэш на диске, грузим только если нет в кэше. Вы всё равно с 5000 объектами ничего не сделаете, вам нужно все 10000. Всё равно придётся их убивать. А если сделаете - то зачем вам все 10000 разом?
vladislav
> Классический пример - при закрытии буферизированного потока необходимо сделать
> flush. Что делать в ситуации, когда он по какой-то причине не получился
> (например, пользователь тупо флэшку вытащил)?
Пользователь - дурак. Ему же было сказано "не вытаскивайте флешку". Вы не можете защититься от идиотии и факторов вам в принципе неподвластных.
Ogra
> Речь о том, что иногда даже при исключении "нехватка памяти" можно не ронять
> программу и сохранить её работоспособность.
Не знаю про какие программы вы говорите - но в играх всё бинарно. Или мы загрузили всё и без проблем или мы не загрузили ничего вообще. А проверка данных всегда делается при сборке. Если вы не проверяете данные при сборке - вы дурак.

zlos
> Не знаю про какие программы вы говорите - но в играх всё бинарно. Или мы
> загрузили всё и без проблем или мы не загрузили ничего вообще. А проверка
> данных всегда делается при сборке.

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

yatagarasu
> ага, проблема из разяряда "а что если пользователь внезапно выключит компьютер"
> =)
zlos
> Пользователь - дурак. Ему же было сказано "не вытаскивайте флешку". Вы не
> можете защититься от идиотии и факторов вам в принципе неподвластных.

И пользователи тоже вас любят :).

Вообще-то это стандартная ситуация, которах должна обрабатываться классическими Abort/Retry/Ignore. И проблема здесь - именно в протечке абстракции RAII.

DevilDevil
> но не изучив вопрос, не попробовав - по меньше мере глупо
во флеше есть, я пробовал
но так и не понял почему я должен писать проверти вместо удобочитаемого геттера или сеттера

Pushkoff

значит мало пробовал
или не тем концом вставлял )

DevilDevil
> значит мало пробовал
> или не тем концом вставлял )
достаточно чтоб понять что это лишнее
программирование ради программирования

если присваивание переменной требует дополнительных телодвижений, то это не должно выглядеть как присваивание переменной
простые вещи должны выглядеть просто, к сложным вещам это правило не применимо

если против, приведи четкие критерии когда нужно использовать именно свойство. чтобы они не были основаны на личном ощущении программиста.
как правила SOLID допустим

Pushkoff
> если против, приведи четкие критерии когда нужно использовать именно свойство.
> чтобы они не были основаны на личном ощущении программиста.
> как правила SOLID допустим

свойство нужно использовать всегда, если это не "дата-холдер"

потому как является универсальной читабельной эффективной единицей по управлению сущностями

DevilDevil
> потому как является универсальной читабельной эффективной единицей по
> управлению сущностями
спасибо поржал

>потому как является универсальной читабельной эффективной единицей по управлению сущностями
кажется это очередной пункт для манифеста ) www.пиши-код....

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

Pushkoff
Warn
susageP

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