Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2007.01.28;
Скачать: [xml.tar.bz2];

Вниз

Сишные циклы FOR в Паскаль не переводятся?   Найти похожие ветки 

 
for   (2006-12-16 05:52) [0]

У них вообще по-моему это не циклы, а просто несколько присваиваний и условия в круглых скобках с надписью for спереди. То есть как while или until. А настоящих циклов for у них нет. Да?


 
Stexen ©   (2006-12-16 06:31) [1]

Ну а чем тебе сишный for не настоящий???Он наоборот более гибкий чем паскалевский и оч функциональный


 
Stexen2   (2006-12-16 07:02) [2]


> Stexen ©   (16.12.06 06:31) [1]
> Он наоборот более гибкий чем паскалевский


Например он открывает перед тобой возможности завесить цикл. А паскалевский такого не даёт, падла.


 
Думкин ©   (2006-12-16 07:19) [3]

> Stexen ©   (16.12.06 06:31) [1]

Гибкость Сишного цикла FOR полностью доступна чере While. А вот оптимальности Паскалевского FOR в Си нет.
Кстати, в статьях в статье про оптимизацию как раз на эту тему ошибка.


 
for   (2006-12-16 07:24) [4]

Можно ссылку на статью?


 
Думкин ©   (2006-12-16 07:34) [5]


> for   (16.12.06 07:24) [4]

Зайди в статьи на этом сайте - она вроде вторая сейчас там висит.
Но читай критически - статью по косточкам разобрали, - ошибок много.


 
Zeqfreed ©   (2006-12-16 08:46) [6]

Сам недавно занимался таким. Переводится, только циклом while :)

Например такой цикл:
while (p*p < PRIMES_SIZE) {
 for (idx = p*p; idx < PRIMES_SIZE; idx += p)
  primes[idx] = 0;
 while ((!primes[++p]) && (p < PRIMES_SIZE));
}


Я преобразовал в такой:
while (p*p <= High(primes)) do begin
 idx := p*p;
 while (idx <= High(primes)) do begin
  primes[idx] := false;
  Inc(idx, p);
 end;
 
 repeat
  Inc(p);
 until (primes[p]) or (p > High(primes));
end;


Должен признаться, что второй понять проще, но первый выглядит красивее :)


 
ors_archangel ©   (2006-12-16 09:29) [7]


> А паскалевский такого не даёт, падла.

Делфийский for можно заклинить, если использовать не integer, а dword.

>  А вот оптимальности Паскалевского FOR в Си нет.

Оптимальность компиляции в Delphi? Да, действительно, Делф не потянул бы гибкий C-for, он со своим-то еле еле справляется :( А вы видели, какой ужасный код генерит Делфи9 компилятор для for x in … - я уже боюсь расширений языка от Борланда, очень уж они тормознутые получаются :(
Мне в С нравится, что там вместо repeat…until - do…loop,  until всегда требует отрицания, что вообще плохой стиль: "if a" легче понять, чем "if not b", особенно, если высказывания - сложные, вот был бы дополнительно repeat…til - тогда нормально было бы. Борланд хочет, чтобы код выглядел красиво, но не прилагает почти никаких усилий, чтобы можно было писать "красиво" без опаски за скорость, вот, например, начинаешь юзать виртуальные методы, а для них вдруг почему-то smart linking отключается :) (он и не включался просто). FreePascal тоже хреново оптимизирует, но это энтузиастский проект ведь, а не от ведущей корпорации.


 
DiamondShark ©   (2006-12-16 10:36) [8]


> Делфийский for можно заклинить, если использовать не integer,
>  а dword.

Код давай.


> он со своим-то еле еле справляется

Гы, лол, сынку:)


> until всегда требует отрицания

until требует условия завершения.

Типа, матчасть учи, да.


 
Sha ©   (2006-12-16 10:48) [9]

> ors_archangel ©   (16.12.06 09:29) [7]
> Оптимальность компиляции в Delphi?


Оптимальность кода от языка зависит, но не в первую очередь.
В качестве примера - цикл перевода датной строки из формата
"yyyymmdd"T"hh":"nn":"ss" в TDateTime через DOS-представление на Delphi:

 Result:=false;
 if (i=17) and (pBeg[8]="T") and (pBeg[11]=":") and (pBeg[14]=":") then begin;
   i:=0;
   j:=0;
   while true do begin;
     ch:=ord(pBeg[i])-ord("0"); if cardinal(ch)>9 then break;
     if j=1 then ch:=w[j-1]*10+ch;
     w[j]:=ch*10;
     ch:=ord(pBeg[i+1])-ord("0"); if cardinal(ch)>9 then break;
     w[j]:=w[j]+ch;
     if i=15 then begin;
       Result:=TryEncodeDateTime(w[1], w[2], w[3], w[4], w[5], w[6], 0, Value);
       //DateTimeToString(FName,"yyyymmdd"T"hh":"nn":"ss",Value);
       //ShowMessage(FName);
       break;
       end;
     i:=i+1+((i+10) shr 3); //i=0,2,4,6,9,12,15
     j:=j+1;
     end;
   end;


В результирующем коде компилятора нет ни одного умножения,
ни одной лишней загрузки адреса. По-моему, он неплохо справился :)


 
Mystic ©   (2006-12-16 11:54) [10]

Чисто синтаксически у меня большая часть циклов repeat..until False, внутри которых есть Break. С этой точки зрения мне больше по душе конструкция цикла в Ada:


 loop
   Middle := (Left+Right) div 2;
   exit when A[Middle] = Value;
   if A(Middle) < Value then
     Left := Middle + 1
   else
     Right := Middle - 1;
   end if;
   exit whenM/b> Left > Right;
 end loop;


 
Palladin ©   (2006-12-16 11:56) [11]


> ors_archangel ©

парень ты встрял :) надо же столько ерунды нанести...


 
iZEN ©   (2006-12-16 14:41) [12]

Паскалевский for работает с переменными перечислимого типа. Это его ограничивает.
В Си и Java оператор for может работать с любыми значениями, даже с булевыми.


 
wicked ©   (2006-12-16 15:13) [13]

ну так же сказано - for в си-образных = while в паскале... а как вы уж код сложите - ваше дело... :)
спорить, что лучше, что хуже, считаю бессмысленным - это не принципиально, особенно в свете фишечек в обероне 1, отмененных в обероне 2... ;)


 
Eraser ©   (2006-12-16 15:13) [14]

> [12] iZEN ©   (16.12.06 14:41)

а толку с того, через while..do организовать такое же проще простого. см. [3].


 
iZEN ©   (2006-12-16 15:17) [15]


> Eraser ©   (16.12.06 15:13) [14]
>
> > [12] iZEN ©   (16.12.06 14:41)
>
> а толку с того, через while..do организовать такое же проще
> простого. см. [3].

Ну в while нельзя инициализировать ничего. Только ДО, в этом случае такие переменные получают большую область видимости, чем если бы они были инициализированы в теле цикла. А это чревато в многопоточном приложении. :))


 
Eraser ©   (2006-12-16 15:20) [16]

> [15] iZEN ©   (16.12.06 15:17)

а причем тут многопоточные приложения :) ? использовать для циклов не локальные переменные вообще мовитон! вон в C# даже локальные нельзя...


 
iZEN ©   (2006-12-16 15:22) [17]


> Eraser ©   (16.12.06 15:20) [16]
>
> > [15] iZEN ©   (16.12.06 15:17)
>
> а причем тут многопоточные приложения :) ? использовать
> для циклов не локальные переменные вообще мовитон!

Это где такая ересь объясняется?


 
Eraser ©   (2006-12-16 15:27) [18]

> [16] Eraser ©   (16.12.06 15:20)


> вон в C# даже локальные нельзя...

не читать, думал не то что писал ))

> [17] iZEN ©   (16.12.06 15:22)

почему же ересь? компилятор предупреждение выдает даже.


 
Anatoly Podgoretsky ©   (2006-12-16 15:29) [19]

> iZEN  (16.12.2006 14:41:12)  [12]

> В Си и Java оператор for может работать с любыми значениями, даже с булевыми.

for B  := Low(Boolean) to High(Boolean) do;


 
iZEN ©   (2006-12-16 15:31) [20]

Anatoly Podgoretsky ©   (16.12.06 15:29) [19], кстати да, Boolean - тоже перечислимый тип:

var b: Boolean;
begin
 for b := False to True do Button1.Caption := "Done.";
end;


 
vuk ©   (2006-12-16 17:17) [21]

to iZEN ©   (16.12.06 15:22) [17]:
>Это где такая ересь объясняется?
Это не ересь. В pascal for - цикл со счетчиком, в C - цикл с условием. Счетчик, он обычно не в переменной, а в регистре процессора. К тому же если параметр цикла живет в переменной, то возможны разные сторонние влияния на него даже не из того же самого потока.


 
iZEN ©   (2006-12-16 18:33) [22]


> vuk ©   (16.12.06 17:17) [21]
>
> to iZEN ©   (16.12.06 15:22) [17]:
> >Это где такая ересь объясняется?
> Это не ересь. В pascal for - цикл со счетчиком, в C - цикл
> с условием. Счетчик, он обычно не в переменной, а в регистре
> процессора. К тому же если параметр цикла живет в переменной,
>  то возможны разные сторонние влияния на него даже не из
> того же самого потока.
>

То же самое может происходить со счётчиком, я полагаю. Небезопасная конкуррентность с циклом — типичный пример для начинающих работать с потоками. В паскалевском цикле переменная счётчика имеет большую область видимости, так как объявляется перед блоком begin...end — она видима во вне цикла for, её можно использовать ДО, ВО ВРЕМЯ, ПОСЛЕ исполнения цикла совершенно из разных потоков/нитей (к сожалению, синхронизация в Delphi, и тем более в Pascal не развиты и основываются на полностью прикладных мьютексах и самафорах).

В Java (в данном случае я рассматриваю Java, а не Си, хотя для последнего тоже многое справедливо, за исключением многопоточности) невозможно использовать объявленную в нём переменную вне тела цикла. И, пусть поправят, если я не прав, нити, которые начинают выполнение одного и того же блока for, имеют разный контекст по работе с такой переменной — фактически имеют её копию в своём стэке, если блок for не защищён монитором от одновременного выполнения двух и более нитей).
Код:
public class DemoConcurrent {
public static void main(String[] args) {
 Worker w = new Worker();
 Thread t1 = new Thread(w);
 Thread t2 = new Thread(w);
 t1.start();
 t2.start();
}
}

class Worker implements Runnable {
private static int step = 1;
private int j = 0;
public void run() {
 System.out.println("step=" + step++);
 //synchronized (this) {
  for (int i = 0; i < 10; i++) {
   j = j +1;
   System.out.println("" + j + ": i=" + i);
  }
 //}
 System.out.println("step=" + step++);
}
}

Выдаёт:
step=1
step=2
1: i=0
2: i=0
3: i=1
4: i=1
5: i=2
6: i=2
7: i=3
8: i=3
9: i=4
10: i=4
11: i=5
12: i=5
13: i=6
14: i=6
15: i=7
16: i=7
17: i=8
18: i=8
19: i=9
step=3
20: i=9
step=4
Понятно, что переменная i фактически у каждой нити своя? (Каждая нить сохраняет значение переменной i в своём стэке, иначе цикл быстро бы завершился).

После раскомментирования блока synchronized нити будут захватывать монитор объекта w, какая первая получит монитор — та и начнёт выполняться, а вторая нить будет ждать, пока первая не покинет этот блок. Тело цикла будет выполняться сначала одной нитью, а потом другой:
step=1
step=2
1: i=0
2: i=1
3: i=2
4: i=3
5: i=4
6: i=5
7: i=6
8: i=7
9: i=8
10: i=9
11: i=0
12: i=1
13: i=2
14: i=3
15: i=4
16: i=5
17: i=6
18: i=7
19: i=8
20: i=9
step=3
step=4

Переменные j и step объявлены вне тела цикла, тем не менее, операции с ними осуществляется АТОМАРНО, так как они — переменные примитивных типов. Но по первому выводу ясно, что доступ может осуществляться в произвольный момент времени из любой нити. Если бы это были ссылочные переменные (например, на контейнер со счётчиками), то мы имели бы геморрой по поддержке синхронности этих счётчиков.


 
Eraser ©   (2006-12-16 20:30) [23]

> [22] iZEN ©   (16.12.06 18:33)

эт все конечно хорошо, но вот как только на Джаве можно будет писать программы, которые компилятся в полноценный 32/64 разрядный код для win32/64 вот тогда можно будет об этом вообще говорить..


 
Anatoly Podgoretsky ©   (2006-12-16 20:33) [24]

iZEN ©   (16.12.06 18:33) [22]
Локальные переменные в Паскале размещаются на стеке, изначально. Процедуры и функции в Паскале реентерабельны.


 
iZEN ©   (2006-12-16 20:35) [25]


> Eraser ©   (16.12.06 20:30) [23]
>
> > [22] iZEN ©   (16.12.06 18:33)
>
> эт все конечно хорошо, но вот как только на Джаве можно
> будет писать программы, которые компилятся в полноценный
> 32/64 разрядный код для win32/64 вот тогда можно будет об
> этом вообще говорить..

В этом нет необходимости, поскольку быстродействие Java байткода сравнялось с нативным кодом, а перекомпилировать баткод при переходе с 32 битной платформы на 64 битную не нужно.


 
iZEN ©   (2006-12-16 20:44) [26]


> Anatoly Podgoretsky ©   (16.12.06 20:33) [24]
>
> iZEN ©   (16.12.06 18:33) [22]
> Локальные переменные в Паскале размещаются на стеке, изначально.
>  Процедуры и функции в Паскале реентерабельны.

Это я знаю.
vuk ©   (16.12.06 17:17) [21] написал, что значение переменной счётчика цикла в Pascal помещается в регистр процессора. Я хотел показать, что операции над такими переменными не могут быть потокобезопасными. В Java защита производится автоматически (так как копия переменной создаётся на стэке каждой из нитей), невзирая на присутствие/отсутствие synchronized-блока.

Насколько я могу судить, в Pascal/Delphi невозможно атомарное изменение переменной счётчика цикла из разных потоков-нитей без использования мьютекса (функционального аналога явского synchronized-блока), так как переменная фактически принадлежит стэку процедуры, а не нити.


 
Anatoly Podgoretsky ©   (2006-12-16 20:48) [27]

> iZEN  (16.12.2006 20:44:26)  [26]

> Насколько я могу судить, в Pascal/Delphi невозможно атомарное изменение переменной счётчика цикла из разных потоков-нитей без использования мьютекса

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


 
Eraser ©   (2006-12-16 20:50) [28]

> [26] iZEN ©   (16.12.06 20:44)


> Насколько я могу судить, в Pascal/Delphi невозможно атомарное
> изменение переменной счётчика цикла из разных потоков-нитей
> без использования мьютекса (функционального аналога явского
> synchronized-блока), так как переменная фактически принадлежит
> стэку процедуры, а не нити.

можно и с накладными расходами явно меньшими, чем в Джаве.

