Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Rifat

Страницы: 1 2 [3] 4 5
31
В одной из статей Ершова есть следующее определение.  "Роль деталей в сборочном программировании играют программные модули. Это – программы, обладающие определенной структурной и функциональной целостностью и в то же время специально приспособленные к тому, чтобы вступать в четко определяемое и контролируемое информационно-логическое взаимодействие с  другими модулями (под взаимодействием понимается или обмен информацией, или определенная соподчиненность выполнения).".
Если добавить параметризацию модулей, то мы потеряем в четко определяемом и контролируемом взаимодействии с другими модулями. Каждой такое взаимодействие нужно будет рассматривать с учетом его параметризации.

32
Идея с гнездами конечно интересная, но думаю, что это может усложнить программирование. Допустим, я открываю какой-нибудь исходник и вижу там 10 гнезд, чтобы понять что делает исходник мне надо будет открыть каждое из этих гнезд и возможно просмотреть еще и варианты этих гнезд, чтобы убедиться, что программа будет правильно работать с различными вариантами.

33
Общий раздел / Re:Oberon-07M
« : Март 27, 2011, 12:31:14 pm »
INC и DEC пока не реализованы, согласен, что они нужны, в ближайшее время они будут реализованы.

34
Изменять язык для препроцессора я не планирую. Я думаю, это это должна быть внешняя утилита, которая сначала обрабатывает файлы препроцессинга (допустим *.pre) и генерит на основе их ob7 файлы.

Кто что думает по поводу книги "Расширяемые программы" Горбунов-Посадов? Можно ли применить оттуда какие-нибудь идеи?

35
Общий раздел / Re:Oberon-07M
« : Март 25, 2011, 03:28:55 pm »
Я уже писал, что те кто не хочет чтобы в компиляторе были динамические массивы, могут просто их не использовать и считать что их просто нет. И использовать только те средства, которые были в описании языка Oberon-07.
C тем же успехом можно сказать, что в С++ нет адресной арифметики, нет множественного наследования, исключений и многого иного, что мешает иногда жить.
Читал какую-то статью, где рассказывалось о впечатлениях одного человека, когда он в каком-то году посетил программистский отдел Дойче банка в Германии. Он рассказывал, что они программировали на С++, но у них были такие строгие правила, что можно использовать и что нет, что их код на С++ был похож на код на Pascal-е.

Я сам работал в одной фирме, где программировали на C++, для нас там не существовал STL, было запрещено им пользоваться.

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

36
Общий раздел / Re:Oberon-07M
« : Март 25, 2011, 02:50:16 pm »
Я уже писал, что те кто не хочет чтобы в компиляторе были динамические массивы, могут просто их не использовать и считать что их просто нет. И использовать только те средства, которые были в описании языка Oberon-07.

37
Общий раздел / Re:Oberon-07M
« : Март 25, 2011, 02:40:36 pm »
А при чем здесь AnyRec, я его не упоминал?

38
Общий раздел / Re:Oberon-07M
« : Март 25, 2011, 02:11:35 pm »
Если добавить динамические массивы, то в моем понимании будет бОльшая симметрия:
1) Есть обычные записи и обычные массивы
2) Есть указатели на записи и указатели на фиксированные массивы
3) Указатель на запись может указывать на запись расширенного типа и указатель на массив может указывать на массивы разных размеров. :)

39
Общий раздел / Re:Oberon-07M
« : Март 25, 2011, 02:02:26 pm »
ARRAY 0 OF SomeType;
Если у нас ARRAY 1 OF SomeType, то компилятор должен разрешать обращение только к нулевому элементу массива arr[0].
А если ARRAY 0 OF SomeType, то ни к какому. И хотя вы выделите в библиотеке память для этого массива, обратиться к нему все равно нельзя будет.

40
Общий раздел / Re:Oberon-07M
« : Март 25, 2011, 12:44:02 pm »
Про динамические массивы: http://patrasyen.livejournal.com/10928.html

