Свой компилятор(С++'о подобный)

[ROD]

Извените что не в тему где можно найти нормальное описание структуры EXE?

Начнем с того, что exe бывают разные - MZ и PE. В этом направлении гуглите.

[BOBAH13]

Сообщение от pu4koff

Может конечно я туплю, но не понимаю идею всё равно.
Кнопка нужна форме, следовательно счетчик + 1. Форма нужна кнопке - следовательно счетчик + 1. Получаем, что форма не может удалиться, т.к. её счетчик равен 1 и та же ситуация с кнопкой.
Если я буду хранить список кнопок формы без увеличения счетчиков, то они соберутся сборщиком и волшебным образом пропадут с экрана на глазах у удивленного пользователя.

1.

Кнопка нужна форме, следовательно счетчик + 1

Верно, при создании новой кнопки вызывается alloc => counter = 1
2.

Форма нужна кнопке - следовательно счетчик + 1

Зачем это? Форма вообще не нужна кнопка, кнопка по сути отдельный объект как и форма. У формы уже есть один объект с counter = 1, зачем еще раз увеличивать counter?
3.

Если я буду хранить список кнопок формы без увеличения счетчиков, то они соберутся сборщиком

Нет. Ибо при создании (alloc) кнопки у него counter = 1, сборщик не сможет убить эту кнопку, counter ведь не равен 0.
4. Во время удаления формы, можно просто пробежатся по списку контролов и у каждого вызвать release, т.е. уменьшить counter на 1, т.к. по сути все что было добавлено во время инициализации формы и после, все объекты, они были добавлены через alloc либо через retain, что значит каждый был добавлен с +1 к counter'у. Значит логично все в списке -1 от counter'a. Соответственно, если объект более никуда не ссылается, counter = 0 и объект будет уничтожен, это к примеру наша кнопка, которая ничего не делает на форме, она была создана во время инициализации формы (alloc => counter = 1) и при удалении формы release из списка => counter = 0 => free.

Надеюсь ясно вы просто не много не понимаете идею, ибо она очень отличается от идей языков delphi/c++/c# и многие другие.

UPD:

// view/form/window
--Window
----------Okay
----------Cancel

...

// code related to view/form/window
Window *Window;
Button *Okay;
Button *Cancel;

// initialization
void Init {
  Window = Window.alloc;
  Okay = Button.alloc;
  Cancel = Button.alloc;

  Window.list.add(okay);
  Window.list.add(cancel);
}

void AddControl(Button *Button) {
  // new control, no matter how many links it already has
  Window.list.add(Button.retain); // add to list with growing counter of the button
}

void Dealloc {
  // okay.release;
  // cancel.release;
  foreach (element in Window.list) {
    element.release;
  }
  Window.release;
}

Вот и все думаю так яснее. Это я так схематически можно сказать сделал, разумеется в реале, Window объект это this(C++), self(Delphi) и т.п. т.е. не надо писать Window.XXX и освобождать/создавать Window.

[pu4koff]

BOBAH13, мозг у меня совсем не работает, поэтому так я до конца идею и не понял. Ну да ладно. Может когда-нибудь до Objective C руки дойдут, там со сборщиком и разберусь. До меня теория без практики туго доходит

[Пепел Феникса]

А вот вопрос, это язык компилируемый я так понимаю? Вы в итоге напишите интерпретатор который будет переводить ваш код(язык) в asm, а потом используя какой либо asm компилятор компилировать уже в бинарный код? Или идея в чем то другом?

компилируемый.
да сначало в асм потом в bin, хочу написать компиль асма к нему, чтоб он сам мог это все сделать.
ну и линкер(но это проще чем компиль асма)

Извените что не в тему где можно найти нормальное описание структуры EXE?

http://www.microsoft.com/whdc/system...re/pecoff.mspx

new есть. delete - нет. Значит утечка будет.

хочу уточнить, утечка будет изза того что начальный b не удаляется?(теряется ссылка на него)

[pu4koff]

Сообщение от Пепел Феникса

хочу уточнить, утечка будет изза того что начальный b не удаляется?(теряется ссылка на него)

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

[Пепел Феникса]

а можно примерчик небольшой?
(конечно вообще там правильно += применить, но в данный момент не суть)

[pu4koff]

Как-то так:

A operator + (int i)
{
  A t(*this);  // создаём копию объекта, к которому прибавляем число
  t.d += i;  // собственно прибавление числа
  return t; // возвращаем результат. По сути тут сработает конструктор копии result(t)
}

Проблема будет с большими объектами, т.к. в данном случае получается создание 2-х временных объектов.

[still_alive]

Сообщение от BOBAH13

Трудно представить где такое понадобится ведь все есть объект, а ссылка есть ссылка. Зачем ссылка на ссылку? если нужна копия объекта, object retain. И все дела.

Для копии скорее copy, а не retain.
Итак, внутри объекта 1 указатель на объект 2. Внутри объекта 2 указатель на объект 1.
Нужно очень часто: как минимум при управлении кэшируемыми объектами и при реализации паттернов Composite/Observer/MVC.
Для примера рассмотрим Observer. Пусть у нас есть наблюдатели (скажем, куча таблиц и диаграмм) и субъект (данные). Внутри каждого наблюдателя должен быть указатель на субъект, внутри субъекта - список указателей на наблюдателей.
Получаем циклические ссылки (или по документации Mac OS X Reference Library - Retain Cycles) - а это недопустимо.
В той же документации (секция Weak References to Objects) предлагается следующее решение проблемы - не делать retain на наблюдателей, а просто внутри субъекта хранить слабые указатели на них.
Недостаток такого решения очевиден (правда есть и другое решение, а именно использование __weak, но оно уже полностью связано с GC) - если клиентский код удалил какого-нибудь наблюдателя, но забыл об этом оповестить субъект, то после следующего обновления данных субъект, пытаясь оповестить об изменении данных всех наблюдателей, наткнется на удаленного наблюдателя и программа вылетит.
В Objective C за этим надо следить ручками, а в C++ эту проблему прекрасно решает boost::weak_ptr.

Сообщение от BOBAH13

Надеюсь ясно вы просто не много не понимаете идею, ибо она очень отличается от идей языков delphi/c++/c# и многие другие.

Не понимаю, чем Reference Counting принципиально отличается во всех этих языках.

[Пепел Феникса]

Проблема будет с большими объектами, т.к. в данном случае получается создание 2-х временных объектов

получается что лучше б было +=?
(глупые вопросы, но хочу быть увереннее)

[pu4koff]

Сообщение от Пепел Феникса

получается что лучше б было +=?
(глупые вопросы, но хочу быть увереннее)

Да. Там без временных объектов можно обойтись.
Кстати, раз уж затронули эту тему... минус перегрузки операторов, используемой в плюсах, в дублировании кода.
Программисту логично, что b = b + 1 и b += 1 это одно и то же, а вот для компилятора это совершенно разные вещи. Можно конечно выражать += через оператор +, но тогда код будет далеко не самым оптимальным.
Есть повод подумать над своей гениальной перегрузкой, чтобы и без дублирования и не зависеть от порядка переменных (в С++ а + b не всегда тождественно b + a, если a и b разных типов, т.к. будут использоваться разные варианты перегрузки +).
За это я и не люблю С++. Язык позволяет многое, но по сути это выливается в кучу граблей и приходится самого себя ограничивать, дабы лоб не разбить. Так что думайте над своим творением более тщательно, чтобы потом не пришлось баги фичами называть