> написал, что значение переменной счётчика цикла в Pascal
> помещается в регистр процессора. Я хотел показать, что операции
> над такими переменными не могут быть потокобезопасными.
> В Java защита производится автоматически (так как копия
> переменной создаётся на стэке каждой из нитей), невзирая
> на присутствие/отсутствие synchronized-блока.

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


 
iZEN ©   (2006-12-16 22:29) [29]


> Anatoly Podgoretsky ©   (16.12.06 20:48) [27]

В принципе, согласен.


> Eraser ©   (16.12.06 20:50) [28]
> повторюсь, для циклов надо использовать локальные переменные,
>  в противном случае компилятор выдаст предупреждение. что
> касается счетчика, так никто не мешает тоже выделить локальную
> переменную.

Приведите пример на Delphi.


 
Eraser ©   (2006-12-16 23:09) [30]

> [29] iZEN ©   (16.12.06 22:29)

насчет глобальной переменной в цикле
var
 Form1: TForm1;
 i: Integer;

implementation

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);
begin
 for i := 0 to 1 do
   beep;
end;

[Pascal Warning] Unit1.pas(28): W1019 For loop control variable must be simple local variable

насчет счетчика в отдельной переменной.
procedure TForm1.FormCreate(Sender: TObject);
var
 i, cnt: Integer;
begin
 cnt := Screen.FormCount;
 for i := 0 to cnt - 1 do
   beep;
end;

хотя со спокойной совестью можно писать и так
procedure TForm1.FormCreate(Sender: TObject);
var
 i: Integer;
begin
 for i := 0 to Screen.FormCount - 1 do
   beep;
end;


 
Anatoly Podgoretsky ©   (2006-12-16 23:13) [31]

> iZEN  (16.12.2006 22:29:29)  [29]

var
  I: Integer;
begin
  ...
end;


 
Stexen ©   (2006-12-17 01:50) [32]


> Думкин ©   (16.12.06 07:19) [3]
> > Stexen ©   (16.12.06 06:31) [1]
>
> Гибкость Сишного цикла FOR полностью доступна чере While.
>  А вот оптимальности Паскалевского FOR в Си нет.
> Кстати, в статьях в статье про оптимизацию как раз на эту
> тему ошибка.

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


 
Eraser ©   (2006-12-17 02:14) [33]

> [32] Stexen ©   (17.12.06 01:50)

уже давно посмотрели :)


 
Mystic ©   (2006-12-17 02:31) [34]

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


Тебе более приятно такое?

for(size_t i = N; i--; ) /* Body */ ;


 
Шашка   (2006-12-17 07:13) [35]


> Mystic ©   (17.12.06 02:31) [34]
> Тебе более приятно такое?
> for(size_t i = N; i--; ) /* Body */ ;

Вообще важно то, что цикл с счётчиком - это самостоятельная единица мышления. Которой в Си просто нету. Это как отказываться от умножения, и говорить, что ведь можно получить тот же результат путём сложения.

А ты вроде шашки когда то писал. Может ты знаешь, кто выигрывает в поддавках в начальной позиции ?


 
Anatoly Podgoretsky ©   (2006-12-17 09:22) [36]

> Stexen  (17.12.2006 1:50:32)  [32]

> сишный for с точки зрения кода выглядит по приятней...

Понятие приятности, это понятие красоты и технического определения не имеет. Мне например нравится естественность, вместо искуственности для шаманов.


 
Mystic ©   (2006-12-17 10:35) [37]

По поводу цикла for я имел в виду несколько другое. Конструкция цикла for в C/C++ более гибкая, которая дает код такой же по производительности код. Гибкость проявляется в том, что можно использовать цикл for почти везде, где надо пробежаться по некоторой совокупности данных, будь то список, вектор, проекция и т. д. При этом счетчик цикла не обязательно индекс, а может быть указатель, итератор, ... Но попробуем написать на C аналог цикла:

var
 I: Cardinal;
..............
for I := N-1 downto 0 do /* Something */ ;


Если пойти в лоб, то легко наступить на грабли:

for (size_t i=N-1; i>=0; --i) /* Something */ ;

Это бесконечный цикл ввиду того, что значения типа size_t всегда больше либо равно нуля. Можно вывернуться так, как было показано в [34] (17.12.06 02:31), но лично мне такой вариант не кажется приятным для чтения: столкнувшись с такой конструкцией впервые прийдется потратить некоторое усилие, чтобы разгадать загадку. Получается, что чрезмерная гибкость сишного цикла for дала щелчок по носу.

> Может ты знаешь, кто выигрывает в поддавках в начальной
> позиции ?


Бытует мнение, что поддавки посложнее шашек будут :) Вопрос пока открыт.


 
MBo ©   (2006-12-17 11:14) [38]

>Mystic ©   (17.12.06 10:35) [37]

В паскале при использовании беззнакового счетчика тоже можно напороться...

Часто встречается:
for ByteVar := 0 to List.Count - 1 do
при нулевом количестве элементов - облом


 
Sha ©   (2006-12-17 12:36) [39]

> MBo ©   (17.12.06 11:14) [38]

Наверно, поэтому нумерация символов в короткой строке с 1 начинается )


 
Думкин ©   (2006-12-17 14:09) [40]


> Stexen ©   (17.12.06 01:50) [32]

Все что может Сишный фор, я легко достигаю вайлом. И проблем ни в чем не вижу. А фор в Паскале - тут уже много напсали - условие окончаний считаетися единожды.
Т.е.

for(i=1;i<=length(c);i++){}

for i:=1 to length(c) do


Разные вещи. В паскале подобное достигается  

i := 1;
while i <= length(c) do begin
....
inc(i)
end;


Либо repeat...until;


 
vidiv ©   (2006-12-17 16:45) [41]

Блин, ну почему мой цикл зациклился :(

var i:integer;
begin
   for i:=0 to 100 do begin
     PInteger(@i)^ := 1;
   end;
end;


Чего вам так не нравится сишный for, помоему удобная штука, если понимать что к чему. А если не понимать, то может стоить подумать, над выбором профессии? :)


 
Anatoly Podgoretsky ©   (2006-12-17 18:18) [42]

> vidiv  (17.12.2006 16:45:41)  [41]

> Чего вам так не нравится сишный for

Потому что это не for, а while


 
Думкин ©   (2006-12-17 19:21) [43]

> vidiv ©   (17.12.06 16:45) [41]

Покажи пальцем где кому то он не нрпавится. И может не только о выборе профессии, но вообще - прежде чем говорить - стоит думать?


 
ANTPro ©   (2006-12-17 19:59) [44]

> [40] Думкин ©   (17.12.06 14:09)
> for i:=1 to length(c) do

Однако, это работает быстрее, чем :

> [40] Думкин ©   (17.12.06 14:09)
> i := 1;
> while i <= length(c) do begin


 
iZEN ©   (2006-12-17 20:41) [45]


> Anatoly Podgoretsky ©   (17.12.06 18:18) [42]
> > vidiv  (17.12.2006 16:45:41)  [41]
> > Чего вам так не нравится сишный for
> Потому что это не for, а while

Отчасти да, но это не вся правда. :)


 
Думкин ©   (2006-12-17 20:54) [46]

> ANTPro ©   (17.12.06 19:59) [44]

Это игра в слепоглухонемой телефон? Быстрее и что мне теперь с этим делать?


 
ANTPro ©   (2006-12-17 21:15) [47]

> [46] Думкин ©   (17.12.06 20:54)

Ничего, мысленно убрать из моего поста > [40] Думкин ©   (17.12.06 14:09)

> [46] Думкин ©   (17.12.06 20:54)
> Это игра в слепоглухонемой телефон?

:) , это что?


 
Думкин ©   (2006-12-18 05:43) [48]

> ANTPro ©   (17.12.06 21:15) [47]

Это когда раз сказанное, озвучивается вновь и вновь и вновь - как сломанная пластинка. :)


 
J_f_S   (2006-12-18 06:45) [49]

А теперб дружно смотрим ссылку
http://www.gamedev.ru/flame/forum/?id=58865
Уже не первый раз замечаю раздвоение темы тут, и на геймдеве, причем главный зачинщик проявляется только первым постом. Троллинг?


 
Думкин ©   (2006-12-18 06:50) [50]

> J_f_S   (18.12.06 06:45) [49]

По первой странице подобной же темы - там прямо заповедник ламеров.


 
Думкин ©   (2006-12-18 06:54) [51]

Впрочем и по остальным тоже.


 
vidiv ©   (2006-12-18 07:02) [52]


> Покажи пальцем где кому то он не нрпавится. И может не только
> о выборе профессии, но вообще - прежде чем говорить - стоит
> думать?

[42], например :)


> Anatoly Podgoretsky ©   (17.12.06 18:18) [42]
> Потому что это не for, а while

Для паскаля может и while, а для си как был конструкцией for так и остался. Есть отдельно while, есть там еще чтото (я в си не очень так). Я так думаю, что у компиляторов Си тоже есть оптимизатор, который сможет както оптимизировать for(i=0; i<10; i++), также как и delphi for i:=0 to 9 do...


 
Думкин ©   (2006-12-18 07:05) [53]


> vidiv ©   (18.12.06 07:02) [52]

Про не нравится, ттам все-таки слов нет. Но, то что это не аналог Паскалевскому фор - это так.

Думаешь, или так и есть?


 
vidiv ©   (2006-12-18 07:15) [54]


> Про не нравится, ттам все-таки слов нет.

Anatoly Podgoretsky, отвечает "Потому что это не for, а while" на вопрос "Чего вам так не нравится сишный for" => он согласен с тем что ОН (Сишный for) ему не нравится!


> Но, то что это не аналог Паскалевскому фор - это так.

А я не говорю что аналог. Сишный for имеет более широкие возможности, ввиду его особенности. И тем не менее запись for(i=0; i<10; i++) является аналогом for i:=0 to 9 do, если вы не согласны, то, пожалуйста объясните в чем разница? Только не надо говорить что это:
i:=0;
while i<10 do begin
...
inc(i)
end;

и ничто другое. Ибо паскалевский for - представляет собой тоже самое. То что там оптимизатор творит - это уже другой разговор.


 
Думкин ©   (2006-12-18 07:19) [55]


> Ибо паскалевский for - представляет собой тоже самое

Не то же самое. И оптимизатор ни при чем. Я же предлагал внчале обсуждения пройти в статьи.
http://www.delphimaster.ru/articles/optimization.html

Вынесение инвариантного кода за пределы цикла – не выносится. Наиболее распространенный недочет – условие цикла записывается как:

for i:=0 to memo1.lines.count – 1 do...

 Delphi будет при каждой итерации вызывать метод count, вычитать из результата 1 и потом уже сверять. Настоятельно рекомендуется переписывать подобный код как

lin := .lines.count – 1;
for i:=0 to lin do...

 Весь код VCL написан с нарушением этого правила. Очевидно, что проще подобного рода оптимизацию встроить в компилятор, нежели переписывать VCL :)


Так вот. Это не так. Сишный фор - будет, Паскалевский - ни разу.


 
vidiv ©   (2006-12-18 07:28) [56]

Это фенечка паскалевского for-а, не больше. Тем большее для случая который привел я - это как раз не принципиально. Конечно реализовать в Си эту фенечку в конструкции for достаточно трудно на первый взгляд - но думаю вполне возможно =)


> Сишный фор - будет, Паскалевский - ни разу.

1 раз всетаки будет =)


 
J_f_S   (2006-12-18 07:33) [57]

Иль самому керосинчека плеснуть?

1. А почему, все решили, что переменная в цикле должна быть одна?

for (int i = 0, int j = 30; i < j; i++, j--)

Запишите паскалевским фором, или вайлом, или рипит-антилом.

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

for(int i=0;;i++)


3. А еще, в цикле может изменяться не сама переменная цикла

for(int i =0; i < 10; j++)


4. А еще, в условии окончания цикла может быть не завязана на переменную цикла

for(int = 0; j < 10; i++)


Да много чего еще можно придумать.
Вывод - функциональность сишного фора гораздо больше паскалевского :-)


 
vidiv ©   (2006-12-18 07:36) [58]


> J_f_S   (18.12.06 07:33) [57]

во +1


 
Думкин ©   (2006-12-18 07:39) [59]

> vidiv ©   (18.12.06 07:28) [56]

Мы не про фенечки. Все-таки фор и вайл - различное поведение имеют, и к друг другу не сводятся. А в Си сводятся. Я не ругаю Си - это прерогатива ламеров, но какое приемущество, кроме записи дает фор перед вайлом там?

> J_f_S   (18.12.06 07:33) [57]

1. А сам не можешь? Текста поболее будет, но и все. Для понимания, возможно и проще.
2. ? и что?
3. ? И что?
4. ? И что?

Чем Сишный фор лучше его же Вайла? Записью?


 
vidiv ©   (2006-12-18 07:47) [60]


> Чем Сишный фор лучше его же Вайла? Записью?

ну вобщем да!

как и в паскале:
for counter := initialValue to finalValue do statement
это тоже что и

counter := initialValue;
endValue := finalValue;
while counter <= endValue do
begin
statement;
counter := Succ(counter);
end;


получается только записью


 
Думкин ©   (2006-12-18 07:51) [61]

> vidiv ©   (18.12.06 07:47) [60]

Не всегда. Хотя ты это назовешь фенечками компилятора. :)


 
J_f_S   (2006-12-18 07:56) [62]

1. В С такая запись имеет явную смысловую и логическую нагрузку, через while - тут будет горотьба из обьявлений переменных в одном месте программы, самого цикла, в цикле будут инкременты, плюс неявное условие.
2,3,4 - иногда так лучше написать.

Coupe de gras -
В цикле C/C++ в качестве переменных могут быть объекты (намекаю - итераторы стандартной библиотеки шаблонов) . Любые обьекты, у классов которых определены соответствующие операторы.


 
vidiv ©   (2006-12-18 07:58) [63]


> Не всегда.

А, например, когда?


 
for   (2006-12-18 07:59) [64]


> Mystic ©   (17.12.06 10:35) [37]
>
> По поводу цикла for я имел в виду несколько другое. Конструкция
> цикла for в C/C++ более гибкая,


Я о том, что целочисленный цикл - это инструмент мышления. Ему не нужна гибкость или больше возможностей.

Ему нужно последовательно перебирать целые числа. И всё.

Глядя на for ты сразу понимаешь что он делает. А глядя на сишные тебе надо обдумывать. В этом разница.


 
Думкин ©   (2006-12-18 07:59) [65]

> 2,3,4 - иногда так лучше написать.

Чем лучше?


 
Думкин ©   (2006-12-18 08:03) [66]

> vidiv ©   (18.12.06 07:58) [63]


for counter := initialValue to finalValue do statement;

Не будет эквивалентом:

counter := initialValue;
endValue := finalValue;
while counter <= endValue do
begin
statement;
counter := Succ(counter);
end;


Если statement не использует counter. Да, и в общем случае тоже возможно. Тут надо тех, кто ЦПУ любит смотреть спрашивать. МВо или Sha, например. Я пас.


 
J_f_S   (2006-12-18 08:09) [67]


