Здравствуйте !
Допустим у нас есть такая функция:

Чем полох такой подход и как его можно подправить ?
P.S.
Использовать всякие "прибамбасы" (искуственные обертки) не хочу, т.к.
мне не нравиться навязывание ООП в каждом простейшем случае 
P.P.S.
 Дважды писать free(pTmp) (для исключения и его отсутствия) - некузяво,
 ибо вместо free(pTmp) может быть много кода.

всем
1. __finally -  нет такого в С++, а значит нет гарантии, что это работает нормально.
2. Зачем try если исключение никто не ловит, где catch?

а придется, или же Вам лучше не писать на С++, потому что без ООП  С++ не нужен.
кстати, чем мотивирован выбор malloc\free?

ни __try ни  __finally в языке С++ нет, а есть try catch...

а для управления памятью лучше использовать идиому RAII

vinter, 
Lazin, 
 Уважаемая Riply забыла видимо сказать, что речь идет о managed с++, где __finally есть
http://msdn.microsoft.com/en-us/library/df24ysb6(VS.71).aspx

ЗЫ __finally возможно есть и в нативных компиляторах реализующих SEH

Содержательный ответ. Главное: всеобъемлющий 



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


try нужен для освобождения памяти в любом случае, что бы не случилось в DoAnyThing()

catch в данном примере мне не нужен



Тем, что я хочу научиться с ними правильно работать.
На мой взгляд, это очень веская мотивация 

Добавлено через 8 минут и 23 секунды


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

плохо... 
__try __finaly не работает с типизироваными исключениями, оно может и сработает, но тип исключения ты уже не определишь...
память в С++ выделяют с помощью new, так как malloc не вызывает конструкторы объектов...
а аналог твоего кода на С++ был бы немного короче... =)

Добавлено через 2 минуты и 45 секунд
 

Добавлено через 7 минут и 21 секунду

это нестандартное расширение компилятора vs, оно используется для обработки SEH исключений...

Плохо в смысле "иж чего захотела" ? 



Веский аргумент



Да я вообщем то и не собиралась использовать malloc везде, где только можно 


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

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

"Не смею с Вами спорить" (с)  

Везде, где это возможно я и использую преимущества языка высокого уровня.
Но бывают ситуации (хоть и не часто), когда надо покомандовать и самой.
Именно из-за них я и создала эту тему.
Хочу понять как надо работать в таких случаях.


Раз уж взялись, то придется не забыть 

командовать парадом по прежнему возможно, вектор можно передавать в winapi функции, SEH можно преобразовывать в обычные, типизированые исключения... можно делать все что угодно, оставаясь в рамках С++  

Значит мне надо еще учиться, учиться и учиться (как завещал...)   
ибо пока мне мешает, например, отсутствие finally,
хотя я и не сумела составить пример, где эта конструкция работает некорректно.

Про структурную обработку сообщений подробно написано в книге Джеффри Рихтер
а "Создание эффективных WIN32-приложений
с учетом специфики 64-разрядной версии Windows", главы 23-25.

Зависит от того где приложение выполняется. Если это сервер, то __try вообще нельзя использовать. Серверное Си приложение должно падать быстро в случае ошибки.
Используй RAII и не морочь мозги, а если не хочешь то используй гемморой связанный с отсутствием удобных ООП прибамбасов. Главное что-бы твоя программа в случае критической ошибки не полезла в важные данные и не изменила их ненароком.

тыц


ты можешь в любой момент удалить smart_pointer сама, если пожелаешь. 

Я не знаю, чем отличается "Серверное Си приложение"  от серверного приложеня.   
Если ничем, то пожалуйста "ссылку в студию" что  "__try вообще нельзя использовать"

 


Sorry, если я "заморочила Вам мозги" - не ожидала, что это так легко сделать. 



Вы невнимательно читали мои посты.
Например, я писала:

А за примером такой ситуации далеко ходить не надо:
Как прикажите работать с RtlCreateUnicodeString ?
Или при автоматическом удалении структуры UNICODE_STRING компилятор сам догадается, 
что для буфера необходимо вызвать RtlFreeUnicodeString или, на худой конец RtlFreeHeap,
через которую она работает ?
Я не вижу другого способа, кроме как обрабатывать данные ситуации вручную.
(Надеюсь мне не дадут совет "подправлять" системные структуры а заодно и корректировать работу API   )


Не поняла какое отношение имеет порча важных данных к обсуждаемой теме.
Можно попдробнее ?


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

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


(с) 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, отвечает на некоторые вопросы, которым Рихтер не счел нужным уделить внимание.
Спасибо.