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

Предлагаю существующий класс переименовать в DataRowAutoDelete. Произвести глобальную замену во всех классах (кроме классов табличного поля) имени CDataRow на DataRowAutoDelete. Например, при помощи Visual Assist. Потом создать НОВЫЙ класс CDataRow с чисто виртуальными AddRef и Release. Этот новый класс сделать базовым для DataRowAutoDelete. Таким образом в классах ТП будет задействоваться CDataRow, а во всех "внешних" для ТП классах будет DataRowAutoDelete. В результате, существующий код не изменится, а в ТП можно будет использовать строки, самостоятельно управляющими временем своей жизни. Да и вообще оопышнее оно как-то будет.

kms писал(а) 10. Мая 2008 :: 14:42:

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

PS. Ага, значит, сейчас против наследования реализации ты ничего не имеешь...

kms писал(а) 10. Мая 2008 :: 14:54:

Уже есть готовый провайдер для ТП, который осталось слегка переделать.

Я не понял, а что информация о возможных модулях как-то отменит кривизну интерфейса?

kms писал(а) 10. Мая 2008 :: 15:35:

Если хошь, я и сам могу замену из первого поста сделать.

kms писал(а) 10. Мая 2008 :: 15:39:

А в ТП для этого переделывать много, наверное, придется? Я просто подумал, что эти небольшие правки сделать можно быстро и код они не поломают. А если садиться и вдумчиво все переделывать под смартпойнтеры, то долго выйдет

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