GCC 4.2.0

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

Эээ. Не совсем так. Она соответствует и успешная компиляция общепринятым компилятором это, в частности, подтверждает. Ну почти :)

> Поддержка не обязательно значит развитие. Поддержка = багфиксинг
Пожизненной поддержки ПО никто не обещал, тем более в OS!
Поэтому ее ожидать как минимум наивно.

> http://img1.liveinternet.ru/images/attach/b/0/16663/16663373_march.jpg

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

Для Вас критерием звания "assembler" является определённый порядок вычислений? Да и он определён, если не писать всяких извращённых конструкций (и код читабельнее)

Добровольно - сколько угодно. Насильно - имхо рабство 21 века.

Это ж теперь всю систему заново пересобирать придется!

> Совершенно не факт.

Всё вам не так, да не этак. Солнце ещё на востоке встаёт, или уже к югу переехало?

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

Я смотрю вашим местом жительства является прямо таки идеальная вселенная, где не осталось человеков. Завидую.

> Держать зоопарк версий компиляторов это безусловно true way! Но по факту так и приходится делать :(

Вы разработчик или обезьяна для кодинга на вижуалвасике? Если первое - то будьте добры перечислить чем программа вашего изготовления собирается. Или же банально ниасилили простейшее переключение между слотовыми инсталляциями в Генте? ;)

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

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

Ну правильно - кто-то в одной ячейке памяти держит переменную i, кто-то "дробит". В итоге в первом случае i++ + i++ даст на единицу больше, чем во втором. Java и C# такие вещи обрабатывают "правильно" - с точки зрения человеческой логики, а вот C и C++ - как повезет.

> Эээ. Не совсем так. Она соответствует и успешная компиляция общепринятым компилятором это, в частности, подтверждает. Ну почти :)

Почти не считается :)

> Пожизненной поддержки ПО никто не обещал, тем более в OS! > Поэтому ее ожидать как минимум наивно.

Не согласен. Если автор забил на проприетарную программу, это её смерть в большинстве случаев. Если автор забил на опенсорсную программу, это совсем не означает её смерть. Многие программы меняют мейнтенеров. В этом сила опенсорса.

Интересно, а вариадические шаблоны C++ уже поддерживаются?... Народ, кто-то уже собрал?

2Gharik

> Я смотрю вашим местом жительства является прямо таки идеальная вселенная, где не осталось человеков. Завидую.
> ...
>
Вы разработчик или обезьяна для кодинга на вижуалвасике? Если первое - то будьте добры перечислить чем программа вашего изготовления собирается.
> ...
> Вот-вот, а потом легионы кошерных кодеров кроют легендарными матюгами таких вот разработчиков,

Флейм можете раздувать сколько душе угодно. Мне это не интересно.


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

> Если автор забил на опенсорсную программу, это совсем не означает её смерть.

Да согласен я. Я не об этом.

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

> добавлена защита от арифметического переполнения

Блин. Если это во время компиляции, то какой-то паскаль уже получается

>Блин. Если это во время компиляции, то какой-то паскаль уже получается

У Паскаля, ИМХО, run-time...

А по-вашему лучше пусть уязвимости будут?

>Давайте закроем тему от анонимусов :) Я не могу на это смотреть.

Терпи, это скнюсики ;)

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

Такие изменения пришлось делать при выходе GCC 3.0, 3.3, 3.4, 4.0 ;-) Вы просто уже забыли.

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

Да и я сказал, что нефиг ныть, а делом нужно заниматься ;)

>Я сравнивал язык паскаль и язык С

Тогда зачем приплёл "скорость програм на С и на Паскале"???

>т.к. клонов паскаля достаточно много

Общепринятых стандартов не так уж много - ок. 3

>Но вряд ли Линус имел в виду турбо паскаль

Почему "вряд ли"? Может да, а может и нет. Как бы то ни было, но отличия Турбо паскаля от ISO не очень большие, в основном это некоторые расширения.

