Автор Тема: Ассоциативный контейнер в оберонах  (Прочитано 39538 раз)

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Ассоциативный контейнер в оберонах
« Ответ #90 : Апрель 09, 2012, 03:26:05 pm »
Адреса объектов же могут совпадать в некоторых случаях. Так что GUID там скорее всего просто отдельным полем.

Это из серии "sin в военное время может достигать 3" ;) Если адреса совпадают, то это один объект :) Это у тебя тяжелое сишное детство проявляется: "раньше по этому адресу мог лежать другой объект и есть поинтер, который думает, что там еще тот другой объект" :)

Berserker

  • Sr. Member
  • ****
  • Сообщений: 254
    • Просмотр профиля
Re: Ассоциативный контейнер в оберонах
« Ответ #91 : Апрель 09, 2012, 03:27:12 pm »
Поправьте меня, если я ошибаюсь, но QT тоже вроде бы использует внешний препроцессор - и ничего. Для легковесного синтаксиса Оберона подобный написать не проблема.

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Ассоциативный контейнер в оберонах
« Ответ #92 : Апрель 09, 2012, 03:31:14 pm »
Адреса объектов же могут совпадать в некоторых случаях. Так что GUID там скорее всего просто отдельным полем.

Это из серии "sin в военное время может достигать 3" ;) Если адреса совпадают, то это один объект :) Это у тебя тяжелое сишное детство проявляется: "раньше по этому адресу мог лежать другой объект и есть поинтер, который думает, что там еще тот другой объект" :)
Ничего подобного. Про такое я не думал :-) Все много проще:
#include <iostream>

struct A {
    char b;
    char c;
};

int main()
{
    A a;
    a.b = 'c';
    std::cout
        << (std::size_t)&a << " "
        << (std::size_t)&a.b << std::endl;
    return 0;
}
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Ассоциативный контейнер в оберонах
« Ответ #93 : Апрель 09, 2012, 03:42:01 pm »
Ничего подобного. Про такое я не думал :-) Все много проще:

Ну да, оно самое, тяжелое сишное детство ;) Назови хоть один managed/safe/гермотипизированный язык где можно такое вытворять ;)

P.S. Да, давненько я не работал с сишно

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Ассоциативный контейнер в оберонах
« Ответ #94 : Апрель 09, 2012, 03:46:55 pm »
Ой, глючит форум... На самом деле пост был такой:

Ничего подобного. Про такое я не думал :-) Все много проще:

Ну да, оно самое, тяжелое сишное детство ;) Назови хоть один managed/safe/гермотипизированный язык где можно такое вытворять ;)

P.S. Это ж на самом деле "эмуляция наследования с помощью композиции", ООП по-сишному. Т.е., структуру A можно рассматривать как "наследника" char. И с этой точки зрения - это действительно один и тот же объект ;)

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Ассоциативный контейнер в оберонах
« Ответ #95 : Апрель 09, 2012, 03:47:27 pm »
Ничего подобного. Про такое я не думал :-) Все много проще:

Ну да, оно самое, тяжелое сишное детство ;) Назови хоть один managed/safe/гермотипизированный язык где можно такое вытворять ;)

P.S. Да, давненько я не работал с сишно
В обероне/кп будет в точности то же самое.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Ассоциативный контейнер в оберонах
« Ответ #96 : Апрель 09, 2012, 03:48:38 pm »
В обероне/кп будет в точности то же самое.

Нет, там не будет "адреса" (поинтера).

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Ассоциативный контейнер в оберонах
« Ответ #97 : Апрель 09, 2012, 03:55:28 pm »
В обероне/кп будет в точности то же самое.

Нет, там не будет "адреса" (поинтера).
SYSTEM :-)
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Ассоциативный контейнер в оберонах
« Ответ #98 : Апрель 09, 2012, 04:02:30 pm »
Нет, там не будет "адреса" (поинтера).
SYSTEM :-)

Речь шла о "managed/safe/гермотипизированный" ;)

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Ассоциативный контейнер в оберонах
« Ответ #99 : Апрель 09, 2012, 04:04:49 pm »
Нет, там не будет "адреса" (поинтера).
SYSTEM :-)

Речь шла о "managed/safe/гермотипизированный" ;)
Речь шла про GUID и адрес объекта. Внаружу safe обычно адрес объекта действительно не выставляет, но внутри он все равно есть. В некоторых случаях унутре адреса разных объектов/переменных могут быть одними и теми же, поэтому генерировать GUID чисто по адресу не стоит.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Ассоциативный контейнер в оберонах
« Ответ #100 : Апрель 09, 2012, 04:20:48 pm »
Речь шла про GUID и адрес объекта. Внаружу safe обычно адрес объекта действительно не выставляет, но внутри он все равно есть. В некоторых случаях унутре адреса разных объектов/переменных могут быть одними и теми же, поэтому генерировать GUID чисто по адресу не стоит.

