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

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

не-не. я не про это. никто не предлагал использовать microsoft specific properties, предложили "ужасный костыль".
ты сказал про компиляторы, то есть фактически про реализацию стандарта. костыль, насколько мне известно, скомпилируется. а вот сколько компиляторов C# (если конечно о них пристойно говорить во множественном числе) реализуют все фичи последнего официального стандарта C# ?

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

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

<костыль скиппед>

C>

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

C>Действительно... в чем разница...
это простейшее использование. если туда напихать кода, он тоже будет вполне пухлым. к тому же непрозрачным — автор того что написано по ссылке в первом сообщении вроде жаловался что компилятор генерит что-то еще. уж лучше прямо написать get_Number_A, что в C#, что в C++

A>>насколько принципиально тащить в язык всё то, что можно вынести в библиотеку?
C>Если Вы не заботитесь о чистоте, читабельности, лаконичносте кода, то действительно незачем.
я тогда боюсь предположить, что туда еще затолкают. кстати, а Parallel.For, почему он не в языке? ведь лаконичнее же написать "parallel for(......)", чем цеплять библиотеку и т.д.

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

пожалуйста, расскажи мне сакральный смысл пропертей, вот я реально не понимаю зачем они нужны когда можно просто

class Foo
{
public:
  void bar(int bar) { m_bar = bar; }
  int bar() const { return m_bar; }
private:
  int m_bar;
};

//...
Foo f;
f.bar(10);
int bar = f.bar();
//...

?
вот реально, в чём цимес пропертей? не, ну я вижу ужасающий синтаксический оверхед в вслучае геттера в виде двух скобок, и в случае сеттера тоже, да (правда '=' писать не надо), однако всё ещё не считаю ето поводом для внесения пропертей в фичу языка, а ты как считаешь?

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

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

A>не-не. я не про это. никто не предлагал использовать microsoft specific properties, предложили "ужасный костыль".
A>ты сказал про компиляторы, то есть фактически про реализацию стандарта. костыль, насколько мне известно, скомпилируется. а вот сколько компиляторов C# (если конечно о них пристойно говорить во множественном числе) реализуют все фичи последнего официального стандарта C# ?

Сколько? Он всего один.

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

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

A><костыль скиппед>

C>>

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

C>>Действительно... в чем разница...
A>это простейшее использование. если туда напихать кода, он тоже будет вполне пухлым.
Если туда еще и кода напихать, то это будет тихий ужас.

A>к тому же непрозрачным — автор того что написано по ссылке в первом сообщении вроде жаловался что компилятор генерит что-то еще. уж лучше прямо написать get_Number_A, что в C#, что в C++
В С++ лучше за не имением стандартного/нормального/вменяемого способа решения. В С# ну уж никак не лучше.

A>>>насколько принципиально тащить в язык всё то, что можно вынести в библиотеку?
C>>Если Вы не заботитесь о чистоте, читабельности, лаконичносте кода, то действительно незачем.
A>я тогда боюсь предположить, что туда еще затолкают. кстати, а Parallel.For, почему он не в языке? ведь лаконичнее же написать "parallel for(......)", чем цеплять библиотеку и т.д.
Вы это у Майкрософт спрашивайте, а не у меня.

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

Х>пожалуйста, расскажи мне сакральный смысл пропертей, вот я реально не понимаю зачем они нужны когда можно просто

1. Читабельность кода.
2. Compile time проверка корректности типов и именования.

void setBAr(int a);
long getBaR();

vs

public int Bar { get; set; }

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

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

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

Я это знаю. Это ярые (подчёркиваю — ярые) противники C++ обычно верят в какие-то невероятные мифы. Я уж не знаю, почему так складывается, но как только кто-то выступает с резкой критикой C++, так такую пургу нести начинает — уши вянут.

C>>>Еще будет интересно посмотреть на сериализацию/десериализацию объекта Test С++.
ГВ>>Такая же, как и для обычной структуры данных.
C>То есть никакая. Так и запишем.

Любая. В твоем мире — если сериализация не встроена в платформу, то её нет, я уже понял. В моём — если какой-то фишки нет, то это означает, что она может быть любой.

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

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

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

