Здравствуйте, COFF, Вы писали:
COF>Хорошо, усложним задачу, предположим, что обработка ведется несколькими потоками, битмапы передаются из потока в поток во время обработки, тоже будете GC.Collect звать?
Конечно. Ты не поверишь — ему поровну, сколько там потоков.

Здравствуйте, Sinclair, Вы писали:

COF>>А каком сексе вы говорите уважаемый? секс это оба ваших решения, а в C++ все просто и прозрачно.
S>Я написал детали секса строчкой ниже. На С++ ничего прозрачного нету — просто есть "типа указатели" с семантикой владения. И есть все остальные указатели, которые приводят к undefined behavior в случае чего.
Не аргумент. Прочие указатели используются только в критических местах.

Здравствуйте, Sinclair, Вы писали:

COF>>Хорошо, усложним задачу, предположим, что обработка ведется несколькими потоками, битмапы передаются из потока в поток во время обработки, тоже будете GC.Collect звать?
S>Конечно. Ты не поверишь — ему поровну, сколько там потоков.

То есть, если я в конце любой функции буду писать GC.Collect — то это будет абсолютно нормально?

Здравствуйте, Sinclair, Вы писали:

NBN>>А если память нужна кому-то ещё?
S>Это то же самое. Когда память становится нужна кому-то еще, GC это замечает и начинает уборку.

Вот отсюда главные тормоза и растут.

Здравствуйте, March_rabbit, Вы писали:

M_>Здравствуйте, MxKazan, Вы писали:

MK>>Ведь аналога метаданных, понимаемых дебаггером, не будет.
M_>а что, дебаггер не люди пишут? И они не могут с компиляторописателями утрясти формат?
M_>Дебажную инфу вроде как утрясли.
Речь идет о сторонней библиотеке эмуляции пропертей, которые не поддерживаются компилятором.

Здравствуйте, NikeByNike, Вы писали:

NBN>Здравствуйте, Sinclair, Вы писали:

NBN>>>А если память нужна кому-то ещё?
S>>Это то же самое. Когда память становится нужна кому-то еще, GC это замечает и начинает уборку.

NBN>Вот отсюда главные тормоза и растут.

Доказательсва будут? или очередное голословное утверждение?

Здравствуйте, COFF, Вы писали:

COF>Здравствуйте, MxKazan, Вы писали:

COF>>>Я понимаю, что можно сказать, что много программ написано (и тобой в том числе) на C# где такие проблемы не возникают, соответственно это все не актуально. Но ведь на C++ написано еще больше программ безо всяких лямбд и свойств, так ведь?
MK>>Ты по-моему влез в спор, не удосужившись глянуть о чем он. Никто ведь не говорит, что свойства — абсолютная необходимость.

COF>Посмотрел начало ветки:
>>А некоторые языки (а именно С++) не имеют таких базовых понятий как: свойства, атрибуты, события, делегаты, лямбда-выражения, замыкания, duck typing, интерфейсы, covariance и contravariance, и много другого.
COF>Логично предположить, что свойства как базовые понятия таки необходимость.
Оууу. Понятно. Приношу извинения. Это скорее я начал читать не с того поста.

COF>Первый ответ:
>>свойства — синтезируется;

COF>Выяснили, что действительно синтезируется, не совсем так как в C#, но есть. Галочку можно поставить Особенно, если они не абсолютная необходимость. Но изначально-то вопрос стоял о том, что свойства — это базовое понятие, только потом был умело повернут на соответствие свойств в C++ и C#.
И повернул его тот самый ответ, что синтезируются И галочку поставить у меня лично рука не поднимется. Ведь синтезируют. Значит нужно, но нету

Здравствуйте, neFormal, Вы писали:

F>а в чём принципиальное преимущество шарпа в этом плане?. какое нибудь дополнительное указание мета-информации?.
Принципиальное — в лаконичности и типобезопасности. Читать про Linq. Аналоги на джаве либо многословны, либо не проверяются статически, либо и то и другое.