> Чем лучше?

А это уже мелочь и придирка.

Насчет обьектов - цикл не обязатеьлно должен быть целочисленным. Это - ограниченность взгляда программиста. Очень часто стоит задача последовательного перебора некоторого множества обьектов, к чему я собственно, STL и вспоминал. В С for-е можно пребрать некоторое множество из отображения (контейнера) . В паскале такого вопроса не стоит в виду отсутствия шаблонов (Всем молчать!), соответственно, контейнеров и их итераторов. Хотя, хотя, тут была бы более логичной концепция for_each, но она не стандартизована (она есть в бусте).


 
Думкин ©   (2006-12-18 08:13) [68]

> J_f_S   (18.12.06 08:09) [67]

Это мы уже в другое ударяемся. Все-таки изначально влопрос ставился иначе.
Циклы фор из Си не реализуются фором в Паскале. Фор Паскаля не реализуется на Си также.
То есть это два разные Фор. И все.


 
J_f_S   (2006-12-18 08:16) [69]

Если ставить вопрос как "Одинаковые ли это форы" - ответ, конечно, "нет".
А вот если задать вопрос - "Что мощнее", то тут можно смотреть выше по топику.


 
Mystic ©   (2006-12-18 08:44) [70]

> 1. А почему, все решили, что переменная в цикле должна быть одна?
for (int i = 0, int j = 30; i < j; i++, j--)

Противоречит стандарту, правильно:
for(int i=0, j=30; i<j; ++i, --j)

> 3. А еще, в цикле может изменяться не сама переменная цикла
for(int i =0; i < 10; j++)

Это скорее преимущество паскалевкого варианта цикла for, где так ввести в заблуждение человека, читающего код, нельзя :) Теоретически можно написать файловый менеджер, где повесить на клавишу Esc функции по удалению файлов :)

Вообще c С++ довольно-таки забавная история: вначале пишут гибкий язык программирования, потом на фирмах вводят стандарты кодирования, которые запрещают использование некоторых возможностей :) К тому сейчас в моде, пользоваться готовыми алгоритмами STL, например так:

template<class Arg, class Result>
std::unary_negate<std::pointer_to_unary_function<Arg, Result> >
 ptr_not_fun(Result (*pfunc)(Arg))
{
 return std::not1(std::ptr_fun(pfunc));
}

inline void skip_spaces(string::iterator& pos, string::iterator end)
{
pos = find_if(pos, end, ptr_not_fun(&isspace));
}


 
Anatoly Podgoretsky ©   (2006-12-18 13:24) [71]

> vidiv  (18.12.2006 7:02:52)  [52]

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


 
Anatoly Podgoretsky ©   (2006-12-18 13:27) [72]

> vidiv  (18.12.2006 7:02:52)  [52]

Теперь замени i<10 на что ни будь более серьезное, наприме на функцию, а еще лучше на List.Count и особенно сделай в цикле, что бы этот Count увеличивался и тогда посмотрим, что будет.


 
Anatoly Podgoretsky ©   (2006-12-18 13:30) [73]

> J_f_S  (18.12.2006 8:09:07)  [67]

> Насчет обьектов - цикл не обязатеьлно должен быть целочисленным. Это - ограниченность взгляда программиста.

И математиков, не много на себя берешь?


 
Anatoly Podgoretsky ©   (2006-12-18 13:33) [74]

> Думкин  (18.12.2006 8:13:08)  [68]

Не два разных FOR а два разных цикла, что из того, что использовано одно и тоже имя, в других языках например может использоваться другое имя. Разница в сущности - в Паскале цикл с именем FOR соответствует математике. И есть другие циклы, не только этот. Сущности разделены.


 
Anatoly Podgoretsky ©   (2006-12-18 13:34) [75]

> J_f_S  (18.12.2006 8:16:09)  [69]

> А вот если задать вопрос - "Что мощнее",

А если задать другой вопрос, насколько хорошо я знаю общую теорию программирования, математику, вот этот вопрос будет правильнее. А не крутить пальцы, мол мощнее, при этом не разбираясь в предмете.


 
Думкин ©   (2006-12-18 13:34) [76]


> Anatoly Podgoretsky ©   (18.12.06 13:33) [74]

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


 
J_f_S   (2006-12-18 13:45) [77]


> Anatoly Podgoretsky ©   (18.12.06 13:30) [73]
>
> > J_f_S  (18.12.2006 8:09:07)  [67]
>
> > Насчет обьектов - цикл не обязатеьлно должен быть целочисленным.
>  Это - ограниченность взгляда программиста.
>
> И математиков, не много на себя берешь?


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


 
Игорь Шевченко ©   (2006-12-18 13:55) [78]

Думкин ©   (18.12.06 07:39) [59]


> Чем Сишный фор лучше его же Вайла? Записью?


Строчек меньше


 
Думкин ©   (2006-12-18 13:57) [79]

> Игорь Шевченко ©   (18.12.06 13:55) [78]

То есть записью. Речь же все-таки об ином шла. Впрочем опять патефон начинается.


 
Anatoly Podgoretsky ©   (2006-12-18 13:58) [80]

> Думкин  (18.12.2006 13:34:16)  [76]

Нормально получается, я твое сообщение видел.
Кашу маслом не испортишь, ты в одном контексте, я в другом, но мельница вертится.


 
Anatoly Podgoretsky ©   (2006-12-18 13:59) [81]

> J_f_S  (18.12.2006 13:45:17)  [77]

Красиво излагаешь :-)


 
J_f_S   (2006-12-18 14:00) [82]

Еще могу :-)

Для каких задач используются циклы?
1. перебор какого-либо множества
Если если множество - линейный вектор, (e.g. массив), с исключительно целочисленными индексами, то это только частный случай. Допустим, сейчас я связан с одним ГИС проектом, и у меня в программе хранится различная информация - точки, грани, полигоны, страны и .т.д - хранятся в различных множествах, (контейнерах), причем прямой индексации они могут и не иметь, в роли индексов могут быть обьекты (и даже списки обьектов), но суть одна - это упорядоченное множество, которое нужно перебрать, соответсвенно, используя связку for + iterators - перебор столь нетривиальной по меркам паскаля задачи прост и нагляден.

2. последовательное изменение некой переменной.
Опять же, а почему переменная - не обьект?


 
clickmaker ©   (2006-12-18 14:03) [83]


> for + iterators - перебор столь нетривиальной по меркам
> паскаля задачи прост и нагляден

iterator - не языковая конструкция. Их вполне можно и в паскале писать


 
Anatoly Podgoretsky ©   (2006-12-18 14:03) [84]

> J_f_S  (18.12.2006 14:00:22)  [82]

Частности и варианты записи.
А циклов все равно как минимум три, с перечислением, с предусловием и с постусловием. Ну и плюс беспоконечный, без условий.


 
J_f_S   (2006-12-18 14:11) [85]


> clickmaker ©   (18.12.06 14:03) [83]
>
>
> > for + iterators - перебор столь нетривиальной по меркам
>
> > паскаля задачи прост и нагляден
>
> iterator - не языковая конструкция. Их вполне можно и в
> паскале писать


STL - стандартизована как подмножество языка в каком-то девяносто - лохматом году (лень мне искать :-(). Соответсвенно, каждый современный (выпущенный за последние десять лет) компилятор обладает поддержкой стандартной библиотеки шаблонов.


> Anatoly Podgoretsky ©   (18.
> А циклов все равно как минимум три, с перечислением, с предусловием
> и с постусловием. Ну и плюс беспоконечный, без условий.
>

Тут спорить грешно. Но я, собственно, ничего против и не говорил.


 
Игорь Шевченко ©   (2006-12-18 14:16) [86]

Думкин ©   (18.12.06 13:57) [79]


> То есть записью.


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


 
Думкин ©   (2006-12-18 14:18) [87]


> Игорь Шевченко ©   (18.12.06 14:16) [86]

С религией спорить трудно. %) Не буду.


 
Anatoly Podgoretsky ©   (2006-12-18 14:22) [88]

> Игорь Шевченко  (18.12.2006 14:16:26)  [86]

Помнится тут приводили строчки из СИ и Паскаля, строчек минимум - одна строка, красота неописуемая.


 
Eraser ©   (2006-12-18 14:59) [89]

> J_f_S

тут уже Думкин и Anatoly Podgoretsky по десят раз повторили, что циклы for в делфи и в C реализованы по-разному, разная философия у этих циклов.
Делфевский цикл может оказаться НАМНОГО быстрее, особенно если работать с объектом, у которого значение, к примеру, свойства count требует значительных вычислительных затрат, что вполне может встретится в реальном проекте. Обойти это можно только добавив доп. переменную.

что касается всяких экзотических вариантов цикла for типа как в [57], часто приходится ими пользоваться.
думаю если проанализировать код большенства проектов на C, выяснится, что подавляющее большенсто циклов - самый примитивный вариант for(int i =0; i < 10; i++), т.е. обычный паскалевский for..to.


 
Eraser ©   (2006-12-18 15:00) [90]

> часто приходится ими пользоваться.

это вопрос :)


 
iZEN ©   (2006-12-18 15:00) [91]

Так давайте же закроем тему с итоговым ответом на поставленный вопрос.

Сишные циклы FOR в Паскаль не не переводятся, но перевод сопряжон с пониманием семантики оператора FOR в этих языках и умением вложить в прокрустово ложе Паскалевского цикла FOR эту трепетную лань — Сишный оператор for. :)


 
Anatoly Podgoretsky ©   (2006-12-18 15:03) [92]

> iZEN  (18.12.2006 15:00:31)  [91]

Все переводится туда и обратно, просто слова разные.


 
vidiv ©   (2006-12-18 17:53) [93]


> Anatoly Podgoretsky ©   (18.12.06 13:27) [72]
>
> Теперь замени i<10 на что ни будь более серьезное, наприме
> на функцию, а еще лучше на List.Count и особенно сделай
> в цикле, что бы этот Count увеличивался и тогда посмотрим,
>  что будет.

Можешь это в новичках советовать. Как заменить i<10 на чтонибудь серьезное я знаю, не хуже тебя!


> Думкин ©   (18.12.06 14:18) [87]
> С религией спорить трудно. %) Не буду.

А, Игорь Шевченко - бог или жрец ??? :))

> Eraser ©   (18.12.06 14:59) [89]
>
> тут уже Думкин и Anatoly Podgoretsky по десят раз повторили,
>  что циклы for в делфи и в C реализованы по-разному, разная
> философия у этих циклов.
не философия, если уж на то пошло, а логика.
> Делфевский цикл может оказаться НАМНОГО быстрее, особенно

чушь :(
> если работать с объектом, у которого значение, к примеру,
>  свойства count требует значительных вычислительных затрат,
>  что вполне может встретится в реальном проекте. Обойти
> это можно только добавив доп. переменную.

Это кем надо быть, чтобы в реальном проекте не учитывать примерную скорость вычисления Count.
В крайнем случае можно написать:
for i:=pred(Obj.Count) downto 0 do - тогда гораздо нагляднее будет видно, что Count будет вычислен только раз


 
vidiv ©   (2006-12-18 17:54) [94]

блин напутал я с < i > =)


 
Anatoly Podgoretsky ©   (2006-12-18 17:58) [95]

> vidiv  (18.12.2006 17:53:33)  [93]

> заменить i<10 на чтонибудь серьезное я знаю, не хуже тебя!

Очень заметно.


 
vidiv ©   (2006-12-18 18:00) [96]


> Anatoly Podgoretsky ©   (18.12.06 17:58) [95]
>
> Очень заметно.

Конечно, у тебя же телепатор есть :)


 
Anatoly Podgoretsky ©   (2006-12-18 18:05) [97]

> vidiv  (18.12.2006 18:00:36)  [96]

У меня есть глаза, достаточно посмотреть твои темы, практически все они оказываются в начинающих, к сожалению ниже конференции у нас нет.


 
vidiv ©   (2006-12-18 18:07) [98]


> Anatoly Podgoretsky ©   (18.12.06 18:05) [97]
> У меня есть глаза, достаточно посмотреть твои темы, практически
> все они оказываются в начинающих, к сожалению ниже конференции
> у нас нет.

Мы видим только то что хотим видеть ;)

ЗЫ. я достаточно редко задаю вопросы и тем не менее обычно они остаются без ответа, так что...


 
vidiv ©   (2006-12-18 18:09) [99]

Тем более речь здесь идет не о каких либо технологиях, а об основах программирования.


 
Anatoly Podgoretsky ©   (2006-12-18 18:09) [100]

> vidiv  (18.12.2006 18:07:38)  [98]

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


 
vidiv ©   (2006-12-18 18:15) [101]


Anatoly Podgoretsky ©   (18.12.06 18:09) [100]
> Вот так и остаешься без ответов.

Да тем и лучше. Ибо есть радость собственного познания.

А ты, Анатолий, мне кажется, слишком самовлюблен!


 
Anatoly Podgoretsky ©   (2006-12-18 18:20) [102]

> vidiv  (18.12.2006 18:15:41)  [101]

Проблемы у тебя, а влюблен я


 
XProger ©   (2006-12-18 18:21) [103]

for (int i = 0, min = a[i]; i < N; min = a[i] < min ? a[i] : min, i++);
я конечно понимаю что "мала букф" в этом поиске минимального элемента, но выглядит, извиняюсь, уродливо, и никак не удобочитаемо )


 
vidiv ©   (2006-12-18 18:32) [104]


> Anatoly Podgoretsky ©   (18.12.06 18:20) [102]
>
> Проблемы у тебя, а влюблен я

С чего ты взял что у меня проблемы?
Но ты начинаешь унижать человека, если он интересуется и чегото не понимает, или еще хуже, если какойто учитель-"дятел" неправильно научил его и он не понимает чегото в корне. Это видно в тойже конференции новечков, хотя само название конференции предписывает проявлять сдержанность. Скажи, для чего? Показать что ты знаешь больше других? Это понятно, опыт ёпт. Или другая причина есть?


 
Anatoly Podgoretsky ©   (2006-12-18 18:37) [105]

> vidiv  (18.12.2006 18:32:44)  [104]

Я веду дисскуссию в стиле оппонента.
Так что к зеркалу.


 
vidiv ©   (2006-12-18 18:41) [106]


> Anatoly Podgoretsky ©   (18.12.06 18:37) [105]

На вопрос ответишь?


 
Anatoly Podgoretsky ©   (2006-12-18 18:42) [107]

> vidiv  (18.12.2006 18:41:46)  [106]

На какой вопрос?
По моему по поводу перевода Сишных циклов в Паскаль уже все сказано, даже с кодом.
Зачем повторяться?


 
vidiv ©   (2006-12-18 18:47) [108]


> Anatoly Podgoretsky ©   (18.12.06 18:42) [107]

Не на этот... И все же,
Предлагаю прекратить диалог. Никаких положительных эмоций...


 
Anatoly Podgoretsky ©   (2006-12-18 19:10) [109]

