ООП: доступ к методу класса из-вне

[Лекс Айрин]

Это скорее к программе, не к коду.

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

Паскаль какраз и есть С с парой плюшек, только для людей, а не для роботов))

Я бы так не сказал. У Вас получается, что все языки одинаковы потому что в них используются одинаковые слова.
Описание правил паскаля, например, более компактное.

ООПом головного мозга тоже страдать ненадо, ооп подходы невсегда оправданы, зачастую проще какраз без них по другому.

вообще, ООП парадигма создавалась для облегчения написания большого объема сложноструктурированного кода. К сожалению, данная задача не выполнена в получивших широкое распространение языках. Да чего уж там... сейчас нет даже нормальной IDE заточенной под ООП. Лазарус наиболее подходящий из известных мне.

Также можно собирать ядро-зависимые проекты под неактуальную версию ядра, если нужны объявления в хэдекрах не изменились.

То есть, чтобы не исправлять косяки линкера/формата библиотеки нормальным решением считается создать костыль? Шикарно...

[zub]

Лекс Айрин
Голый си (не ++) в паскаль переводится почти 1 в 1 и никто не мешает говнякать на паскале также как на си - указатели и арифметика с ними в паскале есть)) Единственное ИМХО значимое отличие это наличие Interface\Implementation.

>>То есть, чтобы не исправлять косяки линкера/формата библиотеки нормальным решением считается создать костыль? Шикарно...
Аналог такого сишного .h в паскале это юнит с объявлением констант и внешних процедур\функций в Interface и пустой секцией Implementation

Mirage
>>Свои чтоли прикрутить к этому тесту...
Конечно прикрутить)) это конечно не совсем полноценный тест, но какоето представление о производительности дает, особенно о наличии "лишних - поэлементных" выделений памяти при постепенном заполнении контейнера от 0 до ...

скалогрыз
>>ну не обязательно использовать указатель, можно скажем TObject, и проверять тип в run-time, если нужно.
Если в контейнере хранить record`ы то от TObject`а проку никакого нет, да и проверка типа в рантайме никчему - она в compile-time нужна

[debi12345]

Аналог такого сишного .h в паскале это юнит с объявлением констант и внешних процедур\функций в Interface и пустой секцией Implementation

А где тогда описать имплементации-? Разве можно заюзать такой юнит в другом юните и прописать для его имплементацию ?

[Лекс Айрин]

переводится почти 1 в 1

ну нет... тут Вы не правы... некоторые конструкции С (любого) в паскале не повторить 1 к 1 -- он просто не будет это безобразие компилировать... например, вырожденный if /for

Аналог такого сишного .h в паскале это юнит с объявлением констант и внешних процедур\функций в Interface и пустой секцией Implementation

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

указатели и арифметика с ними в паскале есть))

это да... к сожалению, они нужны.

[zub]

debi12345
>>А где тогда описать имплементации-? Разве можно заюзать такой юнит в другом юните и прописать для его имплементацию ?
В соответствующей дллке. Мы разве не про хидеры для уже скомпиленых бинарников?

Лекс Айрин
>>например, вырожденный if /for
Пример? если только макрос какойнить придется в функцию переделать и вычисляться он будет в рантайме а не в компилтайме
А заменить хитрый for на repeat\while или union на вариативный рекорд или пересечение нескольких рекордов - по мне это 1 в 1

[Лекс Айрин]

Мы разве не про хидеры для уже скомпиленых бинарников?

вообще-то нет. Про использование стандартных скомпилированных библиотек.

Пример?

Код: Выделить всё

if() 
{}
else
{} 

-- в паскале подобное не запустится.

А заменить хитрый for на repeat\while или union на вариативный рекорд или пересечение нескольких рекордов - по мне это 1 в 1

но это НЕ так.

[zub]

if()
{}
else
{}
-- в паскале подобное не запустится.

И это не 1 в 1? Нет then, но принципиально это ничего не меняет

[debi12345]

Лично мне в Паскале очень не хватает DEFINE-макрорасширений подобного рода:

