Re[2]: За что я не люблю С++ - Компьютерные священные войны

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

F>>должно компиляться и нормально работать..

S>Нет, не должно. Ну, то есть кроме компиляться.
S>Во-первых, то, что после "//или" делает не то что нужно.

да, оно делает не всё, что делается в шарпах, я знаю..
на этом пытаются подловить все поклонники шарпов в этом треде..
но в ограниченных условиях — работает :Р

S>Во-вторых, покажи мне, как будет выглядеть аналог Test.A+=5?

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

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

F>да, оно делает не всё, что делается в шарпах, я знаю..
Нет, оно делает не то. Ты же оператор перегрузил не для свойства, а для класса.
F>на этом пытаются подловить все поклонники шарпов в этом треде..
F>но в ограниченных условиях — работает :Р
Ни в каких не работает.

S>>Во-вторых, покажи мне, как будет выглядеть аналог Test.A+=5?
F>на голых плюсах нельзя же..
Можно, но будет очень многословно.
F>можно, наверное, сделать шаблон типа shared_ptr, который будет реализовывать всё это.. правда пухло получится..
Нужный шаблон был приведён выше по ветке. Ну вот только пример с его применением написать поклонники С++ стесняются.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

F>вот, например.. объясни разницу, пожалуйста..
F>

F>class Test
F>{
F>    int _a;
F>    boost::function<void (Test*)> OnChanged;

F>public:
F>    int A(){return _a;}

F>    void A(int a){_a = a; if(OnChanged != NULL) OnChanged(this);}
F>// или
F>    void operator=(int& a){_a = a; if(OnChanged != NULL)OnChanged(this);}

F>};
F>

F>должно компиляться и нормально работать..

Замечательно. А теперь объясните нам как Вы будете на этот Changed навешивать обработчики (1+).

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

F>>>например, вывод на консоль..

в питоне(про 3ю версию не уверен) print — это оператор языка, а не функция.. базовая штука ведь

C>>Аналогично было в Pascal. Только там это было нужно из-за примитивизма языка, не позволяющего создавать методы с переменным количеством аргументов.

F>ты не понял, print — это не базовая фича языка.. вот совсем ни разу..
F>но его внесли, посчитав это выгодным.. и что теперь, оглядываться на них и повторять то же самое?.

Я все понял. Это Вы не поняли того, что я Вам ответил.

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

M>>Ведь в С++ тонны метаинформации! © Он что, не может сам узнать, что там сериализовывать из родительского класса?

M_>а что, какой-нибудь мегаумный мегаязык способен провести сериализацию объекта с циклическими ссылками?

M_>здорово, если так.

А в чем проблема? Та же java это умеет с версии 1.1, которая была выпушена много лет назад.
Вообще говоря, на java или .NET собственный сериализатор(в любой произвольный формат) пишется за час максимум.

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

F>>да, оно делает не всё, что делается в шарпах, я знаю..
S>Нет, оно делает не то. Ты же оператор перегрузил не для свойства, а для класса.

ага, облажался..

F>>можно, наверное, сделать шаблон типа shared_ptr, который будет реализовывать всё это.. правда пухло получится..
S>Нужный шаблон был приведён выше по ветке. Ну вот только пример с его применением написать поклонники С++ стесняются.

а как насчёт чего нибудь вроде этого:

class Test
{
int a;
public:
 Wrapper<int> a(){return Wrapper<int>(this, set_func, get_func);}
};
// и использование будет таким:
test.a() = 123;
int b = test.a();

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

C>Замечательно. А теперь объясните нам как Вы будете на этот Changed навешивать обработчики (1+).

google -> boost::singnal
я использую boost::function просто по привычке..

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

C>>Замечательно. А теперь объясните нам как Вы будете на этот Changed навешивать обработчики (1+).

F>google -> boost::singnal
F>я использую boost::function просто по привычке..

Посмотрите внимательно на свой код.

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

F>а как насчёт чего нибудь вроде этого:
F>

F>class Test
F>{
F>int a;
F>public:
F> Wrapper<int> a(){return Wrapper<int>(this, set_func, get_func);}
F>};
F>// и использование будет таким:
F>test.a() = 123;
F>int b = test.a();
F>

Спрячьте и никому больше не показывайте.

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

F>а как насчёт чего нибудь вроде этого:
F>

F>class Test
F>{
F>int a;
F>public:
F> Wrapper<int> a(){return Wrapper<int>(this, set_func, get_func);}
F>};
F>// и использование будет таким:
F>test.a() = 123;
F>int b = test.a();
F>

А ты полный пример кода приведи — посмотришь, как оно будет "удобно". А то у тебя тут ни set_func, ни get_func нету.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

C>Эта — которую Вы вырезали (стыдно уже стало, да?) — дает хорошую фору тому, что в топик старте.

Да нет, если и стало стыдно, то только за то, что упомянул {get; set;}. Приношу извинения — {get;set;} не является признаком настоящего джедая и не архикакая лаконичность. Надо признать, это высказывание было ошибкой. Сорвался, признаю.

C>Значит показать не можете? "Слив засчитан" (уж простите мой жаргон, которому я набрался в этом форуме).

Могу, разумеется, но не буду. Могу даже сам написать, но мне хватило твоей реакции на IoC-контейнер. Лишний раз выслушивать рассуждения об ужасе, затычках и уродстве... Есть одна поговорка на этот счёт, которую я не хочу прилюдно напоминать.

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

