Линус Торвальдс о предупреждениях в GCC

> а где я про скорость говорил? :-)

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

// wbr

$ time ./sum_pascal <data >/dev/null
real    0m5.888s
user    0m5.436s
sys     0m0.262s

$ time ./sum_cpp <data >/dev/null
real    0m7.095s
user    0m6.970s
sys     0m0.064s
$ cat sum.c
#include <stdio.h>

#define MAX_LEN 100

int main()
{
        char s[MAX_LEN];
        long int sum = 0;
        while (fgets(s, MAX_LEN, stdin))
                sum += atoi(s);
        printf("%li\n", sum);
        return 0;
}
$ gcc sum.c -o sum
$ time ./sum <data >/dev/null
real    0m1.366s
user    0m1.319s
sys     0m0.047s

Ы? =)

И кстати, что мне сказать компилятору, чтобы программа на C++
вместо 7 секунд работала 3 минуты, как у вас? :P

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

хорошо... тогда попрошу автора использовать c вместо c++ и привести результаты

>> real 3m18.872s user 3m17.920s sys 0m0.520s

>> pascal real 0m7.971s user 0m7.390s sys 0m0.320s

хм... а не в кэше ли дело???

>> И кстати, что мне сказать компилятору, чтобы программа на C++ вместо 7 секунд работала 3 минуты, как у вас? :P

+0xFFFFFFFF

> Чем uses crt; существенно отличается от #include <crt.h> && gcc -lcrt moo.c ?

Принципиально отличается, потому что в Си нет способа проверить соответствие crt и crt.h и как следствие могут быть тяжелые ошибки, когда не совпадают версии инклудов и библиотек.

uses crt напротив гарантирует отсутствие подобных проблем

>а тем кому пацкаль не нравица нужно в очередь к биоректору строица...

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

> Бугого! Да в паскале все уродливо by default. Не касаясь астральных миров и тонких материй ответьте: нравится ли вам уродливый синтаксис, все эти begin|end, Procedure-Function, даже return нормального нет. FunctionName:= result_value - как грцца, ужоснах.

Бугого! В Delphi/FP в каждой функции есть переменная Result, мне в сях не хватает возможности работать с этой переменной, приходится заводить новую и передавать ее в return в каждом месте.

> и чем описанный там язык отличается от реализации хотя бы Turbo Pascal 7? :)

в паскале кстати уже появился условный оператор и аналоги i++,++i,i*=3,... ? или оператор цикла с аналогичными возможностями

>>А внятно ответить чем ЯЗЫК паскаль в реализации FP/Delphi плох сможете? > Слущай суда, больной брат анаимус. Иди поеж ухи и сдохни. Object Pascal имеет совсем отдалённое сходство с Пасцалем от Вирта. Больной моск это ниасилит, но может в следующей жизни ты будешь жабой и твой пердёж в лужах буду доставлять людям радость...

На себя кума оборотись, если твой бойной моск ниасил, что здесь НИКТО не говорит о паскале от Вирта, специально его Вирта не упомянув. Перди дальше.

> в паскале кстати уже появился условный оператор и аналоги i++,++i,i*=3,... ?

В FreePascal да. И перегрузка операторов есть. В Delphi нет.

> или оператор цикла с аналогичными возможностями

чего нет того нет

> То есть все реальные и труЪ пацаны массивы от (-1) отсчитывают на самом-то деле?

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

> Только вот всё равно всё упирается в производительность - на С всё равно будет быстрее.

Строки в Си быстрее? Может за счет того, что strlen дергает всю строку пока не встретит ноль?

> Причиной оказалось то, что кое-где (в другом месте, даже не в том файле где был gethostbyname) я не сделал memset / char* a=0 - в итоге в а помещался мусор, к которому что-то ещё и конкатенировалось.

Забыть инициализировать переменную можно и в паскале и в си. В паскалевых строках мне еще нравится то, что в них можно спокойно поместить ЛЮБЫЕ символы и ноль в том числе. А в Си с нулями вечно заморочки.

>> + Настоящая модульность, а не ее имитация с помощью #include

> man SML

>> + Развитая система типов и их конструирования.

> man Haskell

Я сравнивал Си и Паскаль только.

> Паскаль - чуть более строгий переносимый ассемблер, чем С.

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

>i=i+s;

это ты отжег неимоверно просто

> В любом случае, "строка", состоящая из байт а не символов - это не строка.