Здравствуйте, MxKazan, Вы писали:

MK>И повернул его тот самый ответ, что синтезируются ;) И галочку поставить у меня лично рука не поднимется. Ведь синтезируют. Значит нужно, но нету :)

Я думаю, что многие люди, перейдя скажем с дельфи (где свойства есть) на C++ пытаются перетащить привычную идиому с собой. Ну и игра ума еще, естественно.

Здравствуйте, COFF, Вы писали:
COF>То есть, если я в конце любой функции буду писать GC.Collect — то это будет абсолютно нормально?
Нет, не будет. Я уже писал — само желание срочно пособирать мусор появляется от неправильного подхода. Пытаясь улучшить производительность, ты ее ухудшишь.
А задурить коллектору голову количеством потоков всё равно не получится.

Здравствуйте, COFF, Вы писали:

COF>Здравствуйте, MxKazan, Вы писали:

COF>>>Предположим, что у меня есть некий ресурс, пусть битмап, есть произвольное количество векторов std::vector< boost::shared_ptr<bitmap> > которые содержат пересекающиеся множества битмапов. Например, я делаю какие-то сложные вычисления над графическими примитивами. Теперь, мне нужно очистить один из векторов, я делаю v.clear(), при этом все битмапы, на которые нет ссылок в других векторах тут же должны быть тут же освобождены, так как битмапов много и я не могу их держать в памяти произвольное время. Как это сделать на C#?
MK>>GC.Collect

COF>Хорошо, усложним задачу, предположим, что обработка ведется несколькими потоками, битмапы передаются из потока в поток во время обработки, тоже будете GC.Collect звать?

А чем это усложняет задачу?

Впрочем, звать сборщик обычно не требуется. Когда надо будет, он сам придет.

Здравствуйте, criosray, Вы писали:

C>Тем более, что в автобилд встроен fxcop, энфорсящий вызов Dispose для объектов, реализующих IDisposable.
вот это всем костылям костыль. так с языком чуть ли не что угодно сделать можно, не только проперти в плюсах приделать

Здравствуйте, MxKazan, Вы писали:

COF>>Выяснили, что действительно синтезируется, не совсем так как в C#, но есть. Галочку можно поставить Особенно, если они не абсолютная необходимость. Но изначально-то вопрос стоял о том, что свойства — это базовое понятие, только потом был умело повернут на соответствие свойств в C++ и C#.
MK>И повернул его тот самый ответ, что синтезируются И галочку поставить у меня лично рука не поднимется. Ведь синтезируют. Значит нужно, но нету

Да, возможно. Это обычный полемический приём — в ответ на вопрос "где штука X?" ответить "а на хрена она вообще сдалась? ну если очень хочется — на, забирай". С пропертями то же самое. Я не стал добавлять, что они хоть и синтезируются, но это происходит обычно ради развлечения или спору для. Но ради развлечения на C++ и Lisp синтезируют в терминах шаблонов. Это ещё не повод говорить, что C++ остро нуждается во встроенном Lisp. Хотя... Это ещё как посмотреть.

Забавно в этом обсуждении получилось то, что защитники "свойств" даже не сформулировали толком, что из себя означенные свойства должны представлять (это, кстати, обычный прокол любых "провозвестников" — прямая претензия на сакральность). Например, можно ли оперировать таким явлением, как "ссылка на свойство"? Может ли "свойство" выступать аргументом шаблона? Ну и так далее. Получилось как всегда — C++ плох тем, что это не C#.

Здравствуйте, Mamut, Вы писали:

M>Угу. Вспоминатся Qt, где подобное реализовано для событий. Приходится препроцессор отдельный прогонять. А как только где-то что-то навернется, ни один дебаггер не спасет

Угу, только в данном случае под PROPERTY скрывается тривиальное упрощение синтаксиса объявления инстанцированного шаблонного типа и соответствующей переменной-члена. Никаких вывертов. Я сам противник того, чтобы прятать под макросами какую-нибудь суровую магию. Лучше уж лишние пять строк написать, если что.