> vidiv  (18.12.2006 18:47:48)  [108]

Так зачем же заводил, мазохист что ли?


 
Горгер ©   (2006-12-18 19:11) [110]

Напишите 2 проги на Си и Паскале с циклом for и отдебужьте тем же Turbo Debugger.Я вообще принципиальной разницы не заметил...


 
vidiv ©   (2006-12-18 19:12) [111]


> Anatoly Podgoretsky ©   (18.12.06 19:10) [109]
> Так зачем же заводил, мазохист что ли?

Мне не нравится, что ктото недооценивает моего понимания. Моя ошибка в том, что я начал доказывать чтото


 
Anatoly Podgoretsky ©   (2006-12-18 19:23) [112]

> vidiv  (18.12.2006 19:12:51)  [111]

Поддаешься психологическому программированию.


 
vidiv ©   (2006-12-18 19:24) [113]


> Anatoly Podgoretsky ©   (18.12.06 19:23) [112]
> Поддаешься психологическому программированию.

Может быть, если это так называется. Но в любом случае мне это не нравится


 
J_f_S   (2006-12-18 21:07) [114]

Последний пост темы по существу это сообщение
>iZEN ©   (18.12.06 15:00) [91]

После него все можно потереть.


 
for   (2006-12-19 05:24) [115]


> Думкин ©   (18.12.06 08:13) [68]
>
> > J_f_S   (18.12.06 08:09) [67]
>
> Это мы уже в другое ударяемся. Все-таки изначально влопрос
> ставился иначе.
> Циклы фор из Си не реализуются фором в Паскале. Фор Паскаля
> не реализуется на Си также.


Чушь. Именно из Паскаля в Си for легко переводится. А вот обратно - часто никак.

Попробуй напиши программу перевода такого цикла в Паскаль:

 for (int j = i + i; j < sievesize; j += i)
    sieve[j] = 0;


Умом то ведь ты понимаешь как это перевести. Но программу то написать как ?


 
Думкин ©   (2006-12-19 06:25) [116]

> for   (19.12.06 05:24) [115]

Дяд Петя, ты дурак? (с)

В Си получается не аналогичная Паскалю конструкция.Ну сколько можно об этом говорить? Нет некоторы определенно стоит жевать.

> Умом то ведь ты понимаешь как это перевести. Но программу
> то написать как ?

Если понимаю умом, то и за программой не заржавеет. Вы намекаете на плохую формализацию Си? Ну так вы первый это высказали.


 
Думкин ©   (2006-12-19 06:39) [117]

> > for   (19.12.06 05:24) [115]

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


 
Anatoly Podgoretsky ©   (2006-12-19 10:27) [118]

> for  (19.12.2006 5:24:55)  [115]

А зачем программу писать, написание займет кучу времени, а руками перевести 30 секунд.


 
vidiv ©   (2006-12-19 10:41) [119]


> Попробуй напиши программу перевода такого цикла в Паскаль:
>
>
>  for (int j = i + i; j < sievesize; j += i)
>     sieve[j] = 0;

str_replace("for (int j = i + i; j < sievesize; j += i)\n sieve[j] = 0;", "for j:=i+i to pred(sievesize) div i do seive[j*i]=0", $code); =)

на самом то деле ничего сложного =)


> Умом то ведь ты понимаешь как это перевести. Но программу
> то написать как ?

как уже тут сказали, сишный for скорее соостветствует паскалекскому while
, поэтому перевести достаточно просто.

ЗЫ. Спорить на эту тему также глупо, как и доказывать, что слово, к примеру, СЕВЕР, не переводится на английский язык, т.к. запись "CEBEP" не означает сторону света, край ..., если вообще чтолибо означает.


 
Solution   (2006-12-21 01:53) [120]

Удалено модератором


 
Плохиш ©   (2006-12-21 02:13) [121]


> Solution   (21.12.06 01:53) [120]


> Ты глухой что ли ? Тебе сказали в for перевести, а не в
> while.

Идиоты зажигают...


 
Германн ©   (2006-12-21 02:31) [122]

2 Solution   (21.12.06 01:53) [120]
Имхо, налицо нарушение правил данного форума, а именно п.5 из "Запрещается".
Да и п.1 в части "хамства", тоже.


 
Solution   (2006-12-21 03:25) [123]

Удалено модератором


 
Думкин ©   (2006-12-21 05:41) [124]

> Solution   (21.12.06 01:53) [120]

Оно понятно. Но где объяснение? Жевать - однозначно. :)


 
See   (2006-12-23 05:59) [125]

А вы, между прочим, тут зря на GameDev наезжаете! Некрасиво.


 
Думкин ©   (2006-12-23 06:19) [126]

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


 
Celades ©   (2006-12-23 09:27) [127]


> 90% обитающих там ламеры или около, что не мешает быть небольшому
> проценту действительно грамотных людей.

На этом форуме таже картина. Это проблема всех программистских ресурсов.


 
Anatoly Podgoretsky ©   (2006-12-23 10:34) [128]

> Celades  (23.12.2006 9:27:07)  [127]

А соотношение 10:90 действует везде


 
AM   (2006-12-23 15:13) [129]

Думкин, вы так уверены, что те люди судят о том, о чем имеют смутное представление? И что они такого написали на 1ой странице, что заставило вас сделать такой вывод? Кстати, писать, что "оптимальности Паскалевского Фор в Си нет" - это полный бред. Единственная оптимальность тут - программист набирает меньше букв. Какую ещё вы оптимальность нашли? Вы хоть асм-то знаете, не говоря уже о более тонких вещах? Вот только не надо приводить тут в довод List.Count, ибо это не оптимизация, это условие работы цикла (кстати, на плюсах такое тоже можно реализовать, так что с вашим заявление вы поспешили. Как? А вот любой нормальный программист надо легко ответит, если не сможете сами, то я вам помогу). Да и вообще, про какую оптимальность идет речь, если Делфи не инлайнит?

Ну, или наверное "Разница в сущности - в Паскале цикл с именем FOR соответствует математике" - это просто верх крутости. Какой математике он соответствует? Что-то я не встречал этого соответствия ни в матанализе, ни в теории множеств, ни в теории автоматов...

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


 
Palladin ©   (2006-12-23 18:01) [130]

еще один чудик... откуда такие воинственные берутся, навереное с gamedev.ru...
сайт не плохой, и есть там нормальные люди, посты которых я читаю с удовольствием, а иногда затаив дыхание, но вот подобные АМ, не до конца понимающие когда именно и что именно оптимальней использовать... рассказывающие что все мы тут на лыжах по пляжу... в общем, позорят они этот сайт...


 
ors_archangel ©   (2006-12-23 18:27) [131]


> Sha ©   (16.12.06 10:48) [9]

Да, у меня тоже были случаи, когда я доводил pascal-код до того, что он работал почти как асм, но вот другой пример - враппер для функции перечисления всех консольных переменных:

function ForEachCVarWrapper(name: string; cvar: PCVar; wrapdata: PForEachCVarWrapData): boolean;
begin
 result := wrapdata.callback(name, wrapdata.param);
{ вот, что делает в таких случаях Deлфя: )
//// begin
 пушъ ebp        // стек, а как же без него
 мув ebp,esp
 пушъ ecx
 пушъ ebx
 мув ebx,ecx
 мув [ebp-4],eax
 мув eax,[ebp-4]  // абсолютно бессмыленно !
 колл @LStrAddRef    // увеличиваем ref-count строки (см.ниже)
 xор eax,eax
 пушъ ebp
 пушъ $0046dec4            // SEH, а вдруг что случится?!
 пушъ dword ptr fs:[eax]
 мув fs:[eax],esp
//// result:=wrapdata.callback(name, wrapdata.param)
 мув edx,[ebx+4]      // вот, собственно, сам код
 мув eax,[ebp-4]      // я насчитал три строчки
 колл dword ptr [ebx] // а это, наконец-то, вызов wrapdata.callback
 мув ebx,eax
 xор eax,eax
 поп edx
 поп ecx          // восстанавливаем стек
 поп ecx
 мув fs:[eax],edx   // SEH  
 пушъ $0046decb
 леа eax,[ebp-4]
 колл @LStrClr // уменьшаем ref-count (а зачем было увеличивать?)
 рет
 jмп @HandleFinally  // SEH
 jмп -$10       // довльно интересно
 мув eax,ebx
//// end
 поп ebx           // восстанавливаем стек - не два раза,
 поп ecx           // а для разных ветвей (ветвей!)
 поп ebp
 рет
end;

Конечно, можно было уменьшить раздумья dcc, сделав
const name, но на тот момент уже был код, который юзал не-const name,
не хотелось всё переписывать, поэтому написал сам:

asm
   mov   edx,[ecx].TForEachCVarWrapData.param
   jmp   [ecx].TForEachCVarWrapData.callback
end;

Есть разница?


 
vidiv ©   (2006-12-23 18:40) [132]


> еще один чудик... откуда такие воинственные берутся, навереное
> с gamedev.ru...

Внимания женского недостаточно, видимо :D


 
AM   (2006-12-23 20:33) [133]

Palladin, мы знакомы? Вы видели хоть 1 строчку моего кода? Если нет, то претензии по "когда именно и что именно оптимальней использовать" предъявляйте к тому, что я написал, а не к чему-то эфемерному. А то складывается соответствующее впечатление о вашей квалификации.

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


 
Palladin ©   (2006-12-23 20:54) [134]


> [133] AM

Ну представте 1 строчку вашего кода, раз вы так глупы, что бы считать, что по, лишь по одной строчке, я смогу судить об уровне в целом. Не впечатляет... Вокруг да около... Необоснованной грязи у себя я не увидел, это лишь была реакция на необоснованные и непонятные замечания с твоей стороны. Особенно по поводу Думкина.. что к чему...
Хочешь конкретики. Без проблем.


> Думкин, вы так уверены, что те люди судят о том, о чем имеют
> смутное представление? И что они такого написали на 1ой
> странице, что заставило вас сделать такой вывод? Кстати,
> писать, что "оптимальности Паскалевского Фор в Си нет" -
> это полный бред.

Во первых твоим же оружием по тебе же. А ты уверен что слишком уверенно судишь о Думкине не имея представления о нем? Ай ай ай.
Думкин отнюдь не пишет об превосходстве. Он пишет о различности реализации. Покажи мне где он пишет о превосходстве?


> Единственная оптимальность тут - программист набирает меньше
> букв. Какую ещё вы оптимальность нашли? Вы хоть асм-то знаете,
> не говоря уже о более тонких вещах? Вот только не надо приводить
> тут в довод List.Count, ибо это не оптимизация, это условие
> работы цикла (кстати, на плюсах такое тоже можно реализовать,
> так что с вашим заявление вы поспешили.

Ну да, меньше букв. Ага. Особенно смешны слова "это не оптимизация, это условие работы цикла". Нет, твоя голова в этой фразе точно не работала. Что УЖЕ позволяет соствить о тебе мнение. Кстати в плюсах оно по другому и не реализованно. Так что со своей фразой ты поспешил, что аж насмешил.


> Как? А вот любой нормальный программист надо легко ответит,
> если не сможете сами, то я вам помогу). Да и вообще, про
> какую оптимальность идет речь, если Делфи не инлайнит?


Певый вопрос по поводу "Как?". Как что? А на какой вопрос нормальный программист легко ответит? Помоги мне, я вот не нормальный программист, бо не могу понять, что же имелось в виде под вопросом "Как?" особенно к чему он относится. Ты считаешь что инлайн(ит, кстати почему ит? это какой то придуманные тобой постфикс для инлайн?) это показатель оптимальности? ничего себе, и это говорит парень который типа пришел с геймдев.ру, где любой нормальный человек понимает что инлайн функции это отнюдь далеко не оптимально в рендеринге? ужасть...


> Единственная  причина, почему можно было написать ту гадость
> про геймдев, это то, что люди кинулись так рьяно обсуждать
> эту тему

Да нет. Он написал про основную массу. Раз ты запостил сюда свое негодование, вывод очевиден...


 
ors_archangel ©   (2006-12-23 21:05) [135]


> почему ит

инлайнит - это глагол

>  инлайн функции это отнюдь далеко не оптимально в рендеринге

Действительно, намного оптимальней в цикле тратить время на push/call/ret, чем не делать этого


 
Palladin ©   (2006-12-23 21:17) [136]


> инлайнит - это глагол

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


> Действительно, намного оптимальней в цикле тратить время
> на push/call/ret, чем не делать этого

Где же это можно применить? Давай подумаем... Весь цикл рендеринга в inline никак не получится... хем... ну ладно... обработка вершин? ага.. было бы прикольно если бы обработка вершин склонялась к одной функции, однако она большая... эта функция... и то что тело цикла трансформации введут в инлайн, это оффегительная экономия на спичках... да и смысла нет... что оптимально в инлайн? А вот что...
for (i=0;i<5;i++) {
calc;
}
не более трех-четырех вызовов в теле...


 
ors_archangel ©   (2006-12-23 21:30) [137]


> Palladin ©   (23.12.06 21:17) [136]
> инлайнит функция

странный ты какой-то, я же говорю, что инлайнит - это глагол: "Делфи инлайнит": что? - Делфи, что делает? - инталйнит. Полностью проспрягать что ли?

> Где же это можно применить?

Да, в случае обращения к аппаратно-ускоренным интерфейсам, инлайн или его отсутствие может не сильно влиять на скорость. Но если бы Делфи всё-таки поддерживал встраивание функций (говорю "встраивание", что бы ты не придрался к слову "инлайнинг"), то можно было бы более смело использовать, собсвенно, функции для выделения общих частей (малых по размеру) в коде, что в противном (существуещем на данный момент) случае создаёт упомянутый мной "мусор" в виде опкодов push/call/ret и, возможно, других. То, что Делфи не поддерживает этого, это только малая часть от её общей ограниченности по части оптимизации и, вообще, языка


 
jack128 ©   (2006-12-24 00:15) [138]

ors_archangel ©   (23.12.06 21:30) [137]
если бы Делфи всё-таки поддерживал встраивание функций

она (Дельфи - женского рода ;-) ) и поддерживает...


 
jack128 ©   (2006-12-24 00:17) [139]

jack128 ©   (24.12.06 0:15) [138]
она (Дельфи - женского рода ;-) ) и поддерживает...


хотя мне почему то кажется, что inline сделали, что гордо писать в пресс релизе "поддержка inline функций", чем из-за реальной потребности...


 
ors_archangel ©   (2006-12-24 00:33) [140]


> jack128 ©   (24.12.06 00:17) [139]
> хотя мне почему то кажется, что inline сделали, что гордо
> писать в пресс релизе "поддержка inline функций"…

Не согласен, как я написал в [137], inline-функции позволяют делать больше обобщений. Например, я практически никогда не использую функции GetR/G/BValue, ведь намного быстрее работает and и shr, или хотя бы mod и div, а вот если бы GetRValue, например, был inlinом, то я б и предпочёл его использование, т.к. r = GetRValue(clr) понятней, чем r = clr and $ff или r = clr mod 256, да и ошибку так допустить сложнее


 
Anatoly Podgoretsky ©   (2006-12-24 00:37) [141]