Откуда я знаю? Но затычка отсутствия умолчаний налицо. И это в языке, для которого проперти — роднее всех родных.

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

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

Х>>пожалуйста, расскажи мне сакральный смысл пропертей, вот я реально не понимаю зачем они нужны когда можно просто

C>1. Читабельность кода.
C>2. Compile time проверка корректности типов и именования.
3. Атрибуты
4. Обзёрвер INotifyPropertyChanged

наверно еще чего-то наберется, сразу и не вспомнишь...

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

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

Х>>пожалуйста, расскажи мне сакральный смысл пропертей, вот я реально не понимаю зачем они нужны когда можно просто

C>1. Читабельность кода.
а что не читабельно в моём примере? возникли какие-то затруднения?

C>2. Compile time проверка корректности типов и именования.
C>

C>void setBAr(int a);
C>long getBaR();
C>

C>vs

C>

C>public int Bar { get; set; }
C>

гхм, с чем с чем, а вот с такими проблемами в отношении пропертей не сталкивался даже в с++, вот те крест: +

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

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

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

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

ГВ>Я это знаю. Это ярые (подчёркиваю — ярые) противники C++ обычно верят в какие-то невероятные мифы. Я уж не знаю, почему так складывается, но как только кто-то выступает с резкой критикой C++, так такую пургу нести начинает — уши вянут.

Такой, как эта?

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

Вот уж вянут, так вянут...

C>>>>Еще будет интересно посмотреть на сериализацию/десериализацию объекта Test С++.
ГВ>>>Такая же, как и для обычной структуры данных.
C>>То есть никакая. Так и запишем.

ГВ>Любая. В твоем мире — если сериализация не встроена в платформу, то её нет, я уже понял. В моём — если какой-то фишки нет, то это означает, что она может быть любой.

Я еще раз прошу показать универсальный С++ сериализатор XML или Json для любого графа объектов. Двунаправленный. Дженерик (шаблонный).

Покажете или будете продолжать разводить демагогию и фанатичную чушь без единого факта по теме?

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

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

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

ГВ>Откуда я знаю? Но затычка отсутствия умолчаний налицо. И это в языке, для которого проперти — роднее всех родных.

Каких еще умолчаний? Расшифруйте полет мысли.

PS: Правильно тут кто-то недавно заметил, что те, кто хаят С# знают его на уровне чайника...

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


Х>>>пожалуйста, расскажи мне сакральный смысл пропертей, вот я реально не понимаю зачем они нужны когда можно просто

C>>1. Читабельность кода.
Х>а что не читабельно в моём примере? возникли какие-то затруднения?
Возникнут. Когда у Вас будут тысячи бизнес-классов с нетривиальной логикой.

C>>2. Compile time проверка корректности типов и именования.
C>>

C>>void setBAr(int a);
C>>long getBaR();
C>>

C>>vs

C>>

C>>public int Bar { get; set; }
C>>

Х>гхм, с чем с чем, а вот с такими проблемами в отношении пропертей не сталкивался даже в с++, вот те крест: +
Ну да, ну да.

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

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

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

Х>>>пожалуйста, расскажи мне сакральный смысл пропертей, вот я реально не понимаю зачем они нужны когда можно просто

C>>1. Читабельность кода.
C>>2. Compile time проверка корректности типов и именования.
MK>3. Атрибуты
MK>4. Обзёрвер INotifyPropertyChanged

MK>наверно еще чего-то наберется, сразу и не вспомнишь...
ето уже получше, хотя опять же что то что другое можно семулировать и на с++

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

Х>>>пожалуйста, расскажи мне сакральный смысл пропертей, вот я реально не понимаю зачем они нужны когда можно просто

C>>1. Читабельность кода.
C>>2. Compile time проверка корректности типов и именования.
MK>3. Атрибуты
MK>4. Обзёрвер INotifyPropertyChanged

MK>наверно еще чего-то наберется, сразу и не вспомнишь...

Еще, например, переопределение в классе-наследнике.

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

MK>>наверно еще чего-то наберется, сразу и не вспомнишь...
Х>ето уже получше, хотя опять же что то что другое можно семулировать и на с++
Сэмулировать можно много чего. Только это все-равно будет убогим/неудобным/ущербным костылем...

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