>Для Вас критерием звания "assembler" является определённый порядок вычислений?

Да, от "ассемблера" хотелось бы получить возможности атомарности операций, хотя бы принудительно (например, указанием volatile перед выражением).

Приведите ваше определение ассемблера:) Начните с перевода слова assempler:)

>>Блин. Если это во время компиляции, то какой-то паскаль уже получается

>У Паскаля, ИМХО, run-time...

>А по-вашему лучше пусть уязвимости будут?

Если мне нужны рантайм проверки, то я выберу Java. Всё же, у каждого языка своя ниша и свои требования :)

>Если мне нужны рантайм проверки, то я выберу Java. Всё же, у каждого языка своя ниша и свои требования :)

Я не говорил, что в GCC-4.2.0 они compile-time или run-time. Плюс, я почти уверен, что флагом компилятора эти проверки выключаются, какими бы они не были (ещё не собирал - не проверял).

> Тогда зачем приплёл "скорость програм на С и на Паскале"???

Потому что программы выполняются не в сферическом вакууме а на конкретных машинах, и компилируются не абстрактными сферическими всезнающими компиляторами а конкретными gcc или fpc. И результат такой, что программы на С работают быстрее чем программы на паскале.

> Почему "вряд ли"? Может да, а может и нет. Как бы то ни было, но отличия Турбо паскаля от ISO не очень большие, в основном это некоторые расширения.

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

> некоторые расширения.

Отличия огромные.

>Отличия огромные.

Например? Только не путай ObjectPascal и просто Turbo Pascal (это который до 5.0 включительно)

>Потому что программы выполняются не в сферическом вакууме а на конкретных машинах...

Так значит ты всё-таки про конкретные компиляторы, а не про языки?

>И результат такой, что программы на С работают быстрее чем программы на паскале.

Тесты - в студию!

>А турбопаскаль, тем более в 90 годы за пределы доса не выходил.

Ошибаешся. Стандарт турбо паскаля в 90-е реализован был не только на DOS/WIN.

> Например? Только не путай ObjectPascal и просто Turbo Pascal (это который до 5.0 включительно)

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

> Плюс, я почти уверен, что флагом компилятора эти проверки выключаются, какими бы они не были (ещё не собирал - не проверял).

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

>То что написали это
>(i + 2) + (i + 2) == 2 * (i + 1)
>Все же ++i + ++i - немного другое
>Логически так:
>(i + 1) + ((i + 1) + 1)

туфта!
строчка "++i + ++i;" прибавит к "i" 2:
int i=1; //i=1
++i + ++i; //i=3

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

Вполне возможно, что это _включается_ по параметру. Я ведь писал выше, что я ещё новый gcc не собирал (где ебилды?!)...

> - модульность программ

К реализации модульности стандарт языка отношения не имеет

> - работа со строками

Да, есть такое расширение (при том, что классический packed array тоже поддерживается)

> - куча стандартных модулей

К стандарту языка отношения не имеет

> - расширенная работа с указателями

Какая?

> - ассемблерные вставки

Есть такое расширение, но к стандарту языка это не относится:)

>И они меняют язык самым коренным образом.

Язык - не меняют:) AFAIR для трансляции asm-вставок вызывался TASM

> Тесты - в студию!

Ну вот какие то синтетические тесты.

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gcc&...

> Ошибаешся. Стандарт турбо паскаля в 90-е реализован был не только на DOS/WIN.

Ну значит ошибаюсь.

assembler (сущ.) - 1) (рабочий) сборщик, 2) сборочное устройство (Источник: http://lingvo.yandex.ru/en?text=assembler&st_translate=1)

Что я тут должен был увидеть?

( А вообще спор перерастает в флейм;) Пофлеймить - дело хорошее, но может переместимся в Talks? )

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

Вызывающе неверная информация. Производительность у хороших компиляторов на уровне gcc, с низким уровнем у борландовских диалектов всё в порядке. Никогда не было проблем с портированием сёвых примеров.

