хе, примерно о подобном тоже думал..
F>>единственное что — неэстетично выгдядит обёртка.. но с этим ещё можно подумать.. S>Ну так это и есть костыль — неэстетично выглядящая подробность реализации.
-1.. "костыльность" — это вопрос не эстетики, а общепринятости..
F>>по сути это что то схожее с property от микрософта.. S>Да-да, я в курсе про многообразные костыли.
так можно дойти до идеи, что не встроенный ORM — жуткий костыль..
Здравствуйте, COFF, Вы писали:
COF>Предположим, что у меня есть некий ресурс, пусть битмап, есть произвольное количество векторов std::vector< boost::shared_ptr<bitmap> > которые содержат пересекающиеся множества битмапов. Например, я делаю какие-то сложные вычисления над графическими примитивами. Теперь, мне нужно очистить один из векторов, я делаю v.clear(), при этом все битмапы, на которые нет ссылок в других векторах тут же должны быть тут же освобождены, так как битмапов много и я не могу их держать в памяти произвольное время. Как это сделать на C#?
GC.Collect();
GC.WaitForPendingFinalizers();
Все недоступные битмапы будут освобождены. Хотя ты явно преувеличиваешь про "не могу держать в памяти произвольное время" — пока память тебе реально не потребуется, повода паниковать нет.
Но, конечно же, если хочется такого же секса, как в С++, то можно сделать и вектора с подсчётом ссылок. Объем кода будет сравним с shared_ptr.
Секс — это в смысле возможность сохранить указатель на битмэп мимо вектора, и после освобождения получить InvalidOperationException.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, COFF, Вы писали:
COF>Здравствуйте, Sinclair, Вы писали:
S>>Там достаточно сделать опечатку типа int& в декларации проперти типа — и упс! Будешь потом неделю бороду чесать, разбираясь что куда девалось. F>>>по сути это что то схожее с property от микрософта.. S>>Да-да, я в курсе про многообразные костыли.
COF>По моему, свойства прекрасно заменяются get и set функциями, но если считается, что любая возможность которая есть в одном языке, но которой нет в другом языке однозначно свидетельствует о превосходстве первого над вторым, сколь ни натянутой и бесполезной эта возможность на самом деле является, то повторите на C# вот такое вот поведение.
Не гони а. Тут уже привели плюсы свойств против функций. Если тебе они не понятны, то это не значит, что всё это "натянуто и бесполезно". Вообще, "борцам за правду" не мешало бы признавать и недостатки.
COF>Предположим, что у меня есть некий ресурс, пусть битмап, есть произвольное количество векторов std::vector< boost::shared_ptr<bitmap> > которые содержат пересекающиеся множества битмапов. Например, я делаю какие-то сложные вычисления над графическими примитивами. Теперь, мне нужно очистить один из векторов, я делаю v.clear(), при этом все битмапы, на которые нет ссылок в других векторах тут же должны быть тут же освобождены, так как битмапов много и я не могу их держать в памяти произвольное время. Как это сделать на C#?
GC.Collect
Здравствуйте, Sinclair, Вы писали:
S>Все недоступные битмапы будут освобождены. Хотя ты явно преувеличиваешь про "не могу держать в памяти произвольное время" — пока память тебе реально не потребуется, повода паниковать нет.
Я так и думал, что единственным решением будет вызывать сборщик мусора на каждый чих, но вообще-то часто его вызывать это нехорошо, нет?
S>Но, конечно же, если хочется такого же секса, как в С++, то можно сделать и вектора с подсчётом ссылок. Объем кода будет сравним с shared_ptr.
А каком сексе вы говорите уважаемый? секс это оба ваших решения, а в C++ все просто и прозрачно.
S>Секс — это в смысле возможность сохранить указатель на битмэп мимо вектора, и после освобождения получить InvalidOperationException.
В общем, в очередной раз, если чего-то нет в C++ — это секс, а если чего-то нет в C# — это так и надо :)
Здравствуйте, neFormal, Вы писали: F>-1.. "костыльность" — это вопрос не эстетики, а общепринятости..
Общепринятые костыли не становятся менее костыльными. См.напр. MFC.
F>так можно дойти до идеи, что не встроенный ORM — жуткий костыль..
В правильную сторону мыслишь. Но дело не во встроенности, а именно в эстетике. К примеру, ни в С# 3.0, ни в Java 6 ORM не встроены.
Но при этом в шарп можно встроить офигительный ORM, а в джаве один хрен будут костыли.
Впрочем, по сравнению с джавой ORM для C++ будут вообще инвалидной коляской.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, MxKazan, Вы писали:
COF>>Предположим, что у меня есть некий ресурс, пусть битмап, есть произвольное количество векторов std::vector< boost::shared_ptr<bitmap> > которые содержат пересекающиеся множества битмапов. Например, я делаю какие-то сложные вычисления над графическими примитивами. Теперь, мне нужно очистить один из векторов, я делаю v.clear(), при этом все битмапы, на которые нет ссылок в других векторах тут же должны быть тут же освобождены, так как битмапов много и я не могу их держать в памяти произвольное время. Как это сделать на C#? MK>GC.Collect
Хорошо, усложним задачу, предположим, что обработка ведется несколькими потоками, битмапы передаются из потока в поток во время обработки, тоже будете GC.Collect звать?
Здравствуйте, COFF, Вы писали:
COF>Здравствуйте, Sinclair, Вы писали:
S>>Все недоступные битмапы будут освобождены. Хотя ты явно преувеличиваешь про "не могу держать в памяти произвольное время" — пока память тебе реально не потребуется, повода паниковать нет. COF>Я так и думал, что единственным решением будет вызывать сборщик мусора на каждый чих, но вообще-то часто его вызывать это нехорошо, нет?
На каждый чих? Это видать, что ни программа на C#, то сплошь воротилка произвольного числа векторов битмапов
Здравствуйте, MxKazan, Вы писали:
COF>>Я так и думал, что единственным решением будет вызывать сборщик мусора на каждый чих, но вообще-то часто его вызывать это нехорошо, нет? MK>На каждый чих? Это видать, что ни программа на C#, то сплошь воротилка произвольного числа векторов битмапов :)))
А почему нет? Для тебя вот важным является свойства чтоб были, а для меня — нет, зато для меня важно не думать когда GC.Collect звать и как это повлияет на всю остальную систему. Кому, как говорится, арбуз, а кому свиной хрящик :)
Здравствуйте, Sinclair, Вы писали:
S>Все недоступные битмапы будут освобождены. Хотя ты явно преувеличиваешь про "не могу держать в памяти произвольное время" — пока память тебе реально не потребуется, повода паниковать нет.
Здравствуйте, COFF, Вы писали:
COF>Хорошо, усложним задачу, предположим, что обработка ведется несколькими потоками, битмапы передаются из потока в поток во время обработки, тоже будете GC.Collect звать?
Ты знаешь, я честно говоря, не силен в вызове GC.Collect, т.к. не использую этого метода вообще. И в многопоточных приложениях в том числе.
Здравствуйте, MxKazan, Вы писали:
S>>>Все недоступные битмапы будут освобождены. Хотя ты явно преувеличиваешь про "не могу держать в памяти произвольное время" — пока память тебе реально не потребуется, повода паниковать нет. COF>>Я так и думал, что единственным решением будет вызывать сборщик мусора на каждый чих, но вообще-то часто его вызывать это нехорошо, нет? MK>На каждый чих? Это видать, что ни программа на C#, то сплошь воротилка произвольного числа векторов битмапов
Моя последняя именно такой и являлась Мне смешно становится, когда я представляю что было бы если бы я затеял её на шарпе
P.S.
Хотя конечно с удовольствием перешёл бы на шарп — если бы была такая техническая возможность. Но жизнь сурова и ради хорошей зп приходится мучиться
Здравствуйте, MxKazan, Вы писали:
MK>Здравствуйте, COFF, Вы писали:
COF>>Хорошо, усложним задачу, предположим, что обработка ведется несколькими потоками, битмапы передаются из потока в поток во время обработки, тоже будете GC.Collect звать? MK>Ты знаешь, я честно говоря, не силен в вызове GC.Collect, т.к. не использую этого метода вообще. И в многопоточных приложениях в том числе.
Но ты же сам его предложил? Теперь оказывается, что ты в нем не силен, зачем предлагал? ;) Я понимаю, что можно сказать, что много программ написано (и тобой в том числе) на C# где такие проблемы не возникают, соответственно это все не актуально. Но ведь на C++ написано еще больше программ безо всяких лямбд и свойств, так ведь?
Здравствуйте, COFF, Вы писали:
COF>Я так и думал, что единственным решением будет вызывать сборщик мусора на каждый чих, но вообще-то часто его вызывать это нехорошо, нет?
Ну конечно нехорошо. Как и поспешно дестроить объекты в условиях избытка памяти. Но это же ты попросил это сделать — я поверил тебе на слово, что тебе действительно нужно срочно отпустить битмэпы.
COF>А каком сексе вы говорите уважаемый? секс это оба ваших решения, а в C++ все просто и прозрачно.
Я написал детали секса строчкой ниже. На С++ ничего прозрачного нету — просто есть "типа указатели" с семантикой владения. И есть все остальные указатели, которые приводят к undefined behavior в случае чего.
Эмулировать требуемое задачей поведение на C# не слишком сложно — с точки зрения пользователя коллекций всё будет выглядеть практически так же. Ну, кроме того, что вместо UB будет таки InvalidOperationException.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Эмулировать требуемое задачей поведение на C# не слишком сложно — с точки зрения пользователя коллекций всё будет выглядеть практически так же. Ну, кроме того, что вместо UB будет таки InvalidOperationException.
Ну так и на C++ эмулировать свойства не слишком сложно, и с точки зрения пользователей все будет выглядеть практически так же с той же степенью достоверности, так в чем вопрос?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, neFormal, Вы писали: F>>-1.. "костыльность" — это вопрос не эстетики, а общепринятости.. S>Общепринятые костыли не становятся менее костыльными. См.напр. MFC.
не знаю, не успел её распробовать..
F>>так можно дойти до идеи, что не встроенный ORM — жуткий костыль.. S>В правильную сторону мыслишь. Но дело не во встроенности, а именно в эстетике. К примеру, ни в С# 3.0, ни в Java 6 ORM не встроены. S>Но при этом в шарп можно встроить офигительный ORM, а в джаве один хрен будут костыли.
а в чём принципиальное преимущество шарпа в этом плане?. какое нибудь дополнительное указание мета-информации?.
ГВ> class Test
ГВ> {
ГВ> public:
ГВ> PROPERTY(Test, int, a, get_a, set_a);
ГВ> PROPERTY(Test, int, b, get_b);
ГВ> protected:
ГВ> void set_a(int v){ ... }
ГВ> int get_a() const { ... }
ГВ> }
ГВ>
ГВ> F>>единственное что — неэстетично выгдядит обёртка.. но с этим ещё можно подумать..
Угу. Вспоминатся Qt, где подобное реализовано для событий. Приходится препроцессор отдельный прогонять. А как только где-то что-то навернется, ни один дебаггер не спасет
Здравствуйте, COFF, Вы писали:
COF>Но ты же сам его предложил? Теперь оказывается, что ты в нем не силен, зачем предлагал?
Затем что ты просил.
COF>Я понимаю, что можно сказать, что много программ написано (и тобой в том числе) на C# где такие проблемы не возникают, соответственно это все не актуально. Но ведь на C++ написано еще больше программ безо всяких лямбд и свойств, так ведь?
Ты по-моему влез в спор, не удосужившись глянуть о чем он. Никто ведь не говорит, что свойства — абсолютная необходимость. Где такое написано? Я не писал по крайней мере. Хотя на мой взгляд — это очень удобная фича во многих отношениях. И то, что порой методы в С++ маскируют под свойства только доказывает это. Однако, изначально спор пошел на тему, что эмуляция свойств на С++ не является полноценной и уступает C#. Есть что возразить на это?
Здравствуйте, MxKazan, Вы писали:
MK>Ведь аналога метаданных, понимаемых дебаггером, не будет.
а что, дебаггер не люди пишут? И они не могут с компиляторописателями утрясти формат?
Дебажную инфу вроде как утрясли.
Здравствуйте, MxKazan, Вы писали:
COF>>Я понимаю, что можно сказать, что много программ написано (и тобой в том числе) на C# где такие проблемы не возникают, соответственно это все не актуально. Но ведь на C++ написано еще больше программ безо всяких лямбд и свойств, так ведь? MK>Ты по-моему влез в спор, не удосужившись глянуть о чем он. Никто ведь не говорит, что свойства — абсолютная необходимость.
Посмотрел начало ветки: >А некоторые языки (а именно С++) не имеют таких базовых понятий как: свойства, атрибуты, события, делегаты, лямбда-выражения, замыкания, duck typing, интерфейсы, covariance и contravariance, и много другого.
Логично предположить, что свойства как базовые понятия таки необходимость.
Первый ответ: >свойства — синтезируется;
Выяснили, что действительно синтезируется, не совсем так как в C#, но есть. Галочку можно поставить :) Особенно, если они не абсолютная необходимость. Но изначально-то вопрос стоял о том, что свойства — это базовое понятие, только потом был умело повернут на соответствие свойств в C++ и C#.
Здравствуйте, NikeByNike, Вы писали: NBN>А если память нужна кому-то ещё?
Это то же самое. Когда память становится нужна кому-то еще, GC это замечает и начинает уборку.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Мне смешно становится, когда я представляю что было бы если бы я затеял её на шарпе 
