Но бывают ситуации (хоть и не часто), когда надо покомандовать и самой.


(с) Ultraviolet

:gigi:

Это сообщение отредактировал(а) Rififi - 2.8.2008, 13:20

В программах на С++ объекты имеют деструкторы, а механизм __try __finaly о них ничего не знает, и соответственно не вызывает. Это разве не аргумент?  


написать класс RtlUnicodeString  

создаешь wrapper и он все сделает сам : проинициализирует данные /буффер  в конструкторе и удалит его в деструкторе..

если мне не изменяет память, boost::shared_ptr имеет возможность указать какую-то свою функцию, которая будет использована вместо delete, в данном случае RtlFreeUnicodeString

т.е. будет что-то типа

Спасибо, хорошая ссылка.
P.S. А что такое "тыц" ?



Аргумент. Но аргумент, что неудобно использовать а не "вообще нельзя"   



Это серьезно или так принято посмеиваться над новичками ?   
Неужели для каждой подобной стуктуры ( ситуации ) надо писть свою обертку ?



Те же вопросы, что и к Lazin



Если они это (boost::shared_ptr) действительно умеют вызывать вместо delete нужную ф-ию , 
то это может оказаться выходом. (На первый взгяд. Очень на то похоже )

действительно умеют

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


ниче, просто ссылка 

Убедительно. 
Но все же хотелось бы найти возможность и самой покомандовать 



Я тут чуть подумала, насчет этого - не все так просто.
Дело в том, что наш объект может быть "инициализирован" разными способами.
И этих способов довольно много.
От RtlCreateUnicodeString - один вариант финализации, до  RtlInitUnicodeString - другой (нельзя освобождать буфер).
Плюс к этому, придется учитывать, что на протяжении своей жизни,
наш конкректный объект может менять эти способы как перчатки 
 (что вообщем то довольно часто и происходит)

Ну и в довесок: сейчас мы говорим о UNICODE_STRING
а как быть с другими (подобными) объектами ?
Может, лучше попробовать найти "валидный" способ самой поуправлять этим делом 

P.S.
 Неужели от __try __finaly придется отказаться ? 

В данном случае аргумент надо расценивать "нельзя вобше"  потому что деструктор така же важная деталь как и конструктор.
Потому что вначале отладите программу под плоские типы а потом замените на неплоский и долго долго будете искать где теряется память ))



да либо писать самому, либо  использовать уже кем то написаные и проверенные..
Не пойму что Вас так пугает? Вы готовы вручную контролировать каждый раз каждый вызов функции, вместо того чтоб один раз написать обертку в 10 строк и забыть о проблемах ! 


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

Добавлено через 4 минуты и 59 секунд
Мне кажется,  что у Вас несколько процедурный взгляд на программирование (сорри если что не так сказал). В ООП программа не должна быть завязана на реализации - благодаря этому ее удобно развивать и поддерживать   

Это сообщение отредактировал(а) mes - 2.8.2008, 21:19

для этого есть шаблоны

если использвать boost::function и boost::bind то можно сделать еще более гибко, для функций с разным набором параметров..
можно для этого просто использовать boost::shared_ptr...

несомненно, либо писать на чистом Си

Мой "взгляд на программирование" зависит от задачи стоящий передо мной
в данный момент времени.
Сейчас (сегодня) у меня действительно "процедурный взгляд".
Будет другая задача и он тут же изменится ( как у политиков    





Спасибо, большое !

vinter, 
Примеры, приведенные в "тыц", на мой взгляд не совсем "честные" 
Дело в том, что там смешиваются два типа обработки исключений.
Если Builder и пропускает это безобразие при компиляции, 
то VS уже кричит во всю глотку: "only one form of exception handling permitted per function". 
А то что Builder пропускает - не означает, что код "синтаксически код верен и вполне законен" (с) из "тыц".
ибо не все, что проглатывает компилятор - верно 
Рихтер, например, предупреждает, что не стоит путать SEH с обработкой исключений в C++.

Добавлено через 3 минуты и 45 секунд
P.S.
 Забыла сказать, что у меня в этих примерах, все блоки finally выполняются корректно.
 Может другая версия Builder`а.

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

ИМХО, на ООП стоит смотреть не как на средство сокрытия каких-то данных или создания больших и непонятных иерархий, а как на способ выбора места, где в программе расположить то или иное знание

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

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

  

Это сообщение отредактировал(а) mes - 4.8.2008, 00:05

Riply, в аттаче Вам хорошая статья про SEH  

Присоединённый файл ( Кол-во скачиваний: 23 )
 SEH.rar 253,66 Kb

Сложно не согласиться 



А ведь действительно хорошая 
IMHO, отвечает на некоторые вопросы, которым Рихтер не счел нужным уделить внимание.
Спасибо.