> ors_archangel  (24.12.2006 0:33:20)  [140]

Это ты еще про LongRec не слышал


 
Sha ©   (2006-12-24 00:50) [142]

> ors_archangel ©   (23.12.06 18:27) [131]

Весь этот огород понадобился компилятору из-за твоего собственного нежелания помочь ему сгенерировать оптимальный код. Вот он и создает временную копию строки и генерирует код для ее уничтожения по завершении процедуры. В таких случаях обычно помогает указание const или var.

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

Конечно до jmp никакой компилятор не оптимизирует, но до обычного call - запросто.

> jack128 ©   (24.12.06 00:17) [139]
> гордо писать в пресс релизе "поддержка inline функций


Ну почему же... Можно, например, теперь сделать реализацию Pos через PosEx, не рискуя потерять время на call-ret, и т.п.


 
Sha ©   (2006-12-24 00:55) [143]

> ors_archangel ©   (24.12.06 00:33) [140]
> ведь намного быстрее работает and и shr, или хотя бы mod и div


Могу добавить, что в некоторых случаях это самое "намного быстрее"
составляет разы в целом по проекту.


 
Sha ©   (2006-12-24 01:19) [144]

> Sha ©   (24.12.06 00:50) [142]
> Конечно до jmp никакой компилятор не оптимизирует, но до обычного call - запросто.


Кстати, здесь инлайн как раз подойдет как нельзя лучше :)


 
ors_archangel ©   (2006-12-24 01:24) [145]


> Sha © [142]

Вот именно, я не имею никакого желания помогать компилятору делать его работу.

> Sha © [143]

Intel Compiler уже пытается применять SSE, а дядя Борланд сидит и пятки чешет :)

> Sha © [144]

Если /dev/mem мне не изменяет, то Turbo Prolog от того же Borland в своё время мог оптимизировать хвостовую рекурсию, - могли, когда надо было, блин :(


 
ors_archangel ©   (2006-12-24 01:28) [146]

В Паскальном forе не хватает basicовского stepа, вот это уж точно, приходится делать while, где им и не пахнет :(


 
ors_archangel ©   (2006-12-24 01:31) [147]

А ещё для так любимого Borland OOP, inline то ж ой как пригодился б, хотя размер exeшников и так очень уж крут и без того, может, в этом причина, не хотели, чтобы exeшники весили ещё больше, больше, ведь уже некуда? А причина здесь уже в языке


 
Sha ©   (2006-12-24 01:32) [148]

> ors_archangel ©   (24.12.06 01:24) [145]
> Вот именно, я не имею никакого желания помогать компилятору делать его работу.


Помогать не требуется, достаточно сообщить о своих желаниях :)
В том случае ты обманул компилятор, сказав ему что желаешь иметь возможность изменять параметр, вот он и удовлетворил твое желание по полной программе, предоставив тебе такую возможность. А то, что ты ей не воспользовался - не его вина. Он сделал все как ты просил :)


 
Step by step   (2006-12-24 03:52) [149]


> ors_archangel ©   (24.12.06 01:28) [146]
>
> В Паскальном forе не хватает basicовского stepа, вот это
> уж точно, приходится делать while, где им и не пахнет :(

А множитель использовать - типа ума не хватило ?
Чтож. Сочувствую.


> ors_archangel ©   (24.12.06 01:24) [145]
>
> Intel Compiler уже пытается применять SSE, а дядя Борланд
> сидит и пятки чешет :)

Какой же ты агрессивный ламер. Пока Интел пытается, в GLScene уже много лет есть оптимизация и под SSE и под 3DNow для ключевых функций. Сама определяет их наличие и сама использует если они есть. И всё работает даже на старой Дельфи 6.


 
AM   (2006-12-24 04:14) [150]

>Необоснованной грязи у себя я не увидел
"но вот подобные АМ, не до конца понимающие когда именно и что именно оптимальней использовать" - откуда вы знаете, что я не до конца понимаю? Это и есть необоснованная грязь - переход на личности. Про лично Думкина я вообще ничего не писал, только про его посты.

>Во первых твоим же оружием по тебе же. А ты уверен что слишком >уверенно судишь о Думкине не имея представления о нем? Ай ай ай.
Я написал про фразу, а не про него.

>Думкин отнюдь не пишет об превосходстве. Он пишет о различности >реализации. Покажи мне где он пишет о превосходстве?
Думкин пишет "оптимальности Паскалевского Фор в Си нет".

>Ну да, меньше букв. Ага. Особенно смешны слова "это не оптимизация, это >условие работы цикла". Нет, твоя голова в этой фразе точно не работала. >Что УЖЕ позволяет соствить о тебе мнение.
Дело в том, что если значение List.Count должно изменяться в контексте цикла, его нужно было бы вызывать каждый раз при проверке условия окончания цикла. Но из-за специфика Фора в Делфи значение List.Count может быть вычилсено только один раз. Если честно, я не понимаю, чего вас так удивила эта фраза.

>Кстати в плюсах оно по другому и не реализованно.
Вы неправы. Сравните:
for (int i = 0, end = function_call(); i < end; ++i) //аналогично List.Count
for (int i = 0; i < function_call(); ++i)
>Певый вопрос по поводу "Как?".
"Как?" относилось к тому, что я написал выше.

>ничего себе, и это говорит парень который >типа пришел с геймдев.ру, где любой нормальный человек понимает что >инлайн функции это отнюдь далеко не оптимально в рендеринге? ужасть...
Вот вы придираетесь к моим фразам, но сами-то пишете не менее косноязычно - "неоптимально в рендеринге". В общем-то, проблемы инлайнинга (я думаю, раз вы написали про рендеринг, они вам известны) касаются не только 3д движков, но и любого performance-critical приложения. Тем не менее, современные компиляторы достаточно умны, чтобы минимизировать возможность появления этих проблем, учитывая те преимущества, которые он дает.
>Это показатель оптимальности?
Нет, но я использовал Делфи очень давно и это то, что вспомнилось конкретного про его недостатки (впрочем, возможно, я был неправ, см. ниже)

>Да нет. Он написал про основную массу. Раз ты запостил сюда свое >негодование, вывод очевиден...
Я попрошу вас вести себя более сдержано, вам вроде как не 18 лет.

>jack128
Хмм, а с какой версии? Просто я давно его не использовал, может быть и неправ был.


 
ors_archangel ©   (2006-12-24 04:47) [151]


> Step by step   (24.12.06 03:52) [149]
> А множитель использовать - типа ума не хватило ? Чтож. Сочувствую.

- один add, чтобы увеличить счётчик, или в лучшем случае несколько mul - каждый раз умножать счётчи (ума же хватило :), что же быстрее? Спасибо, конечно, за сочувствие… :)

> Пока Интел пытается, в GLScene уже много лет есть оптимизация
> и под SSE и под 3DNow для ключевых функций. Сама определяет
> их наличие и сама использует если они есть. И всё работает
> даже на старой Дельфи 6.

Я конечно извиняюсь, но GLScene - это не компилятор HLL. Читаем описание Википедии: "GLScene — это бесплатный OpenGL-ориентированный графический движок для Дельфи с открытым исходным кодом", а Intel C++ Compiler, как видно из названия, - компилятор, т.е. он "automatically parallelizes code to maximize underlying processor capabilities. This advanced optimization analyzes loops and determines when it is safe and effective to execute several iterations of the loop in parallel by utilizing MMX™, SSE, SSE2, and SSE3 instructions… Features include support for advanced, dynamic data alignment strategies, including loop peeling to generate aligned loads and loop unrolling to match the prefetch of a full cache line", Intel C++ Compiler - это, компилятор, который анализирует HLL-код и может применять SSE там, где он видит это возможно, при этом тебе не нужно даже знать ни одного асм-опкода, именно это я имел в виду.


 
ors_archangel ©   (2006-12-24 04:59) [152]

"Затянувшаяся дискуссия означает, что обе стороны не правы."
©Вольтер


 
Step by step   (2006-12-24 05:22) [153]


> ors_archangel ©   (24.12.06 04:47) [151]
>
>
> > Step by step   (24.12.06 03:52) [149]
> > А множитель использовать - типа ума не хватило ? Чтож.
>  Сочувствую.
>
> - один add, чтобы увеличить счётчик, или в лучшем случае
> несколько mul - каждый раз умножать счётчи (ума же хватило
> :), что же быстрее? Спасибо, конечно, за сочувствие… :)


То есть ты делаешь всё через ж**у ради экономии наносекунд. Тогда сочувствую вдвойне.


> Я конечно извиняюсь, но GLScene - это не компилятор


Тебе шашечки или ехать?

Все эти SSE и 3DNow! большинству офисных приложений которые мы пишем нафиг не нужны. А в GLScene нужны. Поэтому и написаны.


> это, компилятор, который анализирует HLL-код и может применять
> SSE там, где он видит это возможно, при этом тебе не нужно
> даже знать ни одного асм-опкода, именно это я имел в виду.


В GLScene тебе тоже не нужно знать. Всё уже давно написано.

И процессор ещё должен поддерживать SSE. А раздвувать программу типа блокнот, за счёт включения в неё двух экземпляров кода с SSE и без SSE - это тупость.


 
ors_archangel ©   (2006-12-24 06:01) [154]

Уважаемый Step by step !
Я имел в виду, что

for i := 1 to 10 step 2 do …

лучше чем

i := 1; while i <= 10 do begin … inc(i,2); end

и только это, так же я считаю, что первое лучше и

for i := 1 to 10 div 2 do … i * 2 - 1

- я имел в виду только и именно отсутствие step как модификатора for, который по моему мнению был бы удобен и улучшил бы удобочитаемость в соотвествующих случаях, конечно, тебе, например, больше нравится делать for с умножениями, мне приятней сознавать, что код оптимален - все мы разные и это замечательно, я согласен с твоей позицией, ведь, действительно, незначительный выйгрышь/проигрышь в скорости в наше время не так много значит.
Далее, SEE-оптимизация - это был только пример возможностей IntelC++ Compiler, как действительно оптимизирующего компилятора, сильно отличающегося в этом от нашего любимого dcc. А вот причём здесь тот же GLScene, ума не приложу, видимо это хороший движок, раз он даже юзает 3DNow!, я же сравнивал компиляторы Intel и Delphi. Понимаешь, в GLScene не нужно было бы писать asm-SSE код, если бы dcc оптимизировал как волшебник (или как бог), он же оптимизирует скорее для вида ("я оптимизирую, я оптимизирую, посмотрите!" :) В действительности, между $o+ и $o- разница не особая и совсем уж локальная. Меня просто убило, что ты практически заявил "есть програ, юзает SSE уже давно, так что нафиг нам не надо компиляторов, которые такие проги смогут делать за нас!" …И я согласен, что делить блокнот - это тупость, блокнот - это вообще тупость :) я использую bred3 (©Gladiators Soft)

P.S. Что ещё умеет Intel C++ Compiler (читай: "чего ещё не умеет компилятор Делфи"):

# Multithreaded Application Support, including OpenMP and auto-parallelization for simple and efficient software threading.
# Interprocedural Optimization (IPO) dramatically improves performance of small- or medium-sized functions that are used frequently, especially programs that contain calls within loops.
# Profile-guided Optimization (PGO) improves application performance by reducing instruction-cache thrashing, reorganizing code layout, shrinking code size, and reducing branch mispredictions.
# Automatic Vectorizer parallelizes code and aligns data, including loop peeling to generate aligned loads and loop unrolling to match the prefetch of a full cache line. (это и есть MMX/SSE-оптимизация)
# High Level Optimization (HLO) delivers aggressive optimization with loop transformation and pre-fetching.

©Intel


 
ors_archangel ©   (2006-12-24 06:08) [155]

"Самое трудное в споре - не столько защищать свою точку зрения, сколько иметь о ней четкое представление."
©Моруа


 
Думкин ©   (2006-12-24 06:35) [156]

> AM   (23.12.06 15:13) [129]

Качество обсуждения там было именно тем, что я озвучил. Если вас - задело, ну значит задело. Попробуйте исправится - чтобы не задевало.

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

А в остальном

> Palladin ©   (23.12.06 20:54) [134]

озвучил верно.


 
Step by step   (2006-12-24 06:41) [157]


> ors_archangel ©   (24.12.06 06:01) [154]
>
> Уважаемый Step by step !
> Я имел в виду, что
>
> for i := 1 to 10 step 2 do


А если ты прокрутил экран и забыл какой там был шаг, то что тогда ? Крутить туда-сюда, или устраивать конкурс на лучшую память ?

for i := 1 to 10 step 2 do
 for j := 1 to 10 step 9 do
   for k := 1 to 10 step 7 do
      for m := 1 to 10 step 4 do

Давай, держи всё это в голове, где там какой шаг был обозначен. Если лично тебе удобнее обозначать шаг в одном месте, а использовать его в другом. Типичная для Си манера ребусности.


 
Step by step   (2006-12-24 06:54) [158]


> ors_archangel ©   (24.12.06 06:01) [154]
> Понимаешь, в GLScene не нужно было бы писать asm-SSE код,
> если бы dcc оптимизировал как волшебник


Переводя на русский ты не знаешь встроенного в Дельфи асемблера. Даже на уровне:


movq  mm0, [eax]  
pfadd mm0, [edx]  
movq  [ecx], mm0  
movq  mm1, [eax+8]
pfadd mm1, [edx+8]
movq  [ecx+8], mm1
femms            


Могу тогда посочувствовать в третий раз.

Может быть ты вообще ничего кроме Бейсика не знаешь, и ничего кроме "Здарвствуй мир !" на нём в жизни не написал ?

И поэтому требуешь компиляции этой программы только с SSE.


> я использую bred3

Понятно.


 
ors_archangel ©   (2006-12-24 06:56) [159]

2 Step by step

> Крутить туда-сюда, или устраивать конкурс на лучшую память
> for i := 1 to 10 step 2 do   
>   for j := 1 to 10 step 9 do
>     for k := 1 to 10 step 7 do      
>       for m := 1 to 10 step 4 do

- интересный пример, думаю, если бы я сделал в компиляторе step-модификатор для forа, то я бы уж и сделал и хинт для переменной цикла в виде "i: integer, step x", например… Знаешь, если развить твою мысль, то лучше при упоминании переменной сразу же писать её тип, чтобы не "крутить туда-сюда" и не "устраивать конкурс"ы - шутка конечно, - как ни раз говорилось на этом сайте - "всё можно довести до абсурда", и твой пример, согласись, довольно искусственный. Ты принципиально против шага цикла, указываемого в его заголовке? Или ты просто хочешь разоблочить всех "агрессивных ламеров" на свете?


 
Думкин ©   (2006-12-24 07:06) [160]

> AM   (24.12.06 04:14) [150]
> Думкин пишет "оптимальности Паскалевского Фор в Си нет".