ГВ>>Ты мне сначала покажи такую систему, где нужна сериализация любого графа любых объектов и где эта самая сериализация предварительно не спланирована. А потом — тебе сколько фактов ни дай, тебе всё индифферентно.

C>"Слив засчитан".

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

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

C>>>Замечательно. А теперь объясните нам как Вы будете на этот Changed навешивать обработчики (1+).
F>>google -> boost::singnal
C>Посмотрите внимательно на свой код.

да, не public, я знаю.. так просто короче..

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

F>>а как насчёт чего нибудь вроде этого:
F>>

F>> Wrapper<int> a(){return Wrapper<int>(this, set_func, get_func);}
F>>

S>А ты полный пример кода приведи — посмотришь, как оно будет "удобно". А то у тебя тут ни set_func, ни get_func нету.

да то же самое.. get/set спрятанные внутрь метода или "мясом наружу" работают одинаково..
единственное что — неэстетично выгдядит обёртка.. но с этим ещё можно подумать..

по сути это что то схожее с property от микрософта..

__declspec(property(get = getprop, put = putprop)) int the_prop;

http://msdn.microsoft.com/en-us/library/yhfk0thd.aspx

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

NBN>>- сохранение/восстановление в хмл/нативный формат
NBN>>- клонирование графа
NBN>>- конвертация графа в нативный формат

НС>Это все "построение протокола обмена данными"?

В некотором роде. Сериализация в данном случае работает конвертером из данного формата в множество каких-то других.

Здравствуйте, neFormal, Вы писали:
F>да то же самое.. get/set спрятанные внутрь метода или "мясом наружу" работают одинаково..
Работают — одинаково. Выглядят — по разному.
В итоге всё и кончается

class Test
{
  BEGIN_PROPERTY_LIST(Test)
  BEGIN_PROPERTY (int, A)
    PROPERTY_GET()
        {
          return _a;
        }
        PROPERTY_SET()
        {
          _a = value;
        }
  END_PROPERTY(int, A)
  END_PROPERTY_LIST(Test)
}

F>единственное что — неэстетично выгдядит обёртка.. но с этим ещё можно подумать..
Ну так это и есть костыль — неэстетично выглядящая подробность реализации.
Там достаточно сделать опечатку типа int& в декларации проперти типа — и упс! Будешь потом неделю бороду чесать, разбираясь что куда девалось.
F>по сути это что то схожее с property от микрософта..
Да-да, я в курсе про многообразные костыли.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

S>Здравствуйте, neFormal, Вы писали:
F>>да то же самое.. get/set спрятанные внутрь метода или "мясом наружу" работают одинаково..
S>Работают — одинаково. Выглядят — по разному.
S>В итоге всё и кончается
S>

S>class Test
S>{
S>  BEGIN_PROPERTY_LIST(Test)
S>  BEGIN_PROPERTY (int, A)
S>    PROPERTY_GET()
S>        {
S>          return _a;
S>        }
S>        PROPERTY_SET()
S>        {
S>          _a = value;
S>        }
S>  END_PROPERTY(int, A)
S>  END_PROPERTY_LIST(Test)
S>}
S>

Вот тут ты не прав. Проперти могут выглядеть и по-другому:

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>>единственное что — неэстетично выгдядит обёртка.. но с этим ещё можно подумать..
S>Ну так это и есть костыль — неэстетично выглядящая подробность реализации.
S>Там достаточно сделать опечатку типа int& в декларации проперти типа — и упс! Будешь потом неделю бороду чесать, разбираясь что куда девалось.

Не преувеличивай.

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

S>Там достаточно сделать опечатку типа int& в декларации проперти типа — и упс! Будешь потом неделю бороду чесать, разбираясь что куда девалось.
F>>по сути это что то схожее с property от микрософта..
S>Да-да, я в курсе про многообразные костыли.

По моему, свойства прекрасно заменяются get и set функциями, но если считается, что любая возможность которая есть в одном языке, но которой нет в другом языке однозначно свидетельствует о превосходстве первого над вторым, сколь ни натянутой и бесполезной эта возможность на самом деле является, то повторите на C# вот такое вот поведение.

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

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

C>Замечательно. А теперь объясните нам как Вы будете на этот Changed навешивать обработчики (1+).

По большому счёту, это довольно опасная штука — развешивать "обработчики" на "события". Как минимум, всякий раз рискуешь нарваться на что угодно — от бесконечной рекурсии, до дедлоков. Хотя да, лежащий на поверхности наивный подход как раз и состоит в том, чтобы понавешать "сигналов", т.е. — callbacks.

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

ГВ>>Что-то больно много базовых вещей появляется, не находишь? Уже и linq в качестве базовых замаячил. Интересно, что дальше будет?

F>например, вывод на консоль..

в питоне(про 3ю версию не уверен) print — это оператор языка, а не функция.. базовая штука ведь

Питон... WriteLn — встроенный оператор (процедура) Паскаля!

	От:	Ночной Смотрящий
	Дата:	27.05.09 08:51
	Оценка:

	От:	neFormal
	Дата:	27.05.09 09:05
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	27.05.09 09:22
Оценка:	+1

	От:	criosray
	Дата:	27.05.09 09:36
	Оценка:

	От:	criosray
	Дата:	27.05.09 09:38
	Оценка:

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	27.05.09 11:12
Оценка: