GCC 4.2.0

> Пасквилянты опять пыжатся, только дальше windows kernel который кажется только и умеет что вирусы поддерживать ничего системного не написали.

Для тупых, придётся повторить: http://sourceforge.net/projects/delphine всё можно, если захотеть. Только рвать жопу, чтобы что-то доказывать прыщавым сишникам с комплексами - никто не станет.

> Да ну ? ;)

Ну да. Начали с вспоминания цитаты Линуса (http://www.linux.org.ru/jump-message.jsp?msgid=1923981#1924496), а затем тут же начали пороть чушь (http://www.linux.org.ru/jump-message.jsp?msgid=1923981#1924512).

>Для тупых, придётся повторить: http://sourceforge.net/projects/delphine всё можно, если захотеть. Только рвать жопу, чтобы что-то доказывать прыщавым сишникам с комплексами - никто не станет.

Спокойнее ;)

Собственная OS это конечно амбициозно только похоже проект 3 года как мёртв. (я даже исходники не смог найти - выдаёт 404) ImHO проще и полезнее написать фреймворк к ядру linux

>Он очень аккуратный Ж-)

Сорри, но такая логика не для меня :)

Почему во втором случае не print $i + $i; $i++; $i++ ?

> Спокойнее ;)

О, я спокоен. Просто по фидошной привычке стараюсь отвечать "на языке и в кодировке исходного сообщения". :)

> Собственная OS это конечно амбициозно только похоже проект 3 года как мёртв.

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

Потому и не дорабатывают. Например, у меня нет никакого желания иметь ось, принципиально, написанную на чём-то. :)

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

>> for j:=i*2 to Prev(N) do nprime[j]:=1;

> Здесь надо итерироваться с шагом i

Виноват, недоглядел, что там j+i, а не j+1

>> repeat Inc(i) until (i>=N) or (nprime[i]=0);

> test2.pas(13,12) Error: Illegal assignment to for-loop variable "i"

Значит во FreePascal это запретили, в Turbo можно было

> Error: Identifier not found "Prev"

Здесь я опечатался: не Prev, а Pred

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

В этом вся и беда. Повторю. сейчас в ядре линукс всё, что сложнее list_head это сборище лисапедов. У каждого драйвера свои велики. Тут даже дело не в то на каком языке оно написано а в степени повторного использования кода.

> Повторю. сейчас в ядре линукс всё, что сложнее list_head это сборище лисапедов.

О как! А я, признаться, когда ядра собирал сам, и видел на редкость одинаковые варнинги, было думал, что модули пишутся под копирку и при изменении ядреного API их правят perl-скриптом. :)

Мое личное мнение. Паскаль очень красивый и стройный язык, и подходит для большинства прикладных задач. Красивый, по этому легко учить. Стройный - нет неоднозначностей, потому большинство компиляторов паскаля однопроходные. С - язык больше заточен под системные задачи. А С++ очень сложный и богатый возможностями язык. С++, поэтому, сложен для изучения, да и компиляторы двухпроходные. Я думаю, если бы Бил Гейтс любил паскаль, то разработчики делфи все работали бы в майкрософт, а С и С++ уже б вытеснили из бизнеса, как это произошло в 94-95 годах. Тогда была ситуация примерно следующая Вижуал бейсик реально потеснил С и С++. А затем Delphi потеснила Вижуал бейсик. Мое мнение Delphi - одна из лучших систем. Я пишу систем, потому, что это не совсем язык, это язык + компилятор + среда + библиотеки. Сейчас в линуксе Qt набирает обороты, так там масса идей просто взята из Delphi. А производительность программ от языка вообще мало зависит. Производительность программ зависит от реализации, т.е. компилятора и окружения. То что в Линуксе Си де факто, так это трдиция из юникса. А люди которые Линукс развивают, в основном профи именно по Си и С++ вот и ответ на вопрос почему в линуксе паскаль откровенное говно. А по поводу разработки, когда я пересел с Delphi на С++ в частности на Qt, то впечатления будто пересел с ферари на трактор, и до сих пор под этим впечатлением нахожусь.

>О как! А я, признаться, когда ядра собирал сам, и видел на редкость одинаковые варнинги

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

> То что написали это

> (i + 2) + (i + 2) == 2 * (i + 1)

> Все же ++i + ++i - немного другое

> Логически так:

> (i + 1) + ((i + 1) + 1)

А про то что приоритет ++ больше чем у + помним?

После перевода в польскую нотацию: i++, i++, i+i == 14.

Теорию компиляторов в институте уже не учат?

>О, я спокоен. Просто по фидошной привычке стараюсь отвечать "на языке и в кодировке исходного сообщения". :)

Что то я не помню чтобы я так хамил. Если вы настолько примитивны и молоды что не знаете что нас кличут "насильниками", а вас пасквилянтами то это показывает цену вашего мнения. У меня тоже есть знакомые, которые тоже везде были и всё потенциально умеют и могут, вот только ничего кроме использования чужих наработок у них не получается, вы не из таких часом.

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

PS: наличие смайликов, как я понял, отнудь не признак наличия чувства юмора у человека.