В AnsiString строка состоит из символов, равных байту. В WideString из 16 битных символов. Встроенной поддержки utf8 нет.

Месье любит прикидываться крутым кулхацкером делая работу, которую может выполнить компьютер?

>> i=i+s;

> это ты отжег неимоверно просто

Да ладно, современные компиляторы такие вещи нормально оптимизируют. По крайней мере, gcc для "i = i + s" и "i += s" обычно генерирует одинаковый код.

> Я сравнивал Си и Паскаль только.

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

> Я всего лишь, хочу показать что современному паскалю не повезло в распространенности

Ну я бы так не сказал - см. сколько поделий на Делфях.

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

с этим согласен.

> И кстати, что мне сказать компилятору, чтобы программа на C++ вместо 7 секунд работала 3 минуты, как у вас? :P

gcc-c++-3.2.2

>необходимо узнать сумму всех цифр

может все-таки чисел? ;)))

>что мне сказать компилятору c++ чтоб быстрее работал?

задача - супер!!! С++ как раз для таких задач и придумали ;)))

уважаемый! пишите дальше на паскале, если не понимаете для чего нужен С++ :)

>Физически переменная этих типов представляет собой указатель на область памяти

Физически ЛЮБАЯ переменная представляет собой указатель на область памяти. Даже в бейсике.

>по адресу (-1) от этого указателя хранится длина

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

компилятор, конечно важная деталь. Потому что может генерировать жирный, быстрый, медленный, тормознутый, миниатюрный, реактивный код, байт-код, или машинный код. Он также может быть быстрым или медленным. Иногда важно его присутствие на целевой платформе/платформах. (К примеру, gcc для вин64 еще нет, а fpc уже есть, код сгенерированный fpc кажется привлекателен маленьким размером выходных бинарников, а скорость компиляции у fpc гораздо быстрее чем у gcc ... однако здесь причина уже в дизайне языка... та самая модульность - fpc мог бы и быстрее компилить, по скорости компиляции его бьют борландовские продукты)

Однако не в этом суть.

Программа - это абстракция, которая создана для того, что бы ее читали, изредка компилировали и запускали, и что бы описывать на ней ясно и однозначно алгоритмы. При этом, если есть возможность поймать ошибку на стадии компиляции, а не на стадии исполнения, тем лучше. Синтаксис - это не дело вкуса. Он тоже должен снижать вероятность ошибки. Простой пример, часто, вместо того, чтобы написать == пишут =. Поэтому Вирт и убрал паскалевский <> заменив его уже в Модуле на # Символ один, вероятность ошибки меньше. Паскаль, как и Си - это очень старые языки, со своими недостатками. Есть и современники - Модула-2, Модула-3, Оберон, и Ада. Современника Си назвать затрудняюсь... Ява на него похожа лишь синтаксически Ц++ писался так, чтобы сохранить по возможности совместимость с Си. Вынуждены были. А Вирт написав Модулу и Оберон отказался от обратной совместимости. Он написал конвертер паскаль -> модула-2, а затем модула-2 -> оберон :) Написав пару раз код на Модуле, Обероне или Аде к паскалю возвращаться не хочется. Иногда приходится, по причинам реализации - как-то присутствие на целевой платформе или кому удобно интерфейсы в lazarus-e рисовать. Си стал де факто стандартом потому что на нем реализован Юникс, и долгое время единственным нормальным средством разработки для Юникс был именно Си. А вовсе не из-за пресловутой низкоуровневости. Кто не знает, Оберон тоже можно назвать низкоуровневым. Там даже можно писать SYSTEM.MOVE (a, b); Есть сдвиги типа ASH, LSH Есть ROT Можно использовать SYSTEM.GETREG, PUTREG, SYSTEM.ADR Конечно, если оправдано... для application программ обычни (за редкими исключениями) низкоуровневые фунцкии исползьовать глупо (и иногда не переносимо) и безрассудно :) Наше общество инертно, признайтесь. В 86 году Вирт написал операционную систему на Оберон, со сборщиком мусора. Было много находок, интересные решения, революционные для своего времени, оставшиеся в академических стенах, потому, что мало кто решился вынести их в жизнь. Лишь декаду спустя Сан выпустила Яву, и всем своим весом и авторитетом раскрутило ее, еще лет 10 спустя появился C#, а они на мой взгляд сильно уступают даже Ада, не говоря о Обероне.

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

Главное, это то, что язык - это способ выражения алгоритмов, нотация

