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

LVV>>>Это говорит только о том, что в языке их не хватает.
ГВ>>Ну вот, теперь твоя очередь. ИМХО, если фича синтезируется, то и рассуждать не о чем.
LVV>Не... Есть... Синтезируется — это не стандарт определения языка, а реализация конкретного разработчика интегрированной среды...
LVV>При переходе со среды на среду — придется разбираться, как там эти фичи синтезированы.

Ну, знаешь, если так рассуждать, то при переходе от проекта к проекту тоже нужно много в чём разбираться.

LVV>Ну так еще и нет жиж...

Блин, Валерий Викторыч, Intel C++ 11.0. И ещё сейчас MS выложила бету VS2010.

ГВ>>>>интерфейсы — полностью выражается средствами pure virtual;
LVV>>>Нормально. Но почему-то в других языках сочли необходимым такую конструкцию явно определить
ГВ>>Видимо, из-за отсутствия множественного наследования.
LVV>Видимо, множественное наследование ликвидировали из-за наличия озвученных проблем. И сочли за благо ввести отдельную конструкцию.

Каких проблем?

ГВ>>Дык — не надо ж. Он там в качестве контраргумента всё время рассуждает о непонятности внутреннего устройства буста.
LVV>Для него — действительно жуть... Меня тоже только крайняя нужда заставит буст использовать...

ИМХО, это зря.

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

Не знаю, у меня ощущение, что программер-то, может быть, и опытный, но очень сильно путает субъективное и объективное.

MX> M>Объект с циклическими ссылками и членами — указателями на другие объекты.

MX> libs\serialization\test\test_cyclic_ptrs.cpp

MX> M>Плюс является наследником другого объекта так, чтобы не надо было явно указывать:
MX> M>

MX> M>ar & boost::serialization::base_object<bus_stop>(*this) & name;
MX> M>

MX> Думаю, что от этого можно избавиться.

Можно быо бы, в boost:serialize избавились бы

MX> Библиотека знает обо всех типах — могла бы сложить их в список типов, а при сериализации — найти все базы данного типа. Не думаю, что бывают случаи, когда (де)сериализовать наследника надо, на базу — нет. Хотя, с другой стороны, базЫ можно ситать такими же полямИ, и библиотека сама никак не может догадаться — сериализовать ли базу, или нет (если данная база не сериализуется, то понятно, что не надо, а если сериализуется?)

Все она может догадаться. Не в С++, естественно

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

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

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

E>>

ГВ>>>>>>covariance/contravariance — где именно их нет (ковариантные возвращаемые значения есть)?
C>>>>>Нигде их нет.
ГВ>>>>А в документации есть. Дока врёт?
C>>>Ссылку на соответствующий раздел документации в студию.

E>>ISO/IEC 14882, пункт 10.3.5

C>Нету contravariance. Нету.


C>

C>The return type of an overriding function shall be either identical to the return type of the overridden func-
C>tion or covariant with the classes of the functions.

Это как, простите?

class A {
};

class B: public A {
};


class C {
public:
    virtual A * func();
};


class D: public C {
public:
    virtual B * func();
};

Вот это то что есть. А Вы ещё хотели бы, чтобы C::func возвращала B, а D::func возвращала A. Разве это не бред?

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


C>>Нету contravariance. Нету.

C>>

C>>The return type of an overriding function shall be either identical to the return type of the overridden func-
C>>tion or covariant with the classes of the functions.

E>Это как, простите?

http://hestia.typepad.com/flatlander/2008/12/c-covariance-and-contravariance-by-example.html

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

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


C>>>Нету contravariance. Нету.

C>>>

C>>>The return type of an overriding function shall be either identical to the return type of the overridden func-
C>>>tion or covariant with the classes of the functions.

E>>Это как, простите?

C>http://hestia.typepad.com/flatlander/2008/12/c-covariance-and-contravariance-by-example.html

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

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

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

C>>В статье почти все правда. Просто преподнесена она так, чтоб сильно задеть программистов С++ и местами немного искажена.

MX>Почти всё? Примеры?

C>>Отлично. Напишите универсальный сериализатор в XML/Json.