41
Общий раздел / Re:Oberon-07M
« : Март 25, 2011, 12:40:06 pm »
В Обероне-07 ЕСТЬ массивы длины неизвестной на момент компиляции. Система типов его существованию таких массивов никак не припятствует, достаточно свернуть ARRAY x OF y по первому аргументу, причем так, чтобы первый аргумент был не валиден для непосредственного обычного применения этого самого ARRAY x OF y (то есть чтобы его можно было создать только через функцию-процедуру NEW, но нельзя было создать его экзепляр просто так). Поэтому я и предлагаю использовать x=0.
Думаю, что только вы так считаете, что в Oberon-07 есть массивы неизвестной длины. Если использовать 0 для обозначения массивов неизвестной длины, то будут появляться странности, например:
rec1 = RECORD a: ARRAY 2 OF INTEGER END; размер rec1 = 8 байт
rec2 = RECORD a: ARRAY 1 OF INTEGER END; размер rec2 = 4 байта
rec3 = RECORD a: ARRAY 0 OF INTEGER END; размер rec3 = 8 байт.

42
Общий раздел / Re:Oberon-07M
« : Март 25, 2011, 12:05:07 pm »
Обсуждение пошло немного не в то русло. Попробую еще раз разъяснить что я хотел сказать.
В Обероне-07 Вирт убрал динамические массивы, есть только статические массивы и указатели на записи. Причины по которым убрали динамические массивы мне частично понятны, одна из причин в том, что компилятор становится проще без них. Но нет четкой альтернативы что использовать вместо динамических массивов, там где они раньше использовались, по крайней мере я о них не очень много знаю.
Недавно, разговаривал с одним моим другом, и я у него спросил, нужны ли динамические массивы в Обероне, его ответ меня несколько удивил, он сказал, он считает что они не нужны, что должен быть набор различных коллекций, как в Яве, типа хэш массив, еще какой-нибудь массив и т.д., а как они устроены внутри нас это не должно волновать. Допустим, мы решили идти по этому пути, реализовали коллекцию массив, которая внутри себя представляет какой-нибудь VList. Но при этом, у нас будет много избыточной вычислительной работы, которая будет скрыта внутри этого контейнера.
Так вот меня интересует мнение общественности, как они считают, динамический массив должен быть отнесен к разряду родных для языка или же статических массивов и указателей на записи вполне хватает для большинства применений, а в некоторых случаях можно просто запросить блок памяти у модуля SYSTEM и вручную с ним работать, но при этом естественно не будет контроля границ, а при работе с динамическим массивом будет.

43
Общий раздел / Re:Oberon-07M
« : Март 25, 2011, 11:33:11 am »
Насчет сигнатуры не важно, допустим это адрес записанный в переменную типа INTEGER.

Еще одноа проблема в том, что к полученным данным невозможно обращаться по индексу, допустим мне нужен байт с индексом 1000000 из этого массива, как мне его найти? Или мне для начала надо будет все эти данные сначала перегнать в какую-то коллекцию, типа VList?