Не забывайте :)

Удачи!

>>по адресу (-1) от этого указателя хранится длина

> И часто вы так извращаетесь с классами? И после этого мне будут говорить, что паскакаль - безопасный язык?!

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

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

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

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

А вот это извращение, вот поэтому:

> Да я в курсе, что sizeof указатель не обязан равняться sizeof целый тип.

И поэтому такой код непереносим.

Не говоря уже о том, что в следующей версии по адресу -1 может оказаться нечто другое. А длина строки будет по адресу -2. И ССЗБ тот, у кого накроются проги. И он доолго будет искать, где ошибка...

Ну это традиционные проблемы при завязке кода проги на ABI

>никто не мешает привести указатель к integer типу или любому другому, а потом обратно в указатель

И эти люди говорят нам о небезопасности Си!

> Не говоря уже о том, что в следующей версии по адресу -1 может оказаться нечто другое.

Еще раз. Никто в фрипаскале не заставляет использовать знание как компилятор реализует AnsiString/WideString, так делать нехорошо, но если хочется - то можно, что иллюстрирует отсутствие особых ограничений, но всегда когда программист решает сделать грязный хак, он его делает его в фрипаскале явно в отличие от Си, где иногда достаточно чуть ослабить внимательность, чтобы получить жуткие баги.

Если в паскакале можно прикастовать указатель к целому и обратно, то о какой безопасности может идти речь?

>в отличие от Си, где иногда достаточно чуть ослабить внимательность, чтобы получить жуткие баги

А зачем её ослаблять? А для тех, кто не уверен в себе, есть cpp и java - прописываешь конструктор/деструктор и горя не знаешь.

> Если в паскакале можно прикастовать указатель к целому и обратно, то о какой безопасности может идти речь?

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

type bla_bla_type_of_somebody = array ....

var a: mu_mu; b:qu_ku;c:bla_bla_type_of_somebody;

...

a:=...

b:=qu_qu(a);

bla_bla_type_of_somebody(b)[i]:=c[j];

Всё что можно написать на си, можно написать на паскале с кучей геморроя с кодом и без в вопросах надёжности (ликов, оверфловов etc). Всё, что можно написать на паскале, можно легко написать на си, но не уверен, что код будет абсолютно надёжным. При этом есть вероятность, но небольшая, как что код на паскале будет писать даже легче чем на си, так и то что код на си будет надёжным даже без отладки. Короче, IMO языки разные нужны. P.S. go C#, Pascal & C!

> while (cin >> s)

Ты что, после запуска программы копи-пастишь в терминал 210 метровый файл и валишь на язык? :) У меня нет слов, только "бвахаха!!1" :) Ты башкой подумай. громадная разница в производительности у тебя никаких подозрений не вызывает, нет? :) Окей, будем считать, что сложение двух простых чисел в С++ происходит в 28 раз медленнее, чем в паскале :)

> что мне сказать компилятору c++ чтоб быстрее работал?

И причем тут компилятор? :) Ну, ещё один разок напряги мозги и я отстану :)

> В С такое невозможно, при наличии хотя бы примитивной системы модулей - возможно.

Так и пишем: Си не поддерживает модульное программирование... даже на примитивном уровне. %)

Может вам голову помыть пора, а то там каша какая-то засохла :)

>Может вам голову помыть пора, а то там каша какая-то засохла :)

Да, вам ремесленникам вся эта математика такой смешной кажется:)

> Так и пишем: Си не поддерживает модульное программирование... даже на примитивном уровне. %)

А до тебя это только сейчас дошло? С не поддерживает модульного программирования, но не _исключает_ (sic!) его применения.

>> while (cin >> s)
>Ты что, после запуска программы копи-пастишь в терминал 210 метровый файл и валишь на язык? :) У меня нет слов, только "бвахаха!!1" :)

Ты знаешь даже в устаревших системах типа оффтопега есть streams redirections ... но для такого великого спеца это не трЪу да?

>mutronix ** (*)

Проговор - lamo!

>Строки в Си быстрее? Может за счет того, что strlen дергает всю строку пока не встретит ноль?

Да причём здесь строки? Я имел ввиду производительность в-общем. Или Вы гарантируете, что freepascal создаст более оптимальный код чем gcc (кстати, вроде gpc есть? 3 года назад баловался - не рулило)? А с переносимостью чё делать бум? Freepascal для AIX я может и найду. А для z/OS?

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