MX>Жду списка недостатков следующих библиотек:

MX>TinyJSON
MX>jsoncpp
MX>zoolib
MX>Jaula
MX>JOST
MX>JSON Spirit
MX>CAJUN

Это все просто парсеры. Сериализатор это не парсер (точнее парсинг конечно же является элементов десериализации).
Сериализация это способ автоматически преобразовать граф объектов в текстовое в данном случае — JSON представление.
Иными словами:

var myComplexObjectGraph1 = IoC.Get<ComplexObjGraph>();

var jsonString = JsonHelper.Serialize(myComplexObjectGraph1);

...

var myComplexObjectGraph2 = JsonHelper.Deserialize<ComplexObjGraph>(jsonString);

Debug.Assert( myComplexObjectGraph1 == myComplexObjectGraph2);

MX>>>2) "Много ли Вы знаете простых и удобных persistence-библиотек". Ды, уж знаем, несколько.

C>>Простых? Удобных?
C>>"Огласите весь список пжалуста!"

MX>"Всего даже я не знаю". Я пользовлся Boost.Serialization, SF из RCF и одной собственного изготовления.
MX>А по поводу простоты, расскажите нам на пальцах — как в Яве не сериализовать какое-нубудь поле в сериализуемом классе? И ещё хотелось бы про версионизацию тоже узнать.

Повторяю еще раз. "Persistance библиотека" это в первую очередь различные O/RM: nHibernate, LightSpeed, EntityFramework, и т.д.

Список аналогов на С++ в студию.

MX>>>8) "А как же исключения (exceptions), а как же RTII ?. За них то я всегда плачу всегда !!!". Караул! Заявляю — RTII в С++ никогда не было,
C>>RTTI, а не RTII в С++ было, есть и будет.
MX>У аффтара — RTII. Вообще, у него в тексте вагон опечаток. У него, наверное, ко всему такой подход.
MX>>>и не предвидится следующие лет 10 точно.
C>>Какой кошмар...
MX>Зато — правда.
Только в Ваших фантазиях.

http://en.wikipedia.org/wiki/Run-time_type_information

MX>>>9) "будет изменена лишь копия объекта, которая сразу же после этого будет разрушена. Здорово, а ?". А некоторые языки, например, не позвляют выразить тот факт, что переданный в метод объект не будет изменён методом, которые принимает этот объект в качестве параметра.

MX>А на это есть что ответить?

public void Foo(Object obj) 
{
   obj = obj.MemberwiseClone();
   ...
}

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

MX>Вы считает это _базовыми_ понятиями? Очень интересно. А Вы знаете, что даже цикл — не базовое понятие?
Базовое.
MX>свойств в языке нет, но это не значит, что нельзя написать window.visible = true, чтобы лучше разглядеть окно.
Замечательно. Только после window.visible = true Вам придется написать еще window.refresh()
А как на счет проверки корректности ввода? А read-only свойства?
В итоге придете getVisible(), setVisible().
Очень удобно и выразительно... ничего не скажешь.
MX>события, делегаты? они в каком-то есть языке? круто. а мы, опять-таки — библиотеками обходимся.
И мне Вас очень жаль.
MX>лямбда-выражения, замыкания? в старом стандерте-таки да — нет. Но это не мешает нам написать std::for_each(c.begin(), c.end(), std::cout << _1 * _1 << std::endl);

Зато мешает Вам писать так:

var employees = db.Employees.Single(e => e.id == id);

и так:

foreach(var mult in arrNumbers.Where(n => n % Convert.ToInt16(strNum) == 0))

и так:

double Sqrt(double x)
{
    Func<double, bool> Good_Enough = (guess) => 
        Math.Abs(Square(guess) - x) < 0.001;
    Func<double, double> Improve = (guess) =>
        Average(guess, x / guess);
    Func<double, double> Iter = null;
    Iter = (guess) =>
        {
            if (Good_Enough(guess))
                return guess;
            else
                return Sqrt(Improve(guess));
        };
    return Iter(1.0);
}

MX>duck typing? покажите пример на Яве, скажу спасибо. А template в С++ — это не оно? Точно? А почему?
Ява тут при чем?