Здравствуйте, Sinclair, Вы писали:

S>Общепринятые костыли не становятся менее костыльными. См.напр. MFC.

MFC, кстати, вообще интересный феномен. Столько, сколько ругали MFC, наверное, не ругали ни одну другую библиотеку. А ей всё фиолетово — цветёт и пахнет.

S>Впрочем, по сравнению с джавой ORM для C++ будут вообще инвалидной коляской.

Спорный вопрос. Очень спорный. Я вообще подозреваю, что ORM — это какая-то большая ошибка природы. Но это пока только подозрения.

Здравствуйте, LaptevVV, Вы писали:

ГВ>>Блин, Валерий Викторыч, Intel C++ 11.0. И ещё сейчас MS выложила бету VS2010.
LVV>А, ну да... Я пока на 2008 сижу...

Я вообще по большей части на VS2K5. Но одно другому не мешает.

LVV>>>Видимо, множественное наследование ликвидировали из-за наличия озвученных проблем. И сочли за благо ввести отдельную конструкцию.
ГВ>>Каких проблем?
LVV>По этому поводу вспомнилось из его статьи: любая книжка по С++ описывает, как не надо делать при множественном наследовании. Я сам писал — тут он прав...

Мне такие заявления всегда кажутся излишне самонадеянными. Ну, сам знаешь, нет такой конструкции в языке программирования, которую нельзя было бы применить неправильно.

ГВ>>>>Дык — не надо ж. Он там в качестве контраргумента всё время рассуждает о непонятности внутреннего устройства буста.
LVV>>>Для него — действительно жуть... Меня тоже только крайняя нужда заставит буст использовать...
ГВ>>ИМХО, это зря.
LVV>Ну, кое-что подсматриваю и использую. Но небольшие вещи. Типа интеллектуальных указателей.

На самом деле, там много интересного. Мне сильно понравился boost::spirit — полезная штука для мелких парсеров. И наглядно записывается, и быстро работает. В подробности вдаваться не стал. Ну и по мелочи много всего. boost::bind, boost::function, само собой. Не пойму только, как обстоит дело с boost::channel — будет он когда-нибудь внесён в релиз, или нет.

LVV>>>Но вообще статья, конечно, оставляет впечатление, что писал достаточно опытный программер, которому ПРИШЛОСЬ перейти на С++ по необходимости.
LVV>>>А это — действительно УЖОСССССС!!!!!
ГВ>>Не знаю, у меня ощущение, что программер-то, может быть, и опытный, но очень сильно путает субъективное и объективное.
LVV>Объективно я осенью напишу. Вот сравню БлэкБокс с С++ на одних и тех же задачах — и напишу...

О-о-о! Это было бы интересно — я про одни и те же задачи.

LVV>А от субъективного восприятия никуда не деться.

Скажем так, в "плюс" автору можно поставить, что он в заголовке так и сказал: "...мне НЕ НРАВИТСЯ". Но это, по-моему, единственный "плюс". Дальше он стал изъясняться в стиле констатации имманентных проблем C++, а это уже с "не нравится" читателю довольно таки трудно увязывать.

LVV>Особенно программистам-непрофессионалам, которые используют программирование по необходимости только для решения своих задач. Им даже адекватный инструмент для решения подобрать сложно. Ведь не хочется изучать лишний инструменть, чтобы один-два раза решить задачу.

Честно говоря, из статьи следует нечто прямо противоположное — к чему тогда декларации о том, что он 15 лет работает на C++?

LVV>Вот раньше был фортран — на нем все и писали...

А... Да-да. Настоящие программисты работают в NASA и пишут на Фортране. И программы настоящих программистов исполняются в режиме супервизора. Я в курсе.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Забавно в этом обсуждении получилось то, что защитники "свойств" даже не сформулировали толком, что из себя означенные свойства должны представлять (это, кстати, обычный прокол любых "провозвестников" — прямая претензия на сакральность).