Код: Выделить всё

wchar_t* mb2wstr(const char* inval) {
    size_t size = strlen(inval);
#define OUTSZ (size+1)*sizeof(wchar_t)
    wchar_t* buf = (wchar_t*)malloc(OUTSZ);
    memset(buf, 0, OUTSZ);
    setlocale(LC_CTYPE,""); //  необходима, чтобы отработала "mbstowcs"
    size = mbstowcs(buf, inval, size);
    if ( size == (size_t)(-1) ) {
   free(buf);
   buf = NULL;
    } else {
   buf = (wchar_t*)realloc(buf,OUTSZ);
    }
    return buf;
#undef OUTSZ
}

но видимо на одно-проходовом (быстром) компиляторе это не вырулишь.

[скалогрыз]

Если в контейнере хранить record`ы то от TObject`а проку никакого нет, да и проверка типа в рантайме никчему - она в compile-time нужна

согласен от TObject-а проку не будет.

Но тогда правильно ли я понимаю, что данные из рекорда используются в только в этом самом дереве (т.е. даже если дубляж этих данных есть где-то ещё, то им можно принебречь), а сами рекорды маленькие (расход на копирование данных при сортировке "дерева").

[debi12345]

а сами рекорды маленькие (расход на копирование данных при сортировке "дерева").

Эти тесты измеряют оверхэды САМИХ контейнеров - именно поэтому выбраны самые миниатюрные (с наименьшим временем манипуляций в памяти) типа.

[zub]

скалогрыз
Незнаю, правильно ли я делаю, но хотелка примерно такая:
Высокоуровневые "сложные" примитивы - в дереве в виде ссылок на объекты в куче - так гораздо проще из любых соображений и их относительно немного - десятки тысяч.
Низкоуровневые - только в дереве (сам примитив это object c VMT). Массив низкоуровневых примитивов в ветке дерева это массив байтов в котором лежат инстансы примитивов, пробежка по этому массиву с учетом SizeOf каждого инстанса. Низкоуровневых примитивов очень много, и память под каждый выделять отдельно - медленно, надо выделять пачками. По другому не представляю как организовать "экономный" полиморфизм

[Лекс Айрин]

Нет then, но принципиально это ничего не меняет

вот как раз отсутствие then это ерунда. Данный код, перенесенный в паскаль, даже если добавить then вызовет ошибку времени компиляции.

[скалогрыз]

Незнаю, правильно ли я делаю, но хотелка примерно такая:

хорошо получается.

[debi12345]

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

Array of <type> => SetLength(<array>,<elements_of_type>) ? Это идеальный по эффективности способ. Обмен внутри такого массива тоже мгновенный - если делать как Мартин, применяя очень хорошо оптимизируемые под процы блочные MOVE-операции:

Код: Выделить всё

function additem(var dest: longwordarty; const value: longword;
                             var count: integer): boolean;
begin
 result:= false;
 if length(dest) <= count then begin
  setlength(dest,count+arrayminlenghtstep+2*length(dest));
  result:= true;
 end;
 dest[count]:= value;
 inc(count);
end;

Код: Выделить всё

procedure deleteitem(var dest: integerarty; index: integer);
begin
 if (index < 0) or (index > high(dest)) then begin
  tlist.Error(SListIndexError, Index);
 end;
 move(dest[index+1],dest[index],sizeof(dest[0])*(high(dest)-index));
 setlength(dest,high(dest));
end;

Код: Выделить всё

procedure insertitem(var dest: integerarty; index: integer; value: integer);
begin
 setlength(dest,high(dest) + 2);
 move(dest[index],dest[index+1],(high(dest)-index) * sizeof(dest[0]));
 dest[index]:= value;
end;

[runewalsh]

Лично мне в Паскале очень не хватает DEFINE-макрорасширений подобного рода:

Они есть:

Код: Выделить всё

{$macro on}
{$define sum :=
  (a + b)
{$undef a} {$undef b}}

x := {$define a := 2} {$define b := 3} sum;