import System.Threading

def CreateInstance(progid):
   type = System.Type.GetTypeFromProgID(progid)    
   return type()    

ie as duck = CreateInstance("InternetExplorer.Application")
ie.Visible = true
ie.Navigate2("http://www.go-mono.com/monologue/")

Thread.Sleep(50ms) while ie.Busy

document = ie.Document
print("${document.title} is ${document.fileSize} bytes long.")

MX>интерфейсы? тоже отсутствуют. Покажите пример кода на С++, который будет красивее, будь в нём интерфейсы.
MX>covariance и contravariance?
MX>

MX>This variance refers to the parameters and return types of an overridden method in a descendant class. C++ supports this for covariance of return types. Return types and out parameters may be covariant, input parameters may be contravariant, and in-out parameters must be invariant. C++ example: ...

MX>и дальше
Замечательно. А теперь прочитайте ссылку, которую я привел раньше и попробуйте привести пример generic (co)contravariance на С++.


MX>>>После слов "Это конечно здорово, но вот как узнать является ли этот тип каким-либо из элементарных типов, указателем или ссылкой ? Является ли он const или нет ?" этого профана сил осиливать его поток у меня не осталось.
C>>Он правду сказал, а Вы классически "съехали на оскорбления", не могучи аргументированно ответить.

MX>Таки-да, отвечать на весь текст мне не захотелось. Если-б у него было достаточно ума, чтобы обсуждать дефекты стандарта С++ — другое дело. "аргументированно ответить", говорите? Среди моих ответов нет таких — "О, ужас.". А про "как узнать является ли этот тип каким-либо из элементарных типов, указателем или ссылкой ? Является ли он const или нет ?" я ответил выше.

Ваши ответы все в духе "о, ужас", так как Вы банально не знаете возможностей других языков.

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

ГВ>>>>Поиск тебе в помощь.
C>>>Открываем стандарт С++, смотрим, не находим, извиняемся?
ГВ>>Нет, в смысле — в гугль. Слова C++ и property.
C>Еще раз для тех, кто читать не умеет: открываем стандарт С++, смотрим, не находим, извиняемся.

Я потому тебя в гугль и отправил, чтоб ты почитал дискуссии по поводу пропертей для C++. Очень неоднозначно всё получается. Это с одной стороны. А с другой — не так уж и плоха жизнь без оных пропертей, хотя я понимаю — если в язык не затащено всё, что на сегодня считается "базовой вещью" — это плохой язык.

ГВ>>>>>>атрибуты (в смысле сопоставляемых метаданных) — синтезируется;
C>>>>>Нет.
ГВ>>>>Как так? Неужто нельзя приклеить к объекту никаких данных? Ни указателем, ни базовым классом?
C>>>Это не атрибуты. Почитайте чтоли что такое атрибуты.

ГВ>>Нет, ну в смысле взаимодействия с компилятором — да, такого нет. А вообще сопоставить данные с классом совсем не сложно.
C>Ну сопоставте, чтоб так же выразительно, несложно, и функционально, как в моем примере, который Вы явно проигнорировали.

В примере — использование AOP и неявно должен быть задействован Emit и ещё куча всего. Самих атрибутов там — только сопоставление AOP-вызовов. Ты хочешь, чтобы я AOP-фреймворк слабал по-быстрому?

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

ГВ>>>>Этому топику

Автор: Геннадий Васильев
Дата: 28.08.02

больше шести лет.
C>>>Это костыли, пытающиеся их эмулировать. В языке их НЕТ.
ГВ>>О-о-о... Это повод для большого флейма — какими должны быть делегаты.
C>Какого флейма? Они либо есть, либо их нет. В С++ их нет. О чем тут флеймить? Аналогично linq, lambda, events, attributes, properties, implicit typing, duck typing и многое другое.

Что-то больно много базовых вещей появляется, не находишь? Уже и linq в качестве базовых замаячил. Интересно, что дальше будет? Ладно, не суть. Суть в том, что делегаты прекрасно заменяются лямбдами, а евенты — лямбда + vector.