ГВ>Например, можно ли оперировать таким явлением, как "ссылка на свойство"?
Можно. См. PropertyInfo
ГВ>Может ли "свойство" выступать аргументом шаблона?
Нет. Поскольку свойство — это не тип. В С++, впрочем, метод тоже не может быть аргументом шаблона.
ГВ>Ну и так далее. Получилось как всегда — C++ плох тем, что это не C#.
Да нет, не тем. Тем, что многабукаф на ровном, тскать, месте.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>MFC, кстати, вообще интересный феномен. Столько, сколько ругали MFC, наверное, не ругали ни одну другую библиотеку. А ей всё фиолетово — цветёт и пахнет.
Так в том-то и дело, что цветёт. И даже (ой!) пахнет.

ГВ>Спорный вопрос. Очень спорный. Я вообще подозреваю, что ORM — это какая-то большая ошибка природы. Но это пока только подозрения.
Надеюсь, это не от того, что их в плюсах хрен поддержишь?

Между прочим, исторически первая ООDB до сих пор жива и работает на Smalltalk. Там как раз всё построено на фичах, аналогичных применямым в Linq. Безо всяких костылей. А вот Verant, к примеру, включал в себя отдельный компилятор метаданных, без натравления которого на С++ исходник ничерта не работало.

Так что С++ — это, в некотором смысле, не олдскул, а шаг назад по сравнению с олдскулом.

Фишка в том, что ORM, как таковые, в общем-то, не нужны. Что нужно — так это нормальный типизированный доступ к данным (lightweight-ORM) без геморроя.
Ну так вот даже такую малость, без change tracking, lazy loading, и identity map, на плюсах нормальным образом не вырулишь. Даже с помощью макросов. Всё время будет не хватать каких-то мелочей.

Здравствуйте, Eugeny__, Вы писали:

COF>>Хорошо, усложним задачу, предположим, что обработка ведется несколькими потоками, битмапы передаются из потока в поток во время обработки, тоже будете GC.Collect звать?

E__>А чем это усложняет задачу?

В том смысле, что если у нас крутятся параллельно несколько функций, то хорошо ли будет в каждой звать GC.Collect? Не приведет ли это к проблемам с производительностью, например?

E__>Впрочем, звать сборщик обычно не требуется. Когда надо будет, он сам придет. :)

Он придет, когда посчитает нужным, а не когда надо :) Кстати, раньше я помню была проблема с GC, когда сам объект маленький, но держит внешние ресурсы, то CG мог не вызваться за обозримое время. В контексте данной задачи, я ведь могу загрузить битмап как отображаемый файл, в этом случае в объекте будет лежать четыре байта. Сможет ли GC правильно понять эту ситуацию?

Здравствуйте, COFF, Вы писали:

COF>Здравствуйте, Eugeny__, Вы писали:

COF>>>Хорошо, усложним задачу, предположим, что обработка ведется несколькими потоками, битмапы передаются из потока в поток во время обработки, тоже будете GC.Collect звать?

E__>>А чем это усложняет задачу?

COF>В том смысле, что если у нас крутятся параллельно несколько функций, то хорошо ли будет в каждой звать GC.Collect? Не приведет ли это к проблемам с производительностью, например?
Можно после каждого оператора для верности вставить GC.Collect, тогда ормоза обеспечены.
На самом деле в программе можно определить место где какая-то часть тяжелой работы сделана, в этом месте можно вызвать GC.Collect. Просто так тыкать везде не стоит.

E__>>Впрочем, звать сборщик обычно не требуется. Когда надо будет, он сам придет.

COF>Он придет, когда посчитает нужным, а не когда надо
А когда надо?
COF>Кстати, раньше я помню была проблема с GC, когда сам объект маленький, но держит внешние ресурсы, то CG мог не вызваться за обозримое время. В контексте данной задачи, я ведь могу загрузить битмап как отображаемый файл, в этом случае в объекте будет лежать четыре байта. Сможет ли GC правильно понять эту ситуацию?
Не было никогда такой проблемы. Еще с первых версий можно подсказать GC сколько реально выделяется памяти.