Да, я написал эту фразу. Подразумевал, бееспорно конструкцию вида:
for(i=0;i<f(n);i++)
Если приведенное вами, закрывает это также как и в Паскале - что ж, в этом пункте был неправ. И Сишный фор - это ходячий монстр. :)


 
Step by step   (2006-12-24 07:06) [161]


> ors_archangel ©   (24.12.06 06:56) [159]
> твой пример, согласись, довольно искусственный.

Циклы с шагами понадобились тебе. Так, что искусственность - твоя.


 
Step by step   (2006-12-24 07:15) [162]


> ors_archangel ©   (24.12.06 06:56) [159]
> Знаешь, если развить твою мысль, то лучше при упоминании
> переменной сразу же писать её тип, чтобы не "крутить туда-
> сюда" и не "устраивать конкурс"ы


Не волнуйся. Ошибёшься - компилятор поправит.


 
ors_archangel ©   (2006-12-24 07:16) [163]


> Step by step   (24.12.06 06:54) [158]

Поясни, please, как из [154] следует [158].
Так…

> movq  mm0, [eax]  pfadd mm0, [edx]  movq  [ecx], mm0  movq
>  mm1, [eax+8]pfadd mm1, [edx+8]movq  [ecx+8], mm1femms  
>

переносим в регистр mm0 переменную 64 bit из [eax], честно говоря, не знаю, что такое pfadd (может просветишь?), … emms - очистка стека FPU


 
Step by step   (2006-12-24 07:23) [164]

3DNow! учи.
Это всего лишь сложение.


 
ors_archangel ©   (2006-12-24 07:24) [165]

Step by step! может ты подумал, что я хочу эксплуатировать твой ник? :)))) Я понял твоё мнение насчёт контроля ошибок, но вот слушай, писал ты i*2, i*2, шаг у тебя = 2, так? и вдруг забыл :(  вот блин, а компилятор не поправит - это ведь логическая ошибка, а не синтаксическая, а вот если бы ты написал for i := 1 to 10 step 2 (извини за избитый пример), то такое было бы уже невозможно, это что-то вроде  контроля типов, только здесь мы контролируем шаг. Жду твои контраргументы :) Только не надо про "агрессивных ламеров", я их боюсь :))


 
ors_archangel ©   (2006-12-24 07:26) [166]


> 3DNow! учи.

Обязательно! Пасибо за хинт.


 
Думкин ©   (2006-12-24 07:26) [167]

> > AM   (24.12.06 04:14) [150]

А что будет, если end изменится в теле цикла? Все-таки как ни крути - конструкции не эквиваленты. Или я опять ошибаюсь?


 
Думкин ©   (2006-12-24 07:53) [168]


> > > AM   (24.12.06 04:14) [150]

А вообще, чтобы понять о чем я - вы бы прочитали ту ссылку на ГеймДев.

Когда я туда ходил, там было 4 страницы. Сейчас прошел - уже 9.
Там даже на 9-й странице продолжают упорствовать:

- аналог for в Паскале: for (int i = 0; i <= 10; i++){}. + макросы -> 1-1 сопоставление.
http://www.gamedev.ru/flame/forum/?id=58865&page=9 129 пост.

И много чего еще, с неприкрытым уничижением Паскаля. Может вы и не согласитесь, но в войнах типа "Паскаль против Си" с участием на одной из сторон принимают только ламеры. Эта точка зрения неоднократно обсуждалась тут. Можете возражать. Так вот в тех 9 страницах присутствует именно и это.
При этом не у всех участников. Но у значительной части. А я и не утверждал иного.

Поэтому позвольте мне остаться при своем прежнем мнении.


 
Anatoly Podgoretsky ©   (2006-12-24 12:48) [169]

> ors_archangel  (24.12.2006 1:28:26)  [146]

for со step это уже while


 
Anatoly Podgoretsky ©   (2006-12-24 12:50) [170]

> ors_archangel  (24.12.2006 1:31:27)  [147]

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


 
Anatoly Podgoretsky ©   (2006-12-24 12:56) [171]

> AM  (24.12.2006 4:14:30)  [150]

Передергиваешь однака, ты ввел дополнительную переменную, а вопрос то про

for (int i = 0, i < function_call(); ++i)

А то можно навводить кучу переменных и говорить про погоду на Гаваях


 
Anatoly Podgoretsky ©   (2006-12-24 12:59) [172]

> Думкин  (24.12.2006 7:26:47)  [167]

А чего тут ошибаться, тут налицо передергивание карт.


 
Думкин ©   (2006-12-24 13:08) [173]

> Anatoly Podgoretsky ©   (24.12.06 12:59) [172]

Понял. А то чуть не занервничал - народец то мирный. Я даже часть постов оттуда здесь и привести не могу - правила форума не позволяют.


 
Anatoly Podgoretsky ©   (2006-12-24 13:20) [174]

> Думкин  (24.12.2006 13:08:53)  [173]

На РО напросишься :-)


 
AM   (2006-12-24 18:19) [175]

Думкин, если вам не сложно, отвечайте одним постом, а то воспринимать трудновато.

>Качество обсуждения там было именно тем, что я озвучил. Если вас - >задело, ну значит задело. Попробуйте исправится - чтобы не задевало.
А какие у вас претензии к качеству? Меня задела необоснованность (или я не понял, что вы имели ввиду под качеством)

>А АСМ я знал, судя по вашему настрою, еще тогда когда вы о стол башкой >стукались. Причем тут это?
Я младше вас на 7 лет, так что вы немного ошиблись :). Просто без знания АСМа говорит что-либо об оптимальности неправильно, по-моему, поэтому спросил.

>Если приведенное вами, закрывает это также как и в Паскале - что ж, в >этом пункте был неправ. И Сишный фор - это ходячий монстр. :)
В принципе, случаи типа List.Count даже в варианте "i < func-call()" компилятор может заменить единичным вызовом функции перед телом цикла и дальше сравнивать с полученным значением, НО только в том случае, если он уверен, что логика от этого не изменится (впрочем, данная оптимизация работает не всегда).

>Там даже на 9-й странице продолжают упорствовать
Ну, люди бывают разные :) Темы изначально были театром абсурда - сравнивать Фор в языках... Ну, ещё можно сравнить begin end и { }

>И много чего еще, с неприкрытым уничижением Паскаля.
По-моему, дело в том, что автор задал глупый вопрос, но в провокационной форме, притом вопрос был задан вообще некорректно и чего хотел автор - непонятно, скорее всего - ничего. Но на удочку повелись, начали приводить доводы, один из этих доводов - было загнать автора в логическую ловушку, в которой Паскаль получался ничем не лучше Си в поставленном вопросе (ругать Паскаль, я думаю, особо никто не хотел).

>Может вы и не согласитесь, но в войнах типа "Паскаль против Си" с >участием на одной из сторон принимают только ламеры
Я бы сказал такие темы начинают ламеры, всё таки на том же ГеймДеве иногда данные темы навещали очень квалифицированные люди, хотя, если вы имеет ввиду не квалификацию, а ... по-характеру, что-ли, то я согласен.

Anatoly Podgoretsky
>Передергиваешь однака, ты ввел дополнительную переменную, а вопрос то >про for (int i = 0, i < function_call(); ++i)
Ну, когда вам предлагали реализовать Си Фор в Паскале, вы использовали Вайл и доп. переменную (правда, Си-программиты к ней придирались). В общем-то, какая разница как оно выглядит в языке? Главное, что такую вещь можно реализовать, а важность её не настолько большая, чтобы придираться к ещё большим мелочам, по-моему. Если на то пошло, то Си и Паскаль надо сравнивать с Лиспом.


 
Vga ©   (2006-12-24 18:19) [176]

> [147] ors_archangel ©   (24.12.06 01:31)
> А ещё для так любимого Borland OOP, inline то ж ой как пригодился
> б, хотя размер exeшников и так очень уж крут и без того,
> может, в этом причина, не хотели, чтобы exeшники весили
> ещё больше, больше, ведь уже некуда? А причина здесь уже
> в языке

Не в языке, в библиотеке. AvL дает куда меньший по размерам код. И куда меньше возможностей. А GUI библиотеки для С++ типа Qt & wxWidgets дают ехе метров в 2-5.

> [170] Anatoly Podgoretsky ©   (24.12.06 12:50)

Не с винчестерами, канал до инета у таких "озабоенных" медленный и недешевый.


 
Думкин ©   (2006-12-24 18:38) [177]

> AM   (24.12.06 18:19) [175]

0. Одним постом не всегда получается.
1. Про качество описал ниже, что и вы заметили.
2. 7 лет иногда срок. :) Но асм я тут и не подразумевал. Я тут пункт 3-й подразумевал.
3. Компилятор и должен быть уверен. В Паскале он уверен в этом по сути самого фор. И только об этом собственно и речь.
4. Везде разные. Согласен. Тут тоже 9-я страница.
5. Я мало видел, чтобы наезжали на Си. Кроме синтаксиса и иногда трудночитаемости. Наезды же на Паскаль очень часты. И со стороны "Сионистов", так и из их подгруппы - игроделов. Причем зачастую они мало обоснованы и люди многие не в теме совершенно. Это увидел. Ведь многие посты дальше, "Гы, сына, лол" и не пошли. Там ведь даже ваш пример с введением переменной не приведен хотя бы. Впечатление, что люди не разобрались, а тут же пальцы веером. По этим впечатлением и написал свой пост. Провокаторов всяких хватает. Тут правы.
6. Входить в такие темы могут разные люди. И тут и там. Но вот принмать ту же позицию - вряд ли.

А зачем с Лиспом? Это уже другой подход и тип языка.


 
AM   (2006-12-24 21:51) [178]

2. Ага :) Я тут только-что посмотрел, за что его дают :)
3. Угу, это я и подразумевал под "условием работы фор".
5. Ну, тема была начата с "наезда" на Си и обсуждение там вели "Сионисты" и Флапс, поэтому на Си наезжал по мере сил только Флапс.
Про наезды я - согласен. Т.е., наезды есть (и на С++ тоже), но они или просто столь малозначительны, что не будут влиять на процесс написания программы, либо же предполагают использование несвойственных языку парадигм (ака притянутые за уши).
В принципе, те кто писали "Гы, сына, лол" в чем-то были правы (кстати, среди них затесалось пару звезд ГД :) ), ведь тема выеденного яйца не стоит, а разрослась на 9 страниц и, ещё, и алгоритмы умножения двоичных чисел затронула.
6. Просто на ГД меньше Дельфистов и вряд ли у них был шанс в такой огненной теме :)

Вообще, сравнение с Лиспом нечестное, конечно, но по синтаксическим возможностям такого рода он, по-моему, без проблем обходит Си и Паскаль.


 
Cyrax ©   (2006-12-24 22:21) [179]

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

Ну а возражают тоже только ламеры (как бы пореще сформулировать...))?
C и Паскаль вполне можно обсуждать с точки зрения эффективности и удобства использования для каких-то определённых задач. Эти языки проектировались разными людьми и цели ставились разные...


 
ors_archangel ©   (2006-12-25 01:00) [180]


> Anatoly Podgoretsky ©   (24.12.06 12:50) [170]
> Еще один озабоченный
> размерами испольнительными файлами, да что такого у вас
> с винчестерами творится, что такая головная боль?

Вы считаете, что KOLMCK - никому не нужная чушь на пустом месте, и люди, которые этим занимаются занимаются - просто "озабоченные размерами исполнительных файлов" и вам не понятно, "что такого у них с винчестерами творится, что такая головная боль"?


> Vga ©   (24.12.06 18:19) [176]
> Не в языке, в библиотеке

Не в библиотеке, а как она написана, --- все библиотеки, написанные на Делфи очень не эффективно статически компилируются в смысле всё тех же бедных мегабайтов, например, тот же KOL - это библиотека статической компановки для Делфи, но она написана, как подтверждает сам автор с нарушением концепций языка Delphi Language, покрайней мере, концепций ООП VCL уж точно, поэтому мы и имеем то, что имеем - сверх малый размер. В случае KOL и всех библиотек статической компоновки для Делфи вообще, всё дело уперается в две вещи: ВСЕ ВИРТУАЛЬНЫЕ МЕТОДЫ КЛАССА КОМПОНУЮТСЯ в не зависимости от надобности, в этом виноват компилятор Делфи, не язык, да, но и не библиотека, второе, это БЕЗУСЛОВНАЯ ИНИЦИАЛИЗАЦИЯ, например, в конструкторах классов, которая приводит к включению кода, которые нигде больше, кроме как в собственно инициализации не нужен, это уже проблема языка - он не разделяет обязательную и необязательную инициализацию объектов и переменных, вследствии чего компилятор тоже их не разделяет и в итоге инициализационный код из тех же секций initialization (да и finalization) тащит за собой порой совсем никому не нужные вещи :(
Дальше, если говорить о языке: посмотрм как Делфи "поддерживает" inline-функции:

• Inlining will not occur on any form of late-bound method. This includes virtual, dynamic, and message methods
- совершенно не учитывается, что между override-методами одного класса всегда возможен inline
• Routines containing assembly code will not be inlined.
- запрещено в inline-функциях юзать асм, можно было обойтись ограничением на только поименнованный доступ к параметрам
• If a routine is defined in the interface section and it accesses symbols defined in the implementation section,
that routine cannot be inlined.
- а что изменилось? получается, что львиная доля всех функций не подходит под инлайн, потому что для inline-функций нужен дополнительный линкинг, который компилятор конечно ну никак не может сделать
• In Delphi.NET, routines in classes cannot be inlined if they access members with less (i.e. more restricted)
visibility than the method itself. For example, if a public method accesses private symbols, it cannot be inlined.
- то же самое
• Procedures and functions used in conditional expressions in while-do and repeat-until statements cannot be
expanded inline.
- вообще ограничение без причины, как раз в циклах inline больше всего и нужен, странно, почему в forе ещё оставили
• Within a unit, the body for an inline function should be defined before calls to the function are made. Otherwise,
the body of the function, which is not known to the compiler when it reaches the call site, cannot be expanded
inline.
- доисторический однопроходный принцип :(

Т.о. видим, что Борланд сделал поддержку inline, НО при этом постеснялся качественно переработать компилятор, чтобы можно было просто поставить директиву inline, где требуется, нет: нужно сделать, чтобы метод был статическим и его тело было обязательно перед любым его использованием и т.д. Ещё одна конечно же не решённая Борландом проблема здесь - это перекомпиляция: если мы изменяем inline-функцию, то весь код юнитов, которые её используют, перекомпилируется, решение этой проблемы уже давно известно - пофункциональное связывание. О пользе inline тут уже понаписано, в том числе Sha, Борланду это как видим не особо надо, в Делфи много проблем с языком, но не вижу не одной проблемы, которая не имела бы достойного решения


> AM   (24.12.06 18:19) [175]
> Си и Паскаль надо сравнивать с Лиспом.

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


 
XProger ©   (2006-12-25 02:00) [181]

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

ors_archangel,
Borland всячески мечтает отказаться от object и тянет его лишь в качестве обратной совместимости. Текущие record"ы уже обладают некоторой с ними схожестью (и даже больше). KOL как раз использует object и хранит указатели на них в качестве аналога наследования. Это не безопасно с точки зрения Delphi (именно поэтому появился class) да и не шибко удобно, но KOL"ом пользуются люди его понимающие, так что простительно... :)

inline реализован достаточно грамотно (во всяком случае, лучше чем ничего :) и требование static для метода ещё раз страхует тебя от ошибки (Delphi в этом - мастерица) или ты хотел виртуальный метод оборудовать inline вызовом? %) Думаешь если в C++ методу назначить inline - он 100% будет inlune? Щазззз... ты даже об этом не узнаешь )


 
VEG ©   (2006-12-25 04:39) [182]