>http://netlab.ru.is/exception/LinuxCXX.shtml

О! Спасибо тебе, добрый человек!... Теперь заживём!;)

>ЛОРОвский поисковик жутко тормозной и выдаёт результаты не по релевантности а чёрте по чему....саму новость не нашёл

Это да... Собственно ЛОРовский поисковик - притча во языцах. Многие вместо него предпочитают использовать "google://site:linux.org.ru <запрос>"...

> Не понял связи с варнингами и 300 раз запрограммированными в разных драйверах версиями бинарных деревьев

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

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

> Что то я не помню чтобы я так хамил.

А амнезия - это вообще стандартная реакция. Так легче выглядеть пострадавшим.

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

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

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

"опять пыжатся", намёк на привязку к windows (что в контексте сайта выглядит однозначно), "можно смело сливать".

Так что не прикидывайтесь невинной овечкой. Вы получили ровно тот ответ, которого заслужили. За сим прощаюсь.

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

Это скорее всего связано с переездом ядра на более новые версии gcc который не бывает синхронным по всем драйверам или в ломке Kernel API.

> Это скорее всего связано с переездом ядра на более новые версии gcc который не бывает синхронным

Да это я понимаю. Но проблема велосипедов в ядре более сложная. Я не уверен (и это подтверждается Кнутом в его трёхтомнике), что нельзя сделать универсальный быстрый алгоритм для какой-то задачи на все случаи жизни. Так что унификация кода в ядре может привести к уменьшению производительности, по этому тут хотелось бы узнать - были ли такие обсуждения и что было решено. :)

а как будет в случае ++i + ++i + ++i ?

> Мое личное мнение. Паскаль очень красивый и стройный язык, и подходит для большинства прикладных задач. Красивый, по этому легко учить. Стройный - нет неоднозначностей, потому большинство компиляторов паскаля однопроходные. С - язык больше заточен под системные задачи. А С++ очень сложный и богатый возможностями язык. С++, поэтому, сложен для изучения, да и компиляторы двухпроходные. Я думаю, если бы Бил Гейтс любил паскаль, то разработчики делфи все работали бы в майкрософт, а С и С++ уже б вытеснили из бизнеса, как это произошло в 94-95 годах. Тогда была ситуация примерно следующая Вижуал бейсик реально потеснил С и С++. А затем Delphi потеснила Вижуал бейсик. Мое мнение Delphi - одна из лучших систем. Я пишу систем, потому, что это не совсем язык, это язык + компилятор + среда + библиотеки. Сейчас в линуксе Qt набирает обороты, так там масса идей просто взята из Delphi. А производительность программ от языка вообще мало зависит. Производительность программ зависит от реализации, т.е. компилятора и окружения. То что в Линуксе Си де факто, так это трдиция из юникса. А люди которые Линукс развивают, в основном профи именно по Си и С++ вот и ответ на вопрос почему в линуксе паскаль откровенное говно. А по поводу разработки, когда я пересел с Delphi на С++ в частности на Qt, то впечатления будто пересел с ферари на трактор, и до сих пор под этим впечатлением нахожусь.

Ну и нафлудил, а толку? Я понимаю, что паскаль _чуть_ удобнее чем C, но сравнивать его с C++ немного странно. Я вынужден сейчас быдлокодить на паскале, и в нём мне жутко не хватает возможности не переписывая элементарные вещи получать структуры данных.

>А про то что приоритет ++ больше чем у + помним?

А про то, что у i++ в качестве значения участвует значение, бывшее ДО ++, забыли? Да, у ++ приоритет выше, но результат будет - прежнее значение i. Т.е. в одном случае - i, в другом - i+1. Вот они в i++ + i++ и должны складываться.

Собственно, только сейчас сформулировал. В ++ в варианте GCC мы имеем огромный side-effect. Один ++ влияет на значение другого.

Без side-effect результат a = i++ + i++; должен быть точно равен результату:
b = i++;
c = i++;
a = b + c;

Так что, как ни крути, а имеем чудовищную языковую корявость. Введение второго ++ меняет результат первого.

> Ну и нафлудил, а толку? Я понимаю, что паскаль _чуть_ удобнее чем C, но сравнивать его с C++ немного странно. Я вынужден сейчас быдлокодить на паскале, и в нём мне жутко не хватает возможности не переписывая элементарные вещи получать структуры данных.

А можно подробнее?

Согласен со многим из написанного анонимусом_pro. Очень часто выбор в пользу того или иного яыка/среды программирования продиктован традицией и прочими нетехническими факторами. Технически же, паскаль не уступает ни C, ни C++, а иногда и превосходит последние. Тут могу себе представить, что паскалист может вообразить о гентушнике, компилящим созданную на C/C++ систему часами напролет... :)

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

В дополнение.

Почему паскаль не выбирают? Во-первых, очень сильная зависимость от вендора, т.е. Borland (или как он там сейчас называется). Во-вторых, нет такого сложившегося community, какое есть у сишников, а потому может быть труднее найти замену (за бугром). Этих причин вполне достаточно, чтобы сделать выбор для нового проекта не в пользу паскаля. Еще раз повторюсь, технически же дельфы выглядят просто превосходно для широкого класса задач.