> К реализации модульности стандарт языка отношения не имеет

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

> К стандарту языка отношения не имеет

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

> Какая?

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

> Есть такое расширение, но к стандарту языка это не относится:)

Так были же так всякие ключевые слова asm и прочее, которые встроены в язык.

>При чём во всех языках, где есть эти оператора, кроме Си, оно работает именно так. От PHP до Java :)

>Что же получается в Си... В стандарте оно оговорено, как не определённость, а разные компиляторы выдают разные значения :D GCC, например, работает, ЕМНИП, с автоинкрементами атомарно. Т.е. увеличивает i перед _всем_ вычислением выражением, либо после _всего_.

Вот что получается:
http://alenacpp.blogspot.com/2005/11/sequence-points.html

> с низким уровнем у борландовских диалектов всё в порядке

Как-то слабо соотносится вот с этим утверждением:

Led> для трансляции asm-вставок вызывался TASM

> При чём во всех языках, где есть эти оператора, кроме Си, оно работает именно так. От PHP до Java :)

Не во всех -- в С++ работает также как в С.

>Не нравится - слезай.

С кого слизывать?

Есть смысл переводить разработку с Intel C++ на GCC?

>туфта!
строчка "++i + ++i;" прибавит к "i" 2:
int i=1; //i=1
++i + ++i; //i=3

не такой пример рассматривался.
i = ++i + ++i; //i=6

> Есть смысл переводить разработку с Intel C++ на GCC?

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

Насколько я знаю, Intel С++ покупают те, кому его оптимизация действительно критична. Если же собираете програмки вроде два-окна-четыре-кнопки, то сомневаюсь, чтобы Вы использовали Intel C++.

>В оригинальном паскале вся программа писалась в одном файле, понятия модулей не было.

Здесь соглашусь. Пожалуй, unit/uses и строки - это фактически единственные серьёзные расширения стандарта. Кстати, http://en.wikipedia.org/wiki/Turbo_Pascal

>В турбопаскале для этого куча ключевых слов, вроде uses, interface, и прочее.

>Но формально у C, C++ есть стандартная библиотека, поведение которой прописывается в стандарте.

Мы обсуждаем языки или библиотеки?:)

>Ну хотя бы преобразование к целому числу, арифметика и преобразование обратно.

Это ты с C перепутал, там арифметика с указателями:) А преобразование из указателя в числа: ты, наверное, имеешь ввиду Seg(P), Ofs(P)? дык, это к языку отношения не имеет - это узкоплатформенные (DOS-only) ФУНКЦИИ.

>Так были же так всякие ключевые слова asm

Убедил, ключевое слово asm - действительно турбо-расширение стандарта:)

>и прочее, которые встроены в язык.

Какие "прочие"? асм-инструкции? они к языку паскаль отношения не имеют. Они имеют отношение к TASM-варианту ассемблера для x86:)

> с низким уровнем у борландовских диалектов всё в порядке

>Как-то слабо соотносится вот с этим утверждением:

>Led> для трансляции asm-вставок вызывался TASM

Что значит "слабо соотносится"? а в gcc gas для этого не используется?:)

>При чём во всех языках, где есть эти оператора, кроме Си, оно работает именно так. От PHP до Java :)

perl -e '$i=5; print ++$i + ++$i,"\n"'

14

Как видите.

> Что значит "слабо соотносится"? а в gcc gas для этого не используется?:)

В том-то и дело, что gas -- очень мощная штука. TASM поддерживает mov из/в control registers? debug registers? ltr, str и пр.? VMX инструкции? Компилятор поцкаля умеет расширенные шаблоны asm-вставок как GCC?

> Это ты с C перепутал, там арифметика с указателями:)
> А преобразование из указателя в числа: 
>  ты, наверное, имеешь ввиду Seg(P), Ofs(P)? 
> дык, это к языку отношения не имеет - это узкоплатформенные (DOS-only) ФУНКЦИИ.

нет, я имел в виду что то вроде