> Mystic ©   (18.12.06 08:44) [70]
> Противоречит стандарту, правильно:
> for(int i=0, j=30; i<j; ++i, --j)

Вроде как в цикле for не имеет значения, i++ или ++i. На порядок исполнения этой операции не влияет.


 
Думкин ©   (2006-12-25 05:55) [183]

> Cyrax ©   (24.12.06 22:21) [179]

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


 
Anatoly Podgoretsky ©   (2006-12-25 13:02) [184]

> ors_archangel  (25.12.2006 1:00:00)  [180]

> что KOLMCK - никому не нужная чушь на пустом месте

Не вкладывай свои мысли в мои уста. Это изуитский метод.


 
Mystic ©   (2006-12-25 14:13) [185]

> Вроде как в цикле for не имеет значения, i++ или ++i. На
> порядок исполнения этой операции не влияет.


Я не про то. Писать ++i у меня вошло в привычку (в ряде случае компилятор сгенерирует более оптимальный код), но противоречие не в том. Код
for (int i = 0, int j = 30; i < j; i++, j--)
просто не скомпилируется рядом компиляторов (например gcc), потому что конструкция
int i=0, int j=0;
не является объявлением с точки зрения стандарта.

> ors_archangel ©   (25.12.06 01:00) [180]

Ты считаешь эти ограничения на inline принципиальными, а я нет. Хоть убей не вижу решающего выигрыша в производительности, если внутрь inline-а засунуть цикл while (затраты на CALL мизерны по сравнению с временем выполнения цикла) или от того, что вызов виртульного метода предка будет inline (ООП код априори не самый быстрый). И вообще в мире нет идеальных вещей :)


 
J_f_S   (2006-12-25 20:29) [186]


> Mystic ©   (25.12.06 14:13) [185]
> Код
> for (int i = 0, int j = 30; i < j; i++, j--)
> просто не скомпилируется рядом компиляторов (например gcc),
>  потому что конструкция
> int i=0, int j=0;
> не является объявлением с точки зрения стандарта.

Ну, за гнус точно не скажу, но студия(.NET) ест без проблем.


 
ANTPro ©   (2006-12-25 20:47) [187]

> [180] ors_archangel ©   (25.12.06 01:00)
> KOLMCK - никому не нужная чушь на пустом месте

: )


 
Vga ©   (2006-12-25 21:46) [188]

> [180] ors_archangel ©   (25.12.06 01:00)
> > Vga ©   (24.12.06 18:19) [176]
> > Не в языке, в библиотеке
>
> Не в библиотеке, а как она написана, --- все библиотеки,
> написанные на Делфи очень не эффективно статически компилируются
> в смысле всё тех же бедных мегабайтов, например, тот же
> KOL - это библиотека статической компановки для Делфи, но
> она написана, как подтверждает сам автор с нарушением концепций
> языка Delphi Language, покрайней мере, концепций ООП VCL
> уж точно, поэтому мы и имеем то, что имеем - сверх малый
> размер.

Мы имеем не-ОО библиотеку с уменьшенными по сравнению с VCL возможностями. Этим малый размер и объясняется. AvL - библиотека ОО, но сильно урезанная по сравнению с VCL, чем объясняется экономия кода при ее использовании. Так что это именно из-за структуры библиотеки такой размер. Если хочешь посмотреть, что получается, когда неэффективно работает Smart Linking - попробуй сделать форму с кнопкой на Lazarus/LCL. Получается ехе метров на 6. В Delphi ехе файл сравнительно велик из-за большого количества кода, обеспечивающего удобства для программиста.


 
Mystic ©   (2006-12-26 09:07) [189]

> Ну, за гнус точно не скажу, но студия(.NET) ест без проблем.

Да, знаю, проверял. Но строка int i, int j; не является объявлением переменной (ее появление просто в коде приводит к ошибке), а в описании цикла for допускается объявление без специальных оговорок.


 
vuk ©   (2006-12-26 12:33) [190]

to ors_archangel ©   (25.12.06 01:00) [180]:
>- совершенно не учитывается, что между override-методами одного класса
>всегда возможен inline
Это как? В одном из методов заменили вызов другого на его код? Угу. А потом в потомке еще раз перекрыли вызванный метод, и как это будет потом работать?

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

>- вообще ограничение без причины, как раз в циклах inline больше всего и
>нужен, странно, почему в forе ещё оставили
Читали по диагонали? Там чистым английским языком написано, что "in conditional expressions", то есть в условиях цикла, а не в самом цикле. Разница, надеюсь, понятна.


 
Step by step   (2006-12-27 05:00) [191]


> ors_archangel ©   (24.12.06 07:24) [165]
>
> Step by step! может ты подумал, что я хочу эксплуатировать
> твой ник? :)))) Я понял твоё мнение насчёт контроля ошибок,
>  но вот слушай, писал ты i*2, i*2, шаг у тебя = 2, так?
> и вдруг забыл :(  вот блин, а компилятор не поправит - это
> ведь логическая ошибка, а не синтаксическая, а вот если
> бы ты написал for i := 1 to 10 step 2 (извини за избитый
> пример), то такое было бы уже невозможно


Как же невозможно? Вдруг забыл, что степ 2, и пошло поехало.

Кроме того код нужен не только для писания, но и для чтения. Не только для других, но и для себя, когда потом ищешь ошибки. А держать в голове кучу разных объявленных ранее степов сложно, как уже было сказано ранее.


 
ors_archangel ©   (2006-12-27 05:21) [192]


> Step by step   (27.12.06 05:00) [191]
> сложно

Ладно, не начинай, помойму не сложно, наверно - дело вкуса (в таких случая разработчики плюют на мнение программистов и делают как им нравится)? Хотя меня вставляет идея в цикле итерационного увеличения счётчика, например, задать шаг итерации…

А в [180] я такую чушь нёс несусветную, а заметил только vuk!

vuk!  Большое СПАСИБО за исследование моего поста!


> vuk ©   (26.12.06 12:33) [190]
> >всегда возможен inline
> Это как? В одном из методов заменили
> вызов другого на его код?
> >- запрещено в inline-функциях юзать асм, можно было обойтись
> >ограничением на только поименнованный доступ к параметрам
> Дело не в параметрах, а в использовании регистров.

Да, я погарячился, в действительности есть только несколько случаев: если мы из override-метода вызывем не виртуальный метод, virtual-метод без overridов, либо override-метод без overridов (в потомках). Ты оч правильно заметил, я совсем неправ кругом :( А насчёт регистром мы ещё поговорим!

>> как раз в циклах inline больше всего и нужен
> Читали по диагонали?
>  Там чистым английским языком написано, что "in conditional
> expressions", то есть в условиях цикла, а не в самом цикле.

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

В действительности, согласен с Mystic"ом, что inline не принципиален для программиста, мне просто странно, почему оптимизатор (ведь эти ограничения не для программиста, это ограничения компилятора) так его боится, ведь, хотя процессоры всё умнеют, но при этом стоимость call тоже не падает, раньше это стоило push eip + jmp и всё, а теперь это ещё сбрасывает декодеры, ухудшает выборку…

Так, кто тут ещё?

Vga ©   (25.12.06 21:46) [188]
>  Если хочешь посмотреть, что получается, когда неэффективно
> работает Smart Linking - попробуй сделать форму с кнопкой
> на Lazarus/LCL. Получается ехе метров на 6. В Delphi ехе
> файл сравнительно велик из-за большого количества кода,
> обеспечивающего удобства для программиста.

насколько я знаю, где-то 5/6 - это debug info, а не код


 
Step by step   (2006-12-27 05:37) [193]


> (в таких случая разработчики плюют на мнение программистов
> и делают как им нравится)?


Наоборот. Опытные разработчики предерживаются стандарта стилевого оформления, обязательно дают понятные имена, а не func1 func2 func3, и придерживаются многих негласных соглашений. Всё это казалось бы сильно ограничивает, но зато сильно облегчает взаимопонимание.


 
ors_archangel ©   (2006-12-27 05:58) [194]

Step by step, но ведь

i := 1;
while i <= 257 do begin
 ля-ля-топаля
 inc(i,step);
end;

- это такая искусственость: присвоение (это же цикл изменения счётчика, почему оно вынесено?), inc(i,step) (это можно забыть написать, само его положение сдесь как бы факультативное - вот сделали, а в while"е часто и нету такого), если же ты опять за свои умножения (я опять буду против), то это тоже накручивание подпорок, когда можно прямо выразись смысл - это минус всех ЯП - заставляют писать подпорки для мыслей.
Ещё значит: я захотел изменить шаг - у меня сущность шага в одном месте, у тебя - "Replace All", дальше, через конструкцию for i := a to b step s мы получаем контроль за read-only"ностью счётчика i (как и в обычном for, т.к. оператор отражает сущность!), а в while мы можем его изменить нечаяно, а ведь на ЯП должнобыть сложно писать неправильно, и просто - правильно. Ещё: ну не помешает нам потренеровать память, ты пишешь, что код нужен для чтения, аргумент - все будут путать for со step с for обычный или там, забывать, шаг, вот - пусть помучаются - лучше код поймут! Шаг - параметр цикла, его нельзя не учитывать ну не как, а то что по умолчанию он = 1 ещё в Бейсике отлично запоминается, там много умолчаний, и это здорово. Конечно, не научнообосновано, но ведь разные условия в if тебе лезут в память? А разные параметры функций, те же функции имеют параметры по умолчанию, которые то ж иногда приходится вспоминать (особенно, если чужок код), чувствую, я тебя не убедил, но ведь контроль ошибок реально возрастает при написании, заметь! И не надо думать, что я тут Бейсик пропагандирую, это (до .NET), вообще скорее скрипт...


 
Step by step   (2006-12-27 06:22) [195]


> ors_archangel ©   (27.12.06 05:58) [194]

Вместо while могу предложить использовать if и goto.

Однако язык существует в первую очередь для людей, а уж потом для компьютеров. "While" принято использовать когда счётчика нет. Поэтому когда написано "for", то читающему сразу ясно, что это счётчик.


> вот - пусть помучаются

Для этого есть сипиписка.


> ведь разные условия в if тебе лезут в память?

В if ничего не меняется.


 
ors_archangel ©   (2006-12-27 06:32) [196]


> Step by step   (27.12.06 06:22) [195]


> Вместо while могу предложить использовать if и goto.

Ты смелый человек!

> Однако язык существует в первую очередь для людей, а уж
> потом для компьютеров. "While" принято использовать когда
> счётчика нет. Поэтому когда написано "for", то читающему
> сразу ясно, что это счётчик.

Вот, я ж и предлаю, что когда я имею в виду "здесь цикл, где счётчик меняется от a до b с шагом s", я писал for i := a... ну ты знаешь :) for - именно он! Он означает счётчик -> ты прав && это for -> я прав, неужто консенсус?

> Для этого есть сипиписка.

Вот я и предлажил цикл с шагом! А ещё я предлагаю безусловный цикл, но правда не в этой ветке, ну и если ещё честней, то это всё ведь голословно, пока мы тут теорию уточняем, да практику вспоминаем, от меня, например, ни на 0.001% не зависит, что будет, напрмер, поддерживать компилятор dcc, так что пора закончивать разговор, я так думаю, а то грусно стало совсем :(

> В if ничего не меняется.

Если в if ничего не меняется -> в step ничего не меняется, так что не уходи от темы! Ты там компилятор не написал, случайно, какой-нить? Или у тебя чисто научные соображения для спора?


 
Step by step   (2006-12-27 06:45) [197]


> ors_archangel ©   (27.12.06 06:32) [196]
> от меня, например, ни на 0.001% не зависит, что будет, напрмер,
>  поддерживать компилятор dcc,

И слава Богу!


> в step ничего не меняется,

[191]


 
ors_archangel ©   (2006-12-27 06:56) [198]

> И слава Богу!  
А мне жаль, только не говори, что не хотел бы чего-то поменять в Delphi Language!

> [191]
Рекурсия :)


 
XProger ©   (2006-12-27 09:34) [199]

ors_archangel, нужно в первую очередь менять своё мышление, оно более гибкое нежели язык. for ... in ... do появился, кто им пользуется? Генерируемый asm код видели? )


 
Mystic ©   (2006-12-27 11:06) [200]

> - это такая искусственость: присвоение (это же цикл изменения
> счётчика, почему оно вынесено?), inc(i,step)


Все программирование -- искусственность. Кому-то не хватает конечных автоматов, и он предложит ввести конструкции вида

statemacine
 state Initial:
   I := 0;
  gostate ReadFirst;
 state ReadFirst:
{ ... }
end;


Кому-то не хватает именованых циклов, кому-то еще-чего... Я не сторонник большого разрастания языка, новые возможности не должны быть экзотическими. Например, имхо, step в for -- экзотическая возможность -- очень не часто возникает в ней необходимость, а когда возникает, то вполне можно обойтись while.


 
Palladin ©   (2006-12-27 17:33) [201]


> то вполне можно обойтись while.

а большинстве случаев - просто умножением :)


 
Vga ©   (2006-12-27 20:20) [202]

> [192] ors_archangel ©   (27.12.06 05:21)
> Vga ©   (25.12.06 21:46) [188]
> >  Если хочешь посмотреть, что получается, когда неэффективно
> > работает Smart Linking - попробуй сделать форму с кнопкой
> > на Lazarus/LCL. Получается ехе метров на 6. В Delphi ехе
> > файл сравнительно велик из-за большого количества кода,
> > обеспечивающего удобства для программиста.
> насколько я знаю, где-то 5/6 - это debug info, а не код

Не в Delphi. В lazarus после strip ехе облегчается до пары метров.


 
Anatoly Podgoretsky ©   (2006-12-27 20:31) [203]

> Palladin  (27.12.2006 17:33:21)  [201]

> а большинстве случаев - просто умножением :)

Шутник, всегда сложения хватало.


 
Arct   (2007-01-06 05:47) [204]

У кого нибудь есть функции синтаксического разбора паскалевского кода?


 
Галинка ©   (2007-01-06 06:36) [205]

А мне больше всего н6равится цикл foreach (... in ... ). Могли бы и раньше такое придумать.

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


 
Arct   (2007-01-06 06:45) [206]


> Галинка ©   (06.01.07 06:36) [205]
>
> А мне больше всего н6равится цикл foreach (... in ... ).
>  Могли бы и раньше такое придумать.
>
> Конечно крутые прогрмамеры сейчас заплюют.