44
Общий раздел / Re:Oberon-07M
« : Март 25, 2011, 11:14:17 am »
Поясню на всякий случай – мы тут размер не знаем ни на этапе компиляции, ни на этапе исполнения. Если после вызова функции нам оно скажет что "нишмогла, не поместилась в буфер даденого размера", то стратегия проста – удваиваем размер буфера и пробуем снова. Для удваивания буфера, как я заметил выше, массивы с размером неизвестным на этапе компиляции не нужны.
В принципе я знаю, как решается эта проблема, но насколько это решение будет красивым. Например, в какую-нибудь внешнюю функцию нужно передать указатель на непрерывный кусок памяти, допустим от 256 байт до 1 Гб.
Тогда это можно сделать следующим способом:
TYPE
r1 = RECORD a1: ARRAY 256 OF CHAR END;
p1 = POINTER TO r1;
r2 = RECORD (r1) a2: ARRAY 256 OF CHAR END;
p2 = POINTER TO r2;
r3 = RECORD (r2) a3: ARRAY 512 OF CHAR END;
p3 = POINTER TO r3;
r4 = RECORD (r3) a4: ARRAY 1024 OF CHAR END;
p4 = POINTER TO r4;
r5 = RECORD (r4) a5: ARRAY 2048 OF CHAR END;
p5 = POINTER TO p5;
p6 = RECORD (p5) a6: ARRAY 4096 OF CHAR END;
p6 = POINTER TO r6;
r7 = RECORD (r6) a7: ARRAY 8192 OF CHAR END;
p7 = POINTER TO r7;
r8 = RECORD (r7) a8: ARRAY 16384 OF CHAR END;
p8 = POINTER TO r8;
r9 = RECORD (r8) a9: ARRAY 32768 OF CHAR END;
p9 = POINTER TO r9;
r10 = RECORD (r9) a10: ARRAY 65536 OF CHAR END;
p10 = POINTER TO r10;
r11 = RECORD (r10) a11: ARRAY 131072 OF CHAR END;
p11 = POINTER TO r11;
r12 = RECORD (r11) a12: ARRAY 262144 OF CHAR END;
p12 = POINTER TO r12;
r13 = RECORD (r12) a13: ARRAY 524288 OF CHAR END;
p13 = POINTER TO r13;
r14 = RECORD (r13) a14: ARRAY 1048576 OF CHAR END;
p14 = POINTER TO r14;
r15 = RECORD (r14) a15: ARRAY 2097152 OF CHAR END;
p15 = POINTER TO r15;
r16 = RECORD (r15) a16: ARRAY 4194304 OF CHAR END;
p16 = POINTER TO r16;
r17 = RECORD (r16) a17: ARRAY 8388608 OF CHAR END;
p17 = POINTER TO r17;
r18 = RECORD (r17) a18: ARRAY 16777216 OF CHAR END;
p18 = POINTER TO r18;
r19 = RECORD (r18) a19: ARRAY 33554432 OF CHAR END;
p19 = POINTER TO r19;
r20 = RECORD (r19) a20: ARRAY 67108864 OF CHAR END;
p20 = POINTER TO r20;
r21 = RECORD (r20) a21: ARRAY 134217728 OF CHAR END;
p21 = POINTER TO r21;
r22 = RECORD (r21) a22: ARRAY 268435456 OF CHAR END;
p22 = POINTER TO r22;
r23 = RECORD (r22) a23: ARRAY 536870912 OF CHAR END;
p23 = POINTER TO r23;

(* Должна вернуть указатель на данные *)
PROCEDURE GetAnswer(VAR p: p1);
VAR t1: p1; t2: p2; t3: p3; t4: p4; t5: p5; t6: p6; t7: p7; t8: p8; t9: p9;
t10: p10; t11: p11; t12: p12; t13: p13; t14: p14; t15: p15; t16: p16; t17: p17; t18: p18; t19: p19;
t20: p20; t21: p21; t22: p22; t23: p23; t24: p24;
size: INTEGER;
BEGIN
   size := GetSize; (* Получаем размер данных *)
   IF size <= 256 THEN NEW(t1); p := t1
   ELSIF size <= 512 THEN NEW(t2); p := t2;
   ELSIF size <= 1024 THEN NEW(t3); p := t3;
   ELSIF size <= 2048 THEN NEW(t4); p := t4;
   ELSIF size <= 4096 THEN NEW(t5); p := t5;
   ELSIF size <= 8192 THEN NEW(t6); p := t6;
   ELSIF size <= 16384 THEN NEW(t7); p := t7;
   ELSIF size <= 32768 THEN NEW(t8); p := t8;
   ELSIF size <= 65536 THEN NEW(t9); p := t9;
   ELSIF size <= 131072 THEN NEW(t10); p := t10;
   ELSIF size <= 262144 THEN NEW(t11); p := t11;
   ELSIF size <= 524288 THEN NEW(t12); p := t12;
   ELSIF size <= 1048576 THEN NEW(t13); p := t13;
   ELSIF size <= 2097152 THEN NEW(t14); p := t14;
   ELSIF size <= 4194304 THEN NEW(t15); p := t15;
   ELSIF size <= 8388608 THEN NEW(t16); p := t16;
   ELSIF size <= 16777216 THEN NEW(t17); p := t17;
   ELSIF size <= 33554432 THEN NEW(t18); p := t18;
   ELSIF size <= 67108864 THEN NEW(t19); p := t19;
   ELSIF size <= 134217728 THEN NEW(t20); p := t20;
   ELSIF size <= 268435456 THEN NEW(t21); p := t21;
   ELSIF size <= 536870912 THEN NEW(t22); p := t22;
   ELSE NEW(t23); p := t23;
   END;
   (* Передаем выделенную память во внешнюю систему *)
   Answer(p^);
END GetAnswer;
(* Программу не компилировал, а просто написал, для примера *)

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

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

Страницы: 1 2 [3] 4 5