C>>>1. Читабельность кода.
C>>>2. Compile time проверка корректности типов и именования.
MK>>3. Атрибуты
MK>>4. Обзёрвер INotifyPropertyChanged

MK>>наверно еще чего-то наберется, сразу и не вспомнишь...
Х>ето уже получше, хотя опять же что то что другое можно семулировать и на с++
Интересно как на С++, например, реализовать второй пункт для четвертого. Идея проста: перед генерацией события INotifyPropertyChanged.PropertyChanged при помощи Рефлексии проверяется, что свойство с заданным именем действительно есть в классе. Тем самым при отладке мы защищаемся от кривого указания имени в аргументах события.

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

A>>ты сказал про компиляторы, то есть фактически про реализацию стандарта. костыль, насколько мне известно, скомпилируется. а вот сколько компиляторов C# (если конечно о них пристойно говорить во множественном числе) реализуют все фичи последнего официального стандарта C# ?
C>Сколько? Он всего один.
Как линия Партии. И чего все такие тупые, что не делают реализаций C#?

A>>это простейшее использование. если туда напихать кода, он тоже будет вполне пухлым.
C>Если туда еще и кода напихать, то это будет тихий ужас.
с ростом объема кода отношение V(C++)/V(C#) будет стремиться к 1. и код там будет осмысленный, а не костыльная обвязка, как в C++, и не синтаксический сахар, как в C#. но если писать код ради красоты кода, то конечно на это пофиг.

A>>>>насколько принципиально тащить в язык всё то, что можно вынести в библиотеку?
C>>>Если Вы не заботитесь о чистоте, читабельности, лаконичносте кода, то действительно незачем.
A>>я тогда боюсь предположить, что туда еще затолкают. кстати, а Parallel.For, почему он не в языке? ведь лаконичнее же написать "parallel for(......)", чем цеплять библиотеку и т.д.
C>Вы это у Майкрософт спрашивайте, а не у меня.
очень мне надо. я вообще под линукс пишу.
мне интересен предел разбухания языка (неважно какого), при котором *пользователи* (то есть программисты в данном случае) будут считать язык неизбыточным.

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

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

Х>пожалуйста, расскажи мне сакральный смысл пропертей, вот я реально не понимаю зачем они нужны когда можно просто

Х>

Х>class Foo
Х>{
Х>public:
Х>  void bar(int bar) { m_bar = bar; }
Х>  int bar() const { return m_bar; }
Х>private:
Х>  int m_bar;
Х>};

Х>//...
Х>Foo f;
Х>f.bar(10);
Х>int bar = f.bar();
Х>//...

Х>

Х>?
Х>вот реально, в чём цимес пропертей? не, ну я вижу ужасающий синтаксический оверхед в вслучае геттера в виде двух скобок, и в случае сеттера тоже, да (правда '=' писать не надо), однако всё ещё не считаю ето поводом для внесения пропертей в фичу языка, а ты как считаешь?

Тривиальный пример:

f.Bar += 10;

Тоже самое без пропертей:

f.setBar(f.getBar() + 10);

Обычно наличие пропетей сопровождается метаданными. Это позволяет делать байндинги, property-gridы и прочие разодсти связывания с данными.
Очень показательный пример с Java,где на уровне языка пропетри не поддерживаются, то многие фреймворки в своих метаданных оперируют именно пропертями, которые в коде обязытельно должны соотвествовать методам getPropName и setPropName. Надеюсь не надо объяснять какие грабли это создает

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

A>>>ты сказал про компиляторы, то есть фактически про реализацию стандарта. костыль, насколько мне известно, скомпилируется. а вот сколько компиляторов C# (если конечно о них пристойно говорить во множественном числе) реализуют все фичи последнего официального стандарта C# ?
C>>Сколько? Он всего один.
A>Как линия Партии. И чего все такие тупые, что не делают реализаций C#?
Зачем? Гораздо лучше, если голова всему одна, а не "комитет — существо с шестью ногами", как цитировал кого-то Влад не столь давно.

A>>>это простейшее использование. если туда напихать кода, он тоже будет вполне пухлым.
C>>Если туда еще и кода напихать, то это будет тихий ужас.
A>с ростом объема кода отношение V(C++)/V(C#) будет стремиться к 1.
Соотношение никогда не будет стремиться к 1. Кроме свойств в С++ еще оооооочень много другого раздувающего непомерно код, делающего его нечитабельным.

A>и код там будет осмысленный, а не костыльная обвязка, как в C++, и не синтаксический сахар, как в C#. но если писать код ради красоты кода, то конечно на это пофиг.
Да уж лучше синтаксический сахар, чем синтаксическая, извините, куча (не будем уточнять чего — сами дофантазируете, коли есть желание), которую мы наблюдаем на примере С++.


A>>>я тогда боюсь предположить, что туда еще затолкают. кстати, а Parallel.For, почему он не в языке? ведь лаконичнее же написать "parallel for(......)", чем цеплять библиотеку и т.д.
C>>Вы это у Майкрософт спрашивайте, а не у меня.
A>очень мне надо. я вообще под линукс пишу.
A>мне интересен предел разбухания языка (неважно какого), при котором *пользователи* (то есть программисты в данном случае) будут считать язык неизбыточным.
Спрашивайте у Хайлсберга. Ему лучше знать.

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

LVV>Вроде это тот Боресков, который книжки по графике в ДиалогМИФИ печатает. Чел вполне квалифицированный...
Возможно писатель он и квалифицированный (не читал, не видел), но в голове у товарища явная каша.

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

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

C>>>>1. Читабельность кода.
C>>>>2. Compile time проверка корректности типов и именования.
MK>>>3. Атрибуты
MK>>>4. Обзёрвер INotifyPropertyChanged

MK>>>наверно еще чего-то наберется, сразу и не вспомнишь...
Х>>ето уже получше, хотя опять же что то что другое можно семулировать и на с++
MK>Интересно как на С++, например, реализовать второй пункт для четвертого. Идея проста: перед генерацией события INotifyPropertyChanged.PropertyChanged при помощи Рефлексии проверяется, что свойство с заданным именем действительно есть в классе. Тем самым при отладке мы защищаемся от кривого указания имени в аргументах события.
а мне интересно как вяжется ето с compile-time проверкой.

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


MK>Интересно как на С++, например, реализовать второй пункт для четвертого. Идея проста: перед генерацией события INotifyPropertyChanged.PropertyChanged при помощи Рефлексии проверяется, что свойство с заданным именем действительно есть в классе. Тем самым при отладке мы защищаемся от кривого указания имени в аргументах события.

Кстати, единственное чего не хватает в С# — макроподстановки имени свойства:

public int Height
{
   get { return _height; }
   set {
      _height = value;
      OnPropertyChanged("Height");
   }
}

Есть конечно вариант решения с лямбдой и рефлексией: OnPropertyChanged(o => o.Height);
Но очевидный перформанс хит в данном случае делает такое решение часто недопустимым...

Конечно генерация кода с помощью T4-шаблонов ликвидирует возможность опечатки, но хотелось бы все-таки макроподстановку. Тем более, что это совсем не сложно сделать, имхо.

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

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

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

C>>>>>1. Читабельность кода.
C>>>>>2. Compile time проверка корректности типов и именования.
MK>>>>3. Атрибуты
MK>>>>4. Обзёрвер INotifyPropertyChanged

MK>>>>наверно еще чего-то наберется, сразу и не вспомнишь...
Х>>>ето уже получше, хотя опять же что то что другое можно семулировать и на с++
MK>>Интересно как на С++, например, реализовать второй пункт для четвертого. Идея проста: перед генерацией события INotifyPropertyChanged.PropertyChanged при помощи Рефлексии проверяется, что свойство с заданным именем действительно есть в классе. Тем самым при отладке мы защищаемся от кривого указания имени в аргументах события.
Х>а мне интересно как вяжется ето с compile-time проверкой.
Ну, оставим compile-time, я даже не обратил на это внимание, т.к. за последнее время привык, что под корректностью именования подразумевают именно ту процедуру, которую описал. Так как оно на С++?