А по-моему это как раз вы плюёте на совместимость.


 
Eraser ©   (2007-01-06 13:27) [207]

> [206] Arct   (06.01.07 06:45)

а зачем она нужна, эта совместимость со старыми версиями?


 
jack128 ©   (2007-01-06 14:42) [208]

Anatoly Podgoretsky ©   (27.12.06 20:31) [203]
Шутник, всегда сложения хватало.

имелось в цикле for вместо
for I := 0 to Max - 1 step 2 do
 Arr[I] := 10;

писать
for I := 0 to (Max - 1) div 2 do
 Arr[I * 2] := 10;


 
palva ©   (2007-01-06 15:00) [209]


> Arct   (06.01.07 05:47) [204]
> У кого нибудь есть функции синтаксического разбора паскалевского
> кода?

Есть в компиляторе http://www.freepalcal.org , исходные паскалевские коды которого выложены на сайте.


 
ForStep   (2007-01-06 15:25) [210]

function ForStep (var i: integer; _to, _step: integer): boolean;
begin
 if _step=0 then
 begin
   result:=false;
   exit;
 end;

 i:=i+_step;

 if _step>0 then
   result:=not (i>_to)
 else
   result:=not (i<_to);
end;

procedure TForm1.Button1Click(Sender: TObject);
var
 i,step:integer;
begin
 i:=0;
 step:=2;

 while ForStep(i,10,step) do
   caption:=caption+";"+IntToStr(i);
end;


 
ors_archangel ©   (2007-01-06 16:26) [211]


>  while ForStep(i,10,step) do

Замечательно! Так действительно можно было бы делать, если бы delph не принимал всё слишком всерьёз :( вот встроил бы функцию ForStep вместо её вызова, причём одна переменна здесь ещё передаётся по сслыке, а значит оптимизация была бы ещё лучше (работа с регистром вместо повсемесной косвенной адресации), дальше нужно было бы оптимизировать инвариантность if, и код был бы не хуже i := 0; while i < 10…, правда если step не константен, то постоянное ветвление - это оч плохо, здесь нужна другая оптимизация - вынесение проверки условия _step>0 из цикла (_step в цикле не должен меняться, хотя ForStep этого не гарантирует, как и для остальных переменных), что в общем-то разрешимо только с помощью самомодификации кода, которая в мире SMP и DEP уже не катит, поэтому придётся делать два цикла - если они маленькие, иначе - неотимизируемо... Всё это один большой аргумент, доказывающий необходимость for to step как встроенной конструкции языка, особенно для тупых компиляторов…
Я тоже против разростания языка до конкретной терминологии задачи (как в случае с statemachine в [200]), я за то, чтобы язык имел больше возможностей выражать мысль человеческую, хорший пример - foreach, любой программист, который сколько-то проргаммист, я уверен, сможет перевести это, как и step, с английского и правильно воспринять смысл, а в случае же с statemachine уже нужно знать теорию автоматов, когда на самом деле ему было бы достаточно в действительности знать switch и goto, - это действительно сомнительно. Именованные циклы - тоже тема, тогда можно было бы сделать весьма наглядный дальний break по имени цикла вместо крамольного goto. В ЕЯ предопределены многие супербазовые понятия, как например, целое-часть, причём среди многих понятий есть много общего, но в ЯП почему-то нужно обязательно выкручивать одно через другое, если это возможно: n базовых блоков структурного программирования и живите как хотите :( Понятия, понятные каждому, должны быть понятны и компилятору, например почему в Делфи нет оператора retrun - вряд ли потому что в Борланде каждый день думают как улучшить язык. Забота о совместимости? Если не вносить несовместимость, то вообще не будет развития


 
кобольеро   (2007-01-07 01:10) [212]


> я за то, чтобы язык имел больше возможностей выражать мысль
> человеческую, хорший пример - foreach, любой программист,
>  который сколько-то проргаммист, я уверен, сможет перевести
> это


          SET WX-INDEX TO 1.
          SEARCH WX-STATION
               AT END MOVE "ERROR" TO DETAIL-STATION-NAME
               WHEN IN-WEATHER-STATION = WX-CODE (WX-INDEX)
                    MOVE WX-NAME (WX-INDEX) TO DETAIL-STATION-NAME.
          MOVE ZERO TO WS-HIGH-TEMP.
          MOVE 999  TO WS-LOW-TEMP.
          PERFORM FIND-THE-HI-AND-LO
               VARYING SUB-X FROM 1 BY 1
                 UNTIL SUB-X > 12.
          MOVE WS-HIGH-TEMP TO DETAIL-HIGH-TEMP.
          MOVE WS-LOW-TEMP  TO DETAIL-LOW-TEMP.
          WRITE OUT-ITEM FROM DETAIL-LINE.
          READ IN-FILE
               AT END MOVE "Y" TO END-OF-FILE-FLAG.


 
Arct   (2007-01-07 01:50) [213]


> jack128 ©   (06.01.07 14:42) [208]
> имелось в цикле for вместо
> for I := 0 to Max - 1 step 2 do
>  Arr[I] := 10;


Объясни, зачем тебе каждый десятый элемент выставлять в 10?
Также непонятно, зачем, например, каждый сорок седьмой элемент выставлять в десять, или каждый пятьсотдвадцатьпервый.


 
Arct   (2007-01-07 02:13) [214]


> palva ©   (06.01.07 15:00) [209]
>
>
> > Arct   (06.01.07 05:47) [204]
> > У кого нибудь есть функции синтаксического разбора паскалевского
> > кода?
>
> Есть в компиляторе http://www.freepalcal.org , исходные
> паскалевские коды которого выложены на сайте.


Не работает !


 
for   (2007-01-07 02:18) [215]


> jack128 ©   (06.01.07 14:42) [208]
>
> Anatoly Podgoretsky ©   (27.12.06 20:31) [203]
> Шутник, всегда сложения хватало.
> имелось в цикле for вместо
> for I := 0 to Max - 1 step 2 do
>  Arr[I] := 10;
>
> писать
> for I := 0 to (Max - 1) div 2 do
>  Arr[I * 2] := 10;


DoubleI := 0;
for I := 0 to Max - 1 do begin
Arr[DoubleI] := 10;
DoubleI := DoubleI +2;
end;


 
for   (2007-01-07 02:20) [216]

Упс

DoubleI := 0;
for I := 0 to  (Max - 1) div 2 - 1 do begin
Arr[DoubleI] := 10;
DoubleI := DoubleI +2;
end;


 
for   (2007-01-07 02:22) [217]

Блин
DoubleI := 0;
for I := 0 to  (Max - 1) div 2 do begin
Arr[DoubleI] := 10;
DoubleI := DoubleI +2;
end;


 
Галинка ©   (2007-01-07 03:59) [218]

Arct   (06.01.07 06:45) [206]

а разве в каком то шарпе нет foreach?


 
jack128 ©   (2007-01-07 05:04) [219]

for   (07.01.07 2:18) [215]
Дык это ж нужно доп. переменную объявлять ;-)  Лень, она - матушка, вперёд нас родилась ;-)


 
Arct   (2007-01-07 07:53) [220]


> Галинка ©   (07.01.07 03:59) [218]
>
> Arct   (06.01.07 06:45) [206]
>
> а разве в каком то шарпе нет foreach?

А разве в Дельфи 7 есть ?


> jack128 ©   (07.01.07 05:04) [219]
>
> for   (07.01.07 2:18) [215]
> Дык это ж нужно доп. переменную объявлять ;-)  Л

Ты типа субботу соблюдаешь?

А вообще то нормального человека устроило бы и : Arr[I * 2] := 10;

DoubleI := DoubleI +2;  - разве что для скорости.


 
ors_archangel ©   (2007-01-07 17:28) [221]


> кобольеро   (07.01.07 01:10) [212]

Да... что за язык? (Сам придумал?)
В принципе, семантически каждая строка в отдельности понятна, не кто и не обещал, что без практики всё должно читаться как собственные мысли! Но чтобы полностью понять данных код, нужно знать контекст (задачу данного кода, или хотя бы назначения модуля, которому он принадлежит) - это всегда так, даже в ЕЯ, в большей или меньшей степени в зависимости от ситуации. В общем, данный язык слишком многословен: нет ничего хорошего в повторении ЕЯ, достаточно вспонить прочтение любой математической записи - насколько это громозко и не наглядно; в частности для данного примера, такие вещи, как moveto … обязательно нужно заменять операторами. Главный минус этого ЯП - при том, что запись становится действительно схожа с естественной, на самом деле язык остаётся в рамках строгого, ограниченного малым количеством элементарных статически функционирующих блоков, императивного стиля: это сразу видно по "разнообразию" операторов, и по их строгой последовательности. Т.о. данный ЯП представляет собой в сущности обычный язык высокого уровня, нолько с намёком на естественную запись. Не естественность нужна языку, а гибкость, например, чтобы такое понятие как условие можно было изменять: допустим, у нас есть цикл, выполняющийся до некоторого условия, а по алгоритму может возникнуть необходимость изменить это условие окончания - в Pascale придётся, как говорится, использовать всю мощь языка в виде функтора, значение которого будет то одна функция, то другая, и таким образом мы будем менять условие, вот это неправильно. Это общий недостаток - при наличии понятия оно используется лишь статически, а практически, собственно, программе недоступно для изменения, т.о. сильно ограничеваются свобода действий при решении любой задачи, ведь тоже самое мы наблюдаем и с типами, а в неfreepascal"е даже с операторами :(


 
кобольеро   (2007-01-07 18:08) [222]

> ors_archangel ©   (07.01.07 17:28) [221]
Да... что за язык? (Сам придумал?)

Это COBOL, мальчик.


 
ors_archangel ©   (2007-01-07 18:25) [223]

Объяснил бы лучше, что ты этим - [212] - хотел сказать, что Cobol - идиотский язык, я уже понял, можешь не объяснять, или что-то другое?


 
Галинка ©   (2007-01-07 18:34) [224]

Arct   (07.01.07 07:53) [220]

извините. Я просто сейчас на шарпе все больше. И думаю, что их конструкции не такие уж и плохие )) Просто есть мусульмане, а есть христиане... И те и другие имеют право на существование. Псрото не всегда сутьважно, как устроен процесс изнутри. Возможностей сейчас просто море, железо тоже продвинулось, не надо воевать за каждую строку кода. Расслабтесь и получайте удовольствие.

Но это конечно не мнение профи. Я когда своему шефу сказала, что мне посоветовали что надо экономнее оперативкой и всем таким пльзваться, он меня обсмеял. Сказал, что для пентиума 4 с 3,4 частотой и двумя гигами оперативки нефиг экономить на спичках. Главное что-б работало. И побыстрее )) (в смысле уже через месяц прога была готова).


 
кобольеро   (2007-01-07 18:48) [225]


> ors_archangel ©   (07.01.07 18:25) [223]

Тебе не угодишь. statemachine не устраивает, простые английские фразы MOVE..TO и PERFORM..VARYING - идиотизмом называешь. Видно, что есть свои гениальные мысли, которые превосходят все придуманное за 50 лет развития программирования. Жаль я не гений, чтобы их понять.


 
ors_archangel ©   (2007-01-07 19:23) [226]


> кобольеро   (07.01.07 18:48) [225]

А тебя, как будто, statemachine устраивает?
Почему "простые английские фразы" меня не устраивают я уже написал: по аналогии с математической записью они излишни в программировании: загромождают запись, разве мало общепринятых операторов?
И единственная мысль, которая у меня есть по поводу всех ЯП, причисляющих себя к высокому уровню, выражается в простом непонимании их неразвитости (которая на лицо), причём эта мысль отнюдь, как видишь, не гениальна. Не отрицаю я всего, но расхваливать тоже не собираюсь. Сарказм твой мне вполне понятен, чтож, заслужил значит, постараюсь в будущем быть толерантнее. "Просто есть мусульмане, а есть христиане...", а я похоже, атеист.
p.s. За слово "идиотизм" извиняюсь, не хотел никого обижать, достаточно было слова "избыточность".


 
Anatoly Podgoretsky ©   (2007-01-07 22:03) [227]

> Галинка  (07.01.2007 18:34:44)  [224]

Правильный у тебя шеф.


 
Arct   (2007-01-08 03:31) [228]


> ors_archangel ©   (07.01.07 17:28) [221]
> > кобольеро   (07.01.07 01:10) [212]
> Да... что за язык? (Сам придумал?)
> В принципе, семантически каждая строка в отдельности понятна,
>  не кто и не обещал, что без практики всё должно читаться
> как собственные мысли!

Это в Си не обещал, из за возможности массы извратов. А в Паскале - обычное дело.


> Но чтобы полностью понять данных код, нужно знать контекст
> (задачу данного кода, или хотя бы назначения модуля, которому
> он принадлежит)

Чушь. Может у вас в Си и так, а в Паскале принято давать ПОНЯТНЫЕ имена.


 
ors_archangel ©   (2007-01-08 07:11) [229]


> Arct   (08.01.07 03:31) [228]


> Это в Си не обещал, из за возможности массы извратов. А
> в Паскале - обычное дело.

Согласен, Си менее читабелен, чем Паскаль, думаю здесь все согласны.

> Чушь. Может у вас в Си и так, а в Паскале принято давать
> ПОНЯТНЫЕ имена.

До сих пор удивляюсь, как безоснавательно иногда можно делать выводы :)
Я пишу недостаточно конкретно? Данный код - [212] мне как раз и не понятен, потому что имена мало о чём говорят, "семантически каждая строка понятна", и вообще, я в печали... А вы тут...
Интересно вообще-то: речь о Си совсем ведь не шла, мы с кобольеро обсуждали Cobol и ЕЯ... Ответ, имхо, не в тему, как и большая часть ветки, собственно :)
Бедный Си...


 
J_f_S   (2007-01-08 07:47) [230]

Да закроют ветку наконец, или нет?


 
мр Паскаль   (2007-01-09 04:25) [231]


> Галинка ©   (07.01.07 18:34) [224]
>
> Arct   (07.01.07 07:53) [220]
>
> извините. Я просто сейчас на шарпе все больше. И думаю,
> что их конструкции не такие уж и плохие )) Просто есть мусульмане,
>  а есть христиане... И те и другие имеют право на существование.


Ну и кого ты тут называешь мусульманами?



Страницы: 1 2 3 4 5 6 вся ветка

Форум: "Прочее";
Текущий архив: 2007.01.28;
Скачать: [xml.tar.bz2];

Наверх




Память: 1.25 MB
Время: 0.051 c
1-1164984707
w666w
2006-12-01 17:51
2007.01.28
Как распаковать Zip из строки в строку.


2-1168303037
Antoxa2005
2007-01-09 03:37
2007.01.28
Ко такое? Вопрос покажется странным, но не знаю, как назначить пр


15-1168009247
Chort
2007-01-05 18:00
2007.01.28
Флешкa


2-1168081609
Antoha111
2007-01-06 14:06
2007.01.28
Array of Byte в String


2-1168510227
root
2007-01-11 13:10
2007.01.28
Как правельно обрабатывать исключения





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский