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

ГВ>>

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

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

Понятно. Значит, я придумал цитату из твоего собственного постинга. А сам твой постинг мне привиделся.

C>Что Вы от меня хотите услышать?

Да я уж не знаю, что от тебя можно хотеть услышать — у тебя ж перл на перле. Моя фантазия не хватать такой предел.

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

S>Он намекает на то, что в плюсах можно перегрузить конструктор копирования и оператор присваивания, а в дотнете нельзя.

В C# отлично можно определить конструктор, принимающий параметр того же типа.

Класс shared_ptr выглядит примерно так:

template<class T> class shared_ptr
{
public:
  explicit shared_ptr(T* p);
  shared_ptr(shared_ptr const& other);
  shared_ptr const& operator =(shared_ptr const& other);
  ~shared_ptr();
}

Подстрочный перевод на C# выглядит так:

class RefCounter<T> : IDisposable
{
  public RefCounter(T t) { ... }
  public RefCounter(RefCounter<T> other) { ... }
  public void Assign(RefCounter<T> other) { ... }
  public void Dispose() { ... }
}

Найди 33 отличия.

S>Поэтому соглашение об инкременте указателя придется выполнять самостоятельно.

Поясни.

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

Q>>Ты таки настаиваешь на том, что подсчёт ссылок — техника исключительно приплюснутых?

COF>Автоматический подсчет ссылок — да

Обоснуй.

int main()
{
  int const* const p_raw = new int(42);
  std::tr1::shared_ptr<int const> p(p_raw);
  std::tr1::shared_ptr<int const> q(p_raw);
  return EXIT_SUCCESS;
}

Почему тут не работает «автоматический» подсчёт ссылок? Что нужно сделать, чтобы заработал? Что мешает сделать то же самое в C#? Алсо, смотри здесь

Автор: Qbit86
Дата: 28.05.09

.

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

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

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

M>Если чо, до ошибки все равно не докопаться

ГВ>> Никаких вывертов. Я сам противник того, чтобы прятать под макросами какую-нибудь суровую магию. Лучше уж лишние пять строк написать, если что.

M>Лучше, если эти пять строк уже встроены в язык
осторожно! Можно ведь и захотеть декодер mpc поиметь встроенный в язык
Ограничивать себя в сладостях надо

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

Q>

Q>int main()
Q>{
Q>  int const* const p_raw = new int(42);
Q>  std::tr1::shared_ptr<int const> p(p_raw);
Q>  std::tr1::shared_ptr<int const> q(p_raw);
Q>  return EXIT_SUCCESS;
Q>}
Q>

Q>Почему тут не работает «автоматический» подсчёт ссылок? Что нужно сделать, чтобы заработал? Что мешает сделать то же самое в C#? Алсо, смотри здесь

Автор: Qbit86
Дата: 28.05.09

.

На самом деле я понимаю куда ты клонишь, определенный смысл в этом есть. Основное отличие, что в C++ ты создаешь shared_ptr и потом работаешь только с ним (одно место о котором стоит помнить — создание объекта), т.е. чтобы сделать как ты написал надо специально постараться. А в C# очень легко написать аналог a = b вместо a = b.Copy() (а присваивание может встречаться произвольное количество раз) и в этом случае весь подсчет ссылок идет лесом. В принципе, я это имел в виду. То, что при должной дисциплине проблем можно избежать, я не сомневаюсь. Так же, как впрочем, и при должной дисциплине можно легко избегать проблем с памятью и циклическими ссылками в C++.

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

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

ГВ>>>

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

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

ГВ>Понятно. Значит, я придумал цитату из твоего собственного постинга. А сам твой постинг мне привиделся.

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

C>>Что Вы от меня хотите услышать?

ГВ>Да я уж не знаю, что от тебя можно хотеть услышать — у тебя ж перл на перле. Моя фантазия не хватать такой предел.

Да. Вашей фантазии хватает только на детские попытки цепляться к словам и переиначивать слова собеседника. Достаточно вспомнить про "словарным структурам" и приписанные мне, выдуманное вами в данной ветке.

Здравствуйте, Qbit86, Вы писали:
Q>Найди 33 отличия.
Достаточно одного

S>>Поэтому соглашение об инкременте указателя придется выполнять самостоятельно.
Q>Поясни.
Очень просто. Вот у нас есть