C>>>Не уже есть, а будет тогда, когда будет выпущен релиз компилятора языка С++0x.
C>>>И повторяю С++0x != C++, о котором речь.
ГВ>>Я тебе скажу больше MSVC6 != MSVC2K5, MSVC2K5 != MSVC2K10 и т.п. Что теперь, ругаться на C++, оперируя глюками MSVC6? И кроме того, внимательно смотрим на дату сообщения.
C>Замечательно. "Все смешалось в доме Облонских". Вы разницу между языком программирования и средой разработки не видите совсем?

Ах, ну да, я ж совсем забыл, что это для C++-ников MSVC6 — нарицательное. На самом деле, это очень неплохая среда с очень поганым C++, реализованным тогдашним компилятором MS C++. кстати, именно этим компилятором спровоцировано высказывание автора статьи о 255 символах в идентификаторе.

ГВ>>>>>>duck typing — статический (и это очень хорошо);
C>>>>>Может Вы для начала узнаете для себя что такое утятина?
ГВ>>>>Раньше предлагали устрицы. Снижается классность, снижается.
C>>>Ликбез: утятина не может быть статической. По определению. Не пишите больше таких глупостей, ок?
ГВ>>Что-то ничего не понимаю

Автор: VladD2
Дата: 25.05.09

.
C>Да я заметил, что Вы ничего не понимаете. Даже не пытаетесь. Пишете всякую, извините, билеберду. Хотя б в вики заглянули, чтоб хоть какое-то представление иметь...

Дык, вот смотри, VladD2 говорит, что шаблоны — утиная типизация, а ты говоришь — что в C++ нет утиной типизации. Википедия воплощает собой примерно такой же конгломерат мнений. Ты считаешь, что имеет смысл к ней апеллировать?

ГВ>>>>>>covariance/contravariance — где именно их нет (ковариантные возвращаемые значения есть)?
C>>>>>Нигде их нет.
ГВ>>>>А в документации есть. Дока врёт?
C>>>Ссылку на соответствующий раздел документации в студию.
ГВ>>ISO/ANSI 14882:1998, Раздел 10.3.5.
C>Нету там contravariance.

Contravariance — нет. Надо же, какой чудовищный недостаток!

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

MX>>Вы считает это _базовыми_ понятиями? Очень интересно. А Вы знаете, что даже цикл — не базовое понятие?
C>Базовое.

Феерично!!!

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

MX>>свойств в языке нет, но это не значит, что нельзя написать window.visible = true, чтобы лучше разглядеть окно.
C>Замечательно. Только после window.visible = true Вам придется написать еще window.refresh()
C>А как на счет проверки корректности ввода? А read-only свойства?
C>В итоге придете getVisible(), setVisible().

Ты, оказывается, действительно не в курсе. Я не даром тебя в гугль отправил. Точно такой же синтаксис можно получить на C++: с неявным вызовом setVisible() в ответ на window.visible = true, с вызовом getVisible() в ответ на bool v = window.visible, и с read-only (то есть — const) в комплекте.

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

MX>>>свойств в языке нет, но это не значит, что нельзя написать window.visible = true, чтобы лучше разглядеть окно.
C>>Замечательно. Только после window.visible = true Вам придется написать еще window.refresh()
C>>А как на счет проверки корректности ввода? А read-only свойства?
C>>В итоге придете getVisible(), setVisible().

ГВ>Ты, оказывается, действительно не в курсе. Я не даром тебя в гугль отправил. Точно такой же синтаксис можно получить на C++: с неявным вызовом setVisible() в ответ на window.visible = true, с вызовом getVisible() в ответ на bool v = window.visible, и с read-only (то есть — const) в комплекте.

Замечательно. Пример на С++ со свойствами в студию. Естественное условие — код должен компиллироваться во всех современных С++ компиляторах.

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

C>Замечательно. Пример на С++ со свойствами в студию. Естественное условие — код должен компиллироваться во всех современных С++ компиляторах.

Тебя гугль забанил? Первая ссылка по запросу "C++ property implementation": http://www.codeproject.com/KB/cpp/cpp_property_indexer.aspx

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