type intptr = ^integer;
var p : intptr;
..
p = intptr(integer(p) + sizeof(integer));

Кстати только что проверил - написал решето эратосфена, паскаль
процентов на 20 медленнее. Хотя конечно тоже неплохо, но для
таких тривиальных алгоритмов, которые должны ложиться в ассемблер
один в один, это странно, как минимум.

~/tmp/tests/1 $ cat test.c
#include <stdlib.h>
#include <stdio.h>

#define N 100000000

int main(void)
{
    static char nprime[N];
    int i, j;
    int primes_count;

    for (i = 2; i < N;) {
        for (j = i * 2; j < N; j += i)
            nprime[j] = 1;

        do {
            ++i;
        } while (i < N && nprime[i] == 1);
    }

    primes_count = 0;
    for (i = 0; i < N; ++i)
        if (nprime[i] == 0)
            ++primes_count;

    printf("%d\n", primes_count);

    return 0;
}
~/tmp/tests/1 $ gcc -o c -O3 test.c
~/tmp/tests/1 $ time ./c
5761457
6.571 secs
~/tmp/tests/1 $ time ./c
5761457
6.568 secs
~/tmp/tests/1 $ time ./c
5761457
6.580 secs
~/tmp/tests/1 $ cat test.pas
program primes;

const N = 100000000;

var
    nprime : array [0 .. N - 1] of byte;
    i, j : longint;
    primes_count : longint;

begin

    i := 2;
    while i < N do begin
        j := i * 2;
        while j < N do begin
            nprime[j] := 1;
            j := j + i;
        end;

        repeat
            i := i + 1;
        until (i >= N) or (nprime[i] = 0);
    end;


    primes_count := 0;
    for i := 0 to N - 1 do begin
        if nprime[i] = 0 then
            primes_count := primes_count + 1;
    end;

    writeln(primes_count);
end.
~/tmp/tests/1 $ fpc -opas test.pas -O3
Free Pascal Compiler version 2.0.4 [2007/01/28] for i386
Copyright (c) 1993-2006 by Florian Klaempfl
Target OS: Linux for i386
Compiling test.pas
Linking pas
33 Lines compiled, 0.0 sec
~/tmp/tests/1 $ time ./pas
5761457
8.159 secs
~/tmp/tests/1 $ time ./pas
5761457
8.076 secs
~/tmp/tests/1 $ time ./pas
5761457
8.163 secs

А ты дельфями компилируй, наверное будет не медленнее а быстрее.

>В том-то и дело, что gas -- очень мощная штука. TASM поддерживает mov из/в control registers? debug registers? ltr, str и пр.?

Я не понял: ты что с чем сравниваешь? Ты хочешь убедить, что gas "круче" паскаля? Ок, убедил. А теперь хватай ранец и беги в школу, не опаздывай!:)

> Как-то слабо соотносится вот с этим утверждением:

Это тоже "вызываеще неверная информация". Я паскаль использую со времён знаменитого 5.5, когда ещё вставок не было. Когда они появились, тогда никакого ассемблера в дистрибутиве не было, компилятор справлялся своими силами.

Вообще, не понятно, что вы имеете ввиду под низким уровнем. Ассеблерные вставки - это именно вставки, не часть языка. Что было в паскале (во времена DOS, когда доступ к железу мог быть актуальным): Работа с портами ввода-вывода средствами языка; Привязывание переменных к абсолютному адресу памяти; Ну, разумеется, возможность создавать произвольные динамические структуры. Я просто не знаю, что вы считаете низкоуровневыми средствами.

> Я не понял: ты что с чем сравниваешь? Ты хочешь убедить, что gas "круче" паскаля? Ок, убедил. А теперь хватай ранец и беги в школу, не опаздывай!:)

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

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

Дык я выше (http://www.linux.org.ru/jump-message.jsp?msgid=1923981#1924956) вроде ясно указал некоторые средства, необходимые для системного программирования. Может быть вы просветите, связка компилятор паскал + TASM имеет их поддержку?