public static void EpicFail(HugeBitmap bmp)
{
  RefCounter<HugeBitmap> c;
  using(var a = new RefCounter<HugeBitmap>(bmp)); // bmp.refCount++;
    {
      var b = new RefCounter(a); // bmp.refCount++
      c = a; // oops... вот в этот момент С++ инкрементирует указатель. С# - нет.
    b.Dispose(); //bmp.refCount-- 
    } // bmp.refCount-- => bmp.Release()
    c.Reference.Draw(); // InvalidOperationException!
}

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

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

COF>На самом деле я понимаю куда ты клонишь, определенный смысл в этом есть. Основное отличие, что в C++ ты создаешь shared_ptr и потом работаешь только с ним (одно место о котором стоит помнить — создание объекта), т.е. чтобы сделать как ты написал надо специально постараться. А в C# очень легко написать аналог a = b вместо a = b.Copy() (а присваивание может встречаться произвольное количество раз) и в этом случае весь подсчет ссылок идет лесом. В принципе, я это имел в виду. То, что при должной дисциплине проблем можно избежать, я не сомневаюсь. Так же, как впрочем, и при должной дисциплине можно легко избегать проблем с памятью и циклическими ссылками в C++.
А когда counter уменьшается? Не может случится, что я сошлюсь лишний раз и объект повиснет в памяти? Помнится когда-то я слышал аргумент в пользу сборщика мусора, мол, он помогает избежать проблем, связанных с циклическими ссылками, основанных на счетчиках.

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

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

ГВ>Как раз таки — тип.

Неправда.

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

ГВ>Where is a difference?

Вам неясна разница между указателем и тем на что он указывает ???
Круто. И эти люди пишут на C++

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

MK>А когда counter уменьшается? Не может случится, что я сошлюсь лишний раз и объект повиснет в памяти? Помнится когда-то я слышал аргумент в пользу сборщика мусора, мол, он помогает избежать проблем, связанных с циклическими ссылками, основанных на счетчиках.

Может конечно, это надо специально разруливать — например использовать пару shared_ptr/weak_ptr

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

ГВ>>Как раз таки — тип.
D>Неправда.

Я имел в виду именно тип самого члена класса.

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

В терминах C++ метод нельзя передать как параметр иначе, чем в виде указателя.

D>Круто. И эти люди пишут на C++

О! В том, что я не понимаю, что такое указатель, меня ещё никто не обвинял.

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

ГВ>Здравствуйте, drol, Вы писали:
ГВ>>>Как раз таки — тип.
D>>Неправда.
ГВ>Я имел в виду именно тип самого члена класса.
Оригинально. Ну тогда и свойства — тип.

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

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

MK>>А когда counter уменьшается? Не может случится, что я сошлюсь лишний раз и объект повиснет в памяти? Помнится когда-то я слышал аргумент в пользу сборщика мусора, мол, он помогает избежать проблем, связанных с циклическими ссылками, основанных на счетчиках.

COF>Может конечно, это надо специально разруливать — например использовать пару shared_ptr/weak_ptr
Вот знаешь, почему хорошо, что в C# нет перегрузки присваивания? Как раз чтобы голова не занималась подсчетом этих операцией или выбором вида указателей. А еще ведь надо будет глядеть не перекрыт ли оператор присваивания, а то мало ли чего на самом деле делается. В C# я всегда знаю, что a = b — есть только копирование указателя в случае ссылочного типа и копирование значения в случае value-типа. Всё четко и ясно. По-моему, это плюс.

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

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

MX>И, если знаете, про то, почему не-типы нельзя в generic-и по-чём зря совать.
Я не фига не понял эту фразу. Какие не типы по-чем совать generic зря? Что там нельзя в generic засунуть?

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

MX>>И, если знаете, про то, почему не-типы нельзя в generic-и по-чём зря совать.
MK>Я не фига не понял эту фразу. Какие не типы по-чем совать generic зря?

Которые non-type. В C++ аргументом шаблона может быть не только тип, но и значение какого-то типа.

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

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

MX>>>И, если знаете, про то, почему не-типы нельзя в generic-и по-чём зря совать.
MK>>Я не фига не понял эту фразу. Какие не типы по-чем совать generic зря?
D>Которые non-type. В C++ аргументом шаблона может быть не только тип, но и значение какого-то типа.
Ааа.. понятно.

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

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

ГВ>>Здравствуйте, drol, Вы писали:
ГВ>>>>Как раз таки — тип.
D>>>Неправда.
ГВ>>Я имел в виду именно тип самого члена класса.
MK>Оригинально. Ну тогда и свойства — тип.

Вот это как раз и интересно. Например, на C++ я могу написать функцию, которая будет требовать в качестве параметра именно "свойство". Примерно так:

void func(PropertyBase<int> *prop){ ... }

То есть на вход ей должно поступить именно свойство. И соответственно, могу сделать шаблон, предполагающий использование классов свойств:

template<typename Property_>
class Foo
{
  public:
    typedef typename Property_::value_type value_type;
    typedef typename Property_::host_type host_type;
};

И т.д. Короче говоря, могу обращаться со свойством, как с полноценным типом. На C#, насколько я знаю, так поступить нельзя (за исключением использования PropertyInfo, но это несколько иной механизм).

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

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

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

ГВ>>>Здравствуйте, drol, Вы писали:
ГВ>>>>>Как раз таки — тип.
D>>>>Неправда.
ГВ>>>Я имел в виду именно тип самого члена класса.
MK>>Оригинально. Ну тогда и свойства — тип.

ГВ>Вот это как раз и интересно. Например, на C++ я могу написать функцию, которая будет требовать в качестве параметра именно "свойство". Примерно так:
Да пускай требует. Свойство от этого типом не становится.

ГВ>void func(PropertyBase<int> *prop){ ... }
Я в С++ не силен. Напиши как ты будешь это юзать.

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

ГВ>>Вот это как раз и интересно. Например, на C++ я могу написать функцию, которая будет требовать в качестве параметра именно "свойство". Примерно так:
MK>Да пускай требует. Свойство от этого типом не становится.

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

ГВ>>void func(PropertyBase<int> *prop){ ... }
MK>Я в С++ не силен. Напиши как ты будешь это юзать.

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

Тогда я смогу сделать так:

template<typename T, ...> class Property : public PropertyBase<T> { ... };

temaplate<typename T, ...> class MySmartProperty : public Property<T> {
  private:
    // Предположим, что такая проперть имеет какую-нибудь хитрую функцию,
    // вызываемую, например, при изменении значения:
    void HiddenSmartFunc() { ... }
};

// Тогда тестовая функция может выглядеть так:
void MyTestFunc(PropertyBase<int> *prop){
  *prop = 42;
  // Проверяем - вызвалась ли HiddenSmartFunc
}

Но это мелочи. Гораздо интереснее другое возможное применение. Например, у нас есть класс какого-нибудь развесистого окна с развесистым же управлением, например, свойствами Enabled. Если я могу оперировать свойствами, как отдельными объектами, то я могу написать функцию управления Enabled примерно так (пример сильно упрощённый):

void ManageEnabled(PropertyBase<bool> &propOK, PropertyBase<bool> &propCancel) {
  if (someCondition)
  {
    propOK = true;
    propCancel = false;
  }
  else if (otherCondition)
  {
    propOK = false;
    propCancel = true;
  }
  else // strangeCondition
  {
    propOK = false;
    propCancel = false;
  }
}

Обрати внимание, что эта функция не зависит от типов объектов-носителей самих свойств. Ими могут быть и окна, и какие-нибудь другие классы.

Но это ещё не всё. Эту же функцию можно обобщить:

template<typename P1, typename P2>
void ManageEnabled(P1 &propOK, P2 &propCancel) { ... }

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

bool bOK = false, bool bCancel = false;

someCondition = true; // Это упрощение - я имею в виду, что мы привели тестовое окружение в состояние,
// когда внутреннее условие someCondition станет true.

ManageEnabled(bOK, bCancel);

TEST_ASSERT(bOK && !bCancel);

otherCondition = true;

ManageEnabled(bOK, bCancel);

TEST_ASSERT(!bOK && bCancel);

someCondition = false;
otherCondition = false;

ManageEnabled(bOK, bCancel);

TEST_ASSERT(!bOK && !bCancel);

Само собой, её можно перетаскивать из класса в класс, положить в библиотеку, использовать ещё как-то и т.п.

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

В примере test-case стоит запятая вместо точки с запятой:

bool bOK = false;
bool bCancel = false;

А то ещё подумаешь чего дурного.