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

G>Не было никогда такой проблемы. Еще с первых версий можно подсказать GC сколько реально выделяется памяти.

Может быть, насчет этого не уверен.

Я вот чё-то не пойму...

Ну не нравится вам С++, ну так не пишите на нём,не читайте форумы,установите себе в почтовой программе фильтр на слово "С++", аналогично поступите в браузере и мессенджере...
И будет вам — спокойно.
Зачем лаять с видом знатока с 15и летним опытом (именно видом,так как некоторые тезисы очень напоминают одного местного фаната одной ОС с ником на букву S.)?

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

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

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

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

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


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

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

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

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

Не слышал про такое, но если и было, то это просто баг реализации конкретного сборщика, а баги имеют тенденцию к исправлению в следующих версиях.

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

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

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

B>Я вот чё-то не пойму...

B>Ну не нравится вам С++, ну так не пишите на нём,не читайте форумы,установите себе в почтовой программе фильтр на слово "С++", аналогично поступите в браузере и мессенджере...
B>И будет вам — спокойно.
B>Зачем лаять с видом знатока с 15и летним опытом (именно видом,так как некоторые тезисы очень напоминают одного местного фаната одной ОС с ником на букву S.)?
B>
Мы ж в КСВ!!!

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

S>Нет. Поскольку свойство — это не тип. В С++, впрочем, метод тоже не может быть аргументом шаблона.

А почему свойство — это не тип? И Вы ошибаетесь — в С++ метод может быть параметром шаблона:

template<typename T, void (T::*m)()>
struct zz
{
    zz()
    {
        T t;
        (t.*m)();
    }
};

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

ГВ>>Например, можно ли оперировать таким явлением, как "ссылка на свойство"?
S>Можно. См. PropertyInfo

А без PropertyInfo никак? Это, в общем-то, прослойка из метаданных получается.

ГВ>>Может ли "свойство" выступать аргументом шаблона?
S>Нет. Поскольку свойство — это не тип.

Понятно.

S>В С++, впрочем, метод тоже не может быть аргументом шаблона.

Может:

template<typename T, void (T::*M)()> class Foo { ... };

class Bar { public: void bar(){ ... } }

Foo<Bar, &Bar::bar> foo;

ГВ>>Ну и так далее. Получилось как всегда — C++ плох тем, что это не C#.
S>Да нет, не тем. Тем, что многабукаф на ровном, тскать, месте.

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

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

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

не покажешь аналог FxCop для C++, сравнимого качества, бесплатный и расширяемый?

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

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

Нет, конечно (skip флейм "хрен поддержишь"). Скорее от того, что модель реляционных данных и "объектная модель" — совсем не одно и то же. Например, объектная модель много сильнее подвержена изменениям, в отличие от модели данных — тут и соображения оптимальности, и иной раз недопустимость реструктуризации БД. Короче говоря, эти две модели живут в разных контекстах требований, и апеллировать непременно к "отображению" тут несколько некорректно.

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

OODB тут вообще к делу не относятся. Это своя ветка развития баз данных.

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

S>Фишка в том, что ORM, как таковые, в общем-то, не нужны. Что нужно — так это нормальный типизированный доступ к данным (lightweight-ORM) без геморроя.

Мда, что-то в этом роде. Хотя тяжелое отображение (по сути — эмуляция персистентных объектов) тоже иной раз имеет смысл.

S>Ну так вот даже такую малость, без change tracking, lazy loading, и identity map, на плюсах нормальным образом не вырулишь. Даже с помощью макросов. Всё время будет не хватать каких-то мелочей.

Не совсем тебя понял — ты имеешь в виду, что на плюсах непременно нужны change tracking, lazy loading и identity map, или что даже самый минимум без этих фич, на плюсах не сделаешь?

Здравствуйте, Eugeny__, Вы писали:
E__>Не слышал про такое, но если и было, то это просто баг реализации конкретного сборщика, а баги имеют тенденцию к исправлению в следующих версиях.
Это не баг. Это суровая правда жизни. В некоторых случаях неверна даже она: к примеру, если реально кому-то надо захватить неуправляемый ресурс, а в пуле их больше нет (залочены управляемыми обертками), то он встанет на ожидании освобождения; рано или поздно все потоки встанут, и останется только GC+finalizer thread, который наконец разблокирует заблокированное. Но это — очень некоторые случаи. В более частых такая стратегия просто приведет к тому, что все начнут быстро-быстро получать ошибки обращения, а GC будет думать, что так и должно быть.