>В паскалевых строках мне еще нравится то, что в них можно спокойно поместить ЛЮБЫЕ символы и ноль в том числе. А в Си с нулями вечно заморочки.

Используй костылёвые классы для С++ (оффтопик - после Джавы Цэ++ кажется мне жутким уродством) либо же скатай с инета (или напиши - это несложно) библиотеку для С. Когда я пересел на С после Паскаля, мне наоборот понравился тот факт что строки заканчиваются нулём.

Кстати, если не секрет, откуда такие "вечно заморочки с нулями"? Кроме нуля есть ещё 255 значений для char ;)

Для любителей научного замера длины пиписьки давно уже сделан фреймворк - шли бы вы туда сразу :)
А именно - сюда: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=sumcol&la...
ваш любимый пример на складывание целых ...
ФАНФАРЫ! Ту-ту-ту-ду ....
На первом месте - Clean, на втором - С, на третьем - D, на 4-м - C++, на 5-м Free Pascal ...
Я лично сейчас ковыряюсь с OCaml - он на 6-м что есть весьма хорошо :)

Кстати тум же иллюстрация почему "скриптовые" рулят для аппликатионс:
Python (к примеру, но можно и рябу и перловку):

import sys, itertools
print sum(itertools.imap(int, sys.stdin))

Все :) И это всего в 4 раза тормознее Ся .... так что :)

> Ты знаешь даже в устаревших системах типа оффтопега есть streams redirections ...

Бля, кто все эти люди? :)

> но для такого великого спеца это не трЪу да?

Нет, почему же. Очень даже тръу. Пусть работает в 28 раз медленнее, если хотите. Я разве спорю? Лишь бы вместе с гландами лишнего не оторвали, а то ещё застрянет в районе сидалища :)

> Проговор - lamo!

Экспертная оценка ананимного аналитика с ЛОРа. "Проверено: anonymous" :)

Мужики! Езыг - это всего лишь инструмент. Какая задача, таков и инструмент. В студенческие годы мне приходилось писать проги под задачи математического моделирования на одним из популярных тогда езыгов программирования (на каком именно - лучше умолчу ;-) ) На Сях это было бы более трудоемко (на тот период времени не было библиотек). Так что оставьте эти споры. Переводчик перевел через *0#у, чем породил флейм.

Перевод уже обсудили :-) И вообще не мешай развлекаться :-))

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

>>есть streams redirections ...
>> но для такого великого спеца это не трЪу да?

>Нет, почему же. Очень даже тръу. Пусть работает в 28 раз медленнее, если хотите. Я разве спорю? Лишь бы вместе с гландами лишнего не оторвали, а то ещё застрянет в районе сидалища :)

Нет ну не тупой? Значит для паскаля чтение со stdin не тормозит, а для сей плюсатых тормозаааа ....
Опять же про "в 28 раз" - это только на твоем 98 виндусе так :)

> Проговор - lamo!
>Экспертная оценка ананимного аналитика с ЛОРа. "Проверено: anonymous" :)
>mutronix ** (*) (01.12.2006 22:25:06)

А! Внял и осознал! Ну ничего, ничего - ты можешь измениться к лучшему.

> "в 28 раз" - это только на твоем 98 виндусе так :)

А у тебя надо пологать виндос хр? "в 28 раз" - это у автора кода, а не на моем "98 виндусе". Но тебе ведь лишь бы кого-нибудь в пупок укусить, правда? Глаза красные, слюна до пола, моск в режиме stand by... :D

> А! Внял и осознал!

Ты главное не волновайся. Санитары уже выехали :)

Не ссорьтесь, мальчики! Пишем ядро на SQL!

К сведению уважаемых коллег:

Sun при разработке Java и MS при разработке .NET катались к Вирту и консультировались, а потом лицензировали часть разработок системы Оберон.

Только, к сожалению, в кодогенераторе использовали более старый байт-код (реализация древнего p-code из паскалевской машины), а не хранимое синтаксическое дерево Оберона (информация лично от Вирта).

В результате на первых порах скорость апплетов на Яве отставала от оберона в 12-50 раз. Потом, конечно, извернулись, оптимизировав трансляцию байт-кода, но это - уже традиционное извращение любителей Си.

Без обид - ИМХО Си, Линукс, Ява и т.п. широко распространены как раз потому, что несовершенны - программистам интересней искать приключения в самовыражении, а не писать надежный код.

Повзрослеют :-)