1. Я бы предположил, что для тех сущностей, у которых есть GUID и которые "выставляются" в safe - адреса действительно разные.
2. Я говорил о корреляции, а не "чисто по адресу".
3. Генерация "полноценных" GUID в количествах соизмеримых с количеством "всех" объектов - кажется довольно дорогой операцией. Даже если не заказывать эти GUID у Microsoft по почте (как положено для получения самых правильных genuine GUID'ов) ;)
4. Очень может быть, что я не прав :)

DIzer

  • Гость
Re: Ассоциативный контейнер в оберонах
« Ответ #101 : Апрель 09, 2012, 05:18:08 pm »
То есть хотелось бы пример типа= для хранения данных которого нельзя построить безопасный контейнер и почему.
Любой пользовательский контейнер. Ну попробуй реализовать банальный типобезопасный связный список. Чтобы все элементы в нем были, как и положено, одного типа.
Угу - попробую, заинтересовали однако  :D.

Peter Almazov

  • Sr. Member
  • ****
  • Сообщений: 482
    • Просмотр профиля
Re: Ассоциативный контейнер в оберонах
« Ответ #102 : Апрель 09, 2012, 05:28:00 pm »
Кстати в 1С каждый объект имеет свой GUID. Думаю что все коллекции и контейнеры используют его для хеширования и индексации.
В принципе тоже вариант, если памяти не жалко  :)

У меня есть подозрение, что тамошний GUID имеет корреляцию с адресом объекта (если, конечно, там не перемещающий GC).
Да там GUID - это просто суррогатный первичный ключ в таблице. Причем не в каждой.
GC - на основе счетчика ссылок.

ilovb

  • Hero Member
  • *****
  • Сообщений: 2538
  • just another nazi test
    • Просмотр профиля
    • Oberon systems
Re: Ассоциативный контейнер в оберонах
« Ответ #103 : Апрель 10, 2012, 06:51:57 am »
Это не просто суррогатный ключ. Гуид - глобальный, т.е. гарантирует уникальность объекта не только в конкретной таблице. Кроме того он содержит информацию о типе.

Madzi

  • Jr. Member
  • **
  • Сообщений: 86
    • Просмотр профиля
Re: Ассоциативный контейнер в оберонах
« Ответ #104 : Апрель 10, 2012, 07:36:43 am »
Хотел ответить каждому, но накопилось много ответов, так что буду отвечать всем :)

1. "Message Bus" не панацея, есть множество способов как можно не потерять производительность (например, введя поле id).
2. Интерфейсов, как правило, много не реализуют в одном объекте (мне максимум встетилось 1 раз 7 интерфейсов). Проверка 1 или 7 последовательных значений не сильно усложнит проверку типа, и не сильно её затормозит.
3. Препроцессоры в обероне смысла не имеют! Поясняю:
Одними из ключевых принципов Оберона (как концепции, а не как языка) является единство исходного кода и реализации плюс одноразовость компиляции (нет необходимости в перекомпиляции исходников при каждой сборке). Что мы получаем в случае предпроцессора: Сгенерёный символьный файл и бинарный модуль будут отличатся от исходного файла, плюс (внимание, любители ifdef) возможно получение различного бинарного кода (символьного файла) при перекомпиляции (если будут другие условия). Вирт стремился к максимальной переносимости кода между системами и максимальной единообразности кода в различных системах, а препроцессоры способствуют получению разного кода в одной и той же системе (при чуть изменившихся условиях).

Уж лучше тогда подумать, как реализовать в обероне дженерики. Если оно вообще нужно.

С интерфейсами - всё проще. Интерфейс - это контракт, такой же как и запись, только на имена процедур у конкретного объекта. т.е., что конкретный объект будет обладать данными процедурами.
Например:
    Figure* = OBJECT
        VAR
            x, y : REAL;
            color : LONGINT;

        PROCEDURE &New*(x, y : REAL; color : LONGINT);
        BEGIN
            SELF.x := x;
            SELF.y := y;
            SELF.color := color;
        END New;
    END Figure;

    Drawable* = INTERFACE
        PROCEDURE Draw*(canvas : Raster.Raster);
    END Drawable;

    Point* = OBJECT(Figure, Drawable)
        PROCEDURE Draw*(canvas : Raster.Raster);
        BEGIN
            canvas.PutPixel(x, y, color);
        END Draw;
    END Point;

    GeomList* = ARRAY OF Drawable;

Т.е. принципиально, всегда в любой системе, у модуля будет один и тот же код, только реализуемая логика может получится значительно проще, чем без интерфейсов. Для интерфейсных методов, можно предусмотреть реакции по умолчанию. Т.е. если процедура не реализована в объекте, то она либо ничего не возвращает (пустая процедура), либо возвращает 0/0.0/NIL.