> Так чего такого не хватает в паскале? Что касается работы со 
>структурами данных и всяких манипуляций с типами и ссылками, то там с 
>этим все в порядке. Просто записывается несколько по-другому.

угу, можешь за пару секунд сделать что-то вроде?

struct hold
{
  int type;
  string value;
};
---------- Где-то в коде...--------------
map <list<list<hold>>>

не можешь, правильно, а мне такие херни приходится часто вводить

> Так что, как ни крути, а имеем чудовищную языковую корявость. Введение второго ++ меняет результат первого.

Во разгорелся сыр-бор! Жаль, я опять к шапошному разбору...
Что же мы имеем на самом деле?

Старое правило языка C :
Нельзя рассчитывать на побочный эффект в пределах одного (данного)
выражения (или подвыражения, если они разделены операцией-запятая).

Если я пишу в некотором выражении
(c = getc())
это допустимо, но с моей стороны будет очень глупо продолжать так
(c = getc()) + c%2
Но можно так
(c = getc()), c + c%2
и т.п.
Тем более это относится к автоприращениям.
Если i == 5 , то
(++i + ++i) == 12 или 13 или 14
в зависимости от реализации, но в следующих выражениях (после
точки с запятой, оператора-запятая и двоеточия в case)
i == 7
независимо от реализации.

Древний юниксоид

> Так что, как ни крути, а имеем чудовищную языковую корявость. Введение второго ++ меняет результат первого.

Во разгорелся сыр-бор! Жаль, я опять к шапошному разбору...
Что же мы имеем на самом деле?

Старое правило языка C :
Нельзя рассчитывать на побочный эффект в пределах одного (данного)
выражения (или подвыражения, если они разделены операцией-запятая).

Если я пишу в некотором выражении
(c = getc())
это допустимо, но с моей стороны будет очень глупо продолжать так
(c = getc()) + c%2
Но можно так
(c = getc()), c + c%2
и т.п.
Тем более это относится к автоприращениям.
Если i == 5 , то
(++i + ++i) == 12 или 13 или 14
в зависимости от реализации, но в следующих выражениях (после
точки с запятой, оператора-запятая и двоеточия в case)
i == 7
независимо от реализации.

Древний юниксоид

>не можешь, правильно, а мне такие херни приходится часто вводить

Да шаблоны, векторы, перегрузка операций, множественное наследование в паскале не реализованы, что позволяет сделать компилятор однопроходным, что в свою очередь позволяет увеличить скорость компиляции в разы. И слава богу, что паскль отличается от С++, а то нам не о чем было бы спорить.

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

>... перегрузка операций ... в паскале не реализованы

Во FreePascal'е перегрузка операций есть.

> map <list<list<hold>>>

Да, о шаблонах я что-то и забыл... Но в паскале, точнее в дельфах, есть решение, правда не совсем удачное. В отличие от того же C++ все дельфовые объекты наследуются от одного базового типа. Вкупе с приведением типов это во многих случаях помогает имитировать шаблоны при небольшой потери скорости исполнения кода.

> Да шаблоны, векторы, перегрузка операций, множественное наследование в паскале не реализованы, что позволяет сделать компилятор однопроходным, что в свою очередь позволяет увеличить скорость компиляции в разы. И слава богу, что паскль отличается от С++, а то нам не о чем было бы спорить.

т.е. ты утверждаешь, что написание килотонн кода на каждый чих это нормально и удобно? клиника ;)

>т.е. ты утверждаешь, что написание килотонн кода на каждый чих это нормально и удобно? клиника ;)

Вы, что то на фантазировали о моих утверждениях. Я читаю этот пост и просто недоумеваю, когда я такое утверждал?!

О! Mono установился, а вчера не устанавливался, видать поправили.

Кстати а GCC 4.2.0 в генту еще нету.

> Вы, что то на фантазировали о моих утверждениях. Я читаю этот пост и просто недоумеваю, когда я такое утверждал?!

Это про пост о наследовании всех объектов от TObject и, следовательно, ненужности шаблонов.
1) В жалкой стандартной библиотеке паскаля (да и говноделфи) нет ассоциативных массивов типа (TObject, TObject). На самом деле, мне бы хватило и (string, TObject), но его тоже нет - приходится быдлокодить, отвлекая внимание от основной цели
2) Ну, набыдлокодил я этот классик. Имею возможность сейчас получать по имени какой-то TObject - именно TObject, приходится ещё раз _вручную_ писать приведение типов до нужного мне, отвлекая внимание от основной цели

И ещё много таких "логичных" говномелочей. Они логичны, не спорю, но они раздражают, и отвлекают. То, чем я занимаюсь сейчас (работа с текстом), на паскале является сущим мучением. Этот язык может быть и удобен для написания говноокон (а это не факт, скорее всего, для написания говноокон удобна IDE, а язык здесь побоку), но для более-менее сложных алгоритмов он как костыль при беге. К счастью, скоро это убожество сдохнет окончательно.