C>>Замечательно. Пример на С++ со свойствами в студию. Естественное условие — код должен компиллироваться во всех современных С++ компиляторах.

ГВ>Тебя гугль забанил? Первая ссылка по запросу "C++ property implementation": http://www.codeproject.com/KB/cpp/cpp_property_indexer.aspx

Это не свойства. Это костыль, который пытается их эмулировать. В языке С++ нету свойств. тчк

ГВ> C>Еще раз для тех, кто читать не умеет: открываем стандарт С++, смотрим, не находим, извиняемся.

ГВ> Я потому тебя в гугль и отправил, чтоб ты почитал дискуссии по поводу пропертей для C++. Очень неоднозначно всё получается. Это с одной стороны. А с другой — не так уж и плоха жизнь без оных пропертей, хотя я понимаю — если в язык не затащено всё, что на сегодня считается "базовой вещью" — это плохой язык.


Дело не в том, что считается базовой вещбю, а что — нет. Дело в том, что с теми же properties можно сразу использовать их из коробки, рыть гугл в поисках их замены, или писать boilerplate code каждый раз, сли их нет. Препочту первое. И так — со многим

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

C>>>Замечательно. Пример на С++ со свойствами в студию. Естественное условие — код должен компиллироваться во всех современных С++ компиляторах.
вот тут осторожней ведь в ответ могут поставить условие чтобы твой код на C# c linq компилировался хотя бы тремя современными С# компиляторами хотя бы на трех архитектурно разных платформах

ГВ>>Тебя гугль забанил? Первая ссылка по запросу "C++ property implementation": http://www.codeproject.com/KB/cpp/cpp_property_indexer.aspx

C>Это не свойства. Это костыль, который пытается их эмулировать. В языке С++ нету свойств. тчк
а собственно, и что с того? в чем разница между "нарисовать костыль с operator= " и определить set/get?

насколько принципиально тащить в язык всё то, что можно вынести в библиотеку? (или C# настолько убог, что не позволяет все перечисленные тобой ранее фичи вынести в библиотеку? )

ну если о костылях, так C# — костыль к IL, который костыль к machine code, который костыль к cpu uops, который... ну короче продолжите сами
в C++ в настоящий момент в большинстве реализаций цепочка костылей на один (IL) меньше, так что добавив эмуляцию пропертей и всего остального не запиханного в непосредственно язык, мы только уровняем ситуацию

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

C>>>>Замечательно. Пример на С++ со свойствами в студию. Естественное условие — код должен компиллироваться во всех современных С++ компиляторах.
A>вот тут осторожней ведь в ответ могут поставить условие чтобы твой код на C# c linq компилировался хотя бы тремя современными С# компиляторами хотя бы на трех архитектурно разных платформах

LINQ — стандартная языковая фича. В отличие от microsoft specific properties.

ГВ>>>Тебя гугль забанил? Первая ссылка по запросу "C++ property implementation": http://www.codeproject.com/KB/cpp/cpp_property_indexer.aspx

C>>Это не свойства. Это костыль, который пытается их эмулировать. В языке С++ нету свойств. тчк
A>а собственно, и что с того? в чем разница между "нарисовать костыль с operator= " и определить set/get?

В чем разница между стандартным решением и ужасным костылем?

class Test
{
    // outside the scope of class Test, 
    // set and get are both public
    typedef ::Property<    
        ::Test, 
        ::Number_Accessor<::Test>, 
        ::Number_Accessor<::Test>::value_type> Property_Number;

    // outside the scope of class Test, 
    // set is public and get is private
    typedef ::Property_Set_Public<    
        ::Test, 
        ::Number_Accessor<::Test>, 
        ::Number_Accessor<::Test>::value_type> Property_Set_Public_Number;

    // outside the scope of class Test, 
    // set is private and get is public
    typedef ::Property_Get_Public<    
        ::Test, 
        ::Number_Accessor<::Test>, 
        ::Number_Accessor<::Test>::value_type> Property_Get_Public_Number;

public:
    Property_Number               Number_A;
    Property_Set_Public_Number    Number_B;
    Property_Get_Public_Number    Number_C;
};

public class Test
{
   public int Number_A { get; set; }
   public int Number_B { private get; set; }
   public int Number_C { get; private set; }
}

Действительно... в чем разница...

Еще будет интересно посмотреть на сериализацию/десериализацию объекта Test С++.

A>насколько принципиально тащить в язык всё то, что можно вынести в библиотеку?
Если Вы не заботитесь о чистоте, читабельности, лаконичносте кода, то действительно незачем.

A>ну если о костылях, так C# — костыль к IL, который костыль к machine code, который костыль к cpu uops, который... ну короче продолжите сами
Чушь.

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

ГВ>>Тебя гугль забанил? Первая ссылка по запросу "C++ property implementation": http://www.codeproject.com/KB/cpp/cpp_property_indexer.aspx
C>Это не свойства.

Почему? Вроде бы, как раз свойства — синтаксис использования вполне характерный для свойств.

C>Это костыль, который пытается их эмулировать.

Ну знаешь, если любую библиотеку так называть, то библиотеки вообще не стоит разрабатывать.

C>В языке С++ нету свойств. тчк

Никто и не говорил, что в самом языке C++ есть "свойства".

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

M>Дело не в том, что считается базовой вещбю, а что — нет. Дело в том, что с теми же properties можно сразу использовать их из коробки, рыть гугл в поисках их замены, или писать boilerplate code каждый раз, сли их нет. Препочту первое. И так — со многим

Да и на здоровье. Но ты же не несёшь по белу свету пургу наподобие статьи в топикстарте.

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

[skip overquoting]

C>Действительно... в чем разница...

Ясное дело, в чём разница. В первом случае "свойство" — это независимый тип, который можно переопределить, обобщённо реализовать, перенести из класса в класс, и вообще накрутить уйму всего, оставив единый синтаксис собственно объявления и использования. А во втором нужно каждый раз бегать и ручками привязывать свойства к типу ("set; get;" как символ настоящего джедая). В остальном — никакой разницы.

C>Еще будет интересно посмотреть на сериализацию/десериализацию объекта Test С++.

Такая же, как и для обычной структуры данных.

A>>насколько принципиально тащить в язык всё то, что можно вынести в библиотеку?
C>Если Вы не заботитесь о чистоте, читабельности, лаконичносте кода, то действительно незачем.

Угу, "set; get;" как символ истинной лаконичности.

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

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

ГВ>[skip overquoting]

C>>Действительно... в чем разница...

ГВ>Ясное дело, в чём разница. В первом случае "свойство" — это независимый тип, который можно переопределить, обобщённо реализовать, перенести из класса в класс, и вообще накрутить уйму всего, оставив единый синтаксис собственно объявления и использования. А во втором нужно каждый раз бегать и ручками привязывать свойства к типу ("set; get;" как символ настоящего джедая). В остальном — никакой разницы.

Вы бьете рекорды по фанатичной чуши... Вы сами хоть верите в то, что пишете?

C>>Еще будет интересно посмотреть на сериализацию/десериализацию объекта Test С++.

ГВ>Такая же, как и для обычной структуры данных.

То есть никакая. Так и запишем.

A>>>насколько принципиально тащить в язык всё то, что можно вынести в библиотеку?
C>>Если Вы не заботитесь о чистоте, читабельности, лаконичносте кода, то действительно незачем.

ГВ>Угу, "set; get;" как символ истинной лаконичности.

Куда лаконичнее?

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

C>>Действительно... в чем разница...

ГВ>Ясное дело, в чём разница. В первом случае "свойство" — это независимый тип, который можно переопределить, обобщённо реализовать, перенести из класса в класс, и вообще накрутить уйму всего, оставив единый синтаксис собственно объявления и использования. А во втором нужно каждый раз бегать и ручками привязывать свойства к типу ("set; get;" как символ настоящего джедая). В остальном — никакой разницы.

И, кстати, небольшой ликбез для Вас:

public class Test<T>
{
   public T GenericAutoProperty { get; set; }
   ...
}

...

ver testString = new Test<string>();
var str = testString.GenericAutoProperty;