Впрочем, "более частые" случаи всё еще очень-очень редки по сравнению с частотой случаев, в которых инстинктивно применяемый using() спасает всё.

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

MX>А почему свойство — это не тип?

А почему поле класса — это не тип ?

MX>И Вы ошибаетесь — в С++ метод может быть параметром шаблона:

Ну какой же это метод ??? Это обычный указатель на член класса (pointer to member), со всеми своими дежурными тараканами.

Здравствуйте, Ночной Смотрящий, Вы писали:

ГВ>>Отлично. Расширь моё сознание альтернативными примерами.
НС>А смысл? Вон рядом тебе примеров привели даже для С++.

Ткни в урл.

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

MX>>А почему свойство — это не тип?
D>А почему поле класса — это не тип ?

Как раз таки — тип.

MX>>И Вы ошибаетесь — в С++ метод может быть параметром шаблона:
D>Ну какой же это метод ??? Это обычный указатель на член класса (pointer to member), со всеми своими дежурными тараканами.

Where is a difference?

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

D>Здравствуйте, -MyXa-, Вы писали:

MX>>А почему свойство — это не тип?

D>А почему поле класса — это не тип ?

Конечно не тип, ни то ни это. Я имел в виду вот что:

struct bar
{
    int f;
};

typeid(&bar::f) != typeid(int)

MX>>И Вы ошибаетесь — в С++ метод может быть параметром шаблона:

D>Ну какой же это метод ??? Это обычный указатель на член класса (pointer to member), со всеми своими дежурными тараканами.

Интересно послушать про тараканов.
И, если знаете, про то, почему не-типы нельзя в generic-и по-чём зря совать.

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

B>Я вот чё-то не пойму...

B>Ну не нравится вам С++, ну так не пишите на нём,не читайте форумы,установите себе в почтовой программе фильтр на слово "С++", аналогично поступите в браузере и мессенджере...
B>И будет вам — спокойно.
B>Зачем лаять с видом знатока с 15и летним опытом (именно видом,так как некоторые тезисы очень напоминают одного местного фаната одной ОС с ником на букву S.)?
B>

Лучше поставить автозамену "С++" на "Цэ два плюса и куча минусов".

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

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

Явно вызывать GC.Collect — моветон.

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

ГВ>Нет, конечно (skip флейм "хрен поддержишь"). Скорее от того, что модель реляционных данных и "объектная модель" — совсем не одно и то же. Например, объектная модель много сильнее подвержена изменениям, в отличие от модели данных — тут и соображения оптимальности, и иной раз недопустимость реструктуризации БД. Короче говоря, эти две модели живут в разных контекстах требований, и апеллировать непременно к "отображению" тут несколько некорректно.
А, ну про это я сразу соглашусь. Без флейма.

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

ГВ>OODB тут вообще к делу не относятся. Это своя ветка развития баз данных.
Ну, не то чтобы. В принципе, на Старшей Речи и Linq нарулить — невелика проблема. Там весь код — одно сплошное Expression Tree.

ГВ>Мда, что-то в этом роде. Хотя тяжелое отображение (по сути — эмуляция персистентных объектов) тоже иной раз имеет смысл.
Имеет, но редко и недаром.

ГВ>Не совсем тебя понял — ты имеешь в виду, что на плюсах непременно нужны change tracking, lazy loading и identity map, или что даже самый минимум без этих фич, на плюсах не сделаешь?
Второе. Если в новом 0x не сделают expression trees, то всё это будет практически невозможно.

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

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

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

Хотя б WTL развивали... а не эту ошибку природы...

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


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

Какой еще костыль? Вы хоть поняли какую глупость сморозили? Сходите чтоли почитайте.. http://msdn.microsoft.com/en-us/library/bb429476.aspx
..и не пишите больше таких глупостей.