Системы на базе Itanium - самые плохо продаваемые в мире

"...За использование scanf - руки надо отрывать однозначно...". Руки надо поотрывать анонимусам, которые нефига не понимают. Чем прикажешь пользоваться на С (не на С++)? А на чистом С написано очень много софта.

> Руки надо поотрывать анонимусам, которые нефига не понимают.

Сам дурак. (Если не понял почему см. пример от Die-Hard)

> Чем прикажешь пользоваться на С (не на С++)?

atoi и т.д. Если нужно распарсить,что-то посложнее - lex.

> А на чистом С написано очень много софта.

Сапасибо за информацию.

> Бредить то не надо: разница указателей типа size_t
Не ptrdiff_t? Кстати о бреде...

anonymous (*) (2003-09-05 18:28:13.135388):

> Сам дурак. (Если не понял почему см. пример от Die-Hard)

Какие вы, анонимусы, в массе своей ограниченные!

Я привел пример scanf'а как простейший. Есть же масса других библиотечных функций, принимающих УКАЗАТЕЛИ на целые! И ты их таким хаком вводишь в заблуждение.

> Если нужно распарсить,что-то посложнее - lex.

Можно гвозди микроскопом забивать.

А я простейшие строки sscanf'ом парзю - и прекрасно все работает - и на 32 битах, и на 64, и на всех индейцах.

Уважаемый Die-Hard!

Что Die-Hard == Eugene_Korobko? > Какие вы, анонимусы, в массе своей ограниченные!

_в_массе_ все ограниченные

> Я привел пример scanf'а как простейший.

А atoi в данном случае было бы к месту.

> Есть же масса других библиотечных функций, принимающих УКАЗАТЕЛИ на целые!

Но

а) scanf - самая позорная из них

б) никто не заставляет вас их использовать.

> И ты их таким хаком вводишь в заблуждение.

Энтот глупый "хак" предложил другой анонимус. Я же указал на явную неправдоподобность вашего примера, свидетельствующую о том, что с Си вы плотно не работаете. (Впрочем это все уже поняли, посмотрев вашу "программу на Си" в треде на тему "fortan vs C" нескольно месяцев назад).

> Можно гвозди микроскопом забивать.

Это вы про обработку текста на голом Си?

> А я простейшие строки sscanf'ом парзю - и прекрасно все работает - и на 32 битах, и на 64, и на всех индейцах.

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

Мдэ, слушал я вас, слушал - и сам не вытерпел .... 8)

Что пень 4 что все 64х получились у Интела мягко говоря ни в пи... не совсем вобщем получились. Сравните хотя бы производительность третьего и четвертого пенька при одинаковой частоте CPU - и все станет на свои места ... (только не надо пузыри пускать про SSE2 8)

Эта история повторяется не единожды - вспомните первый пень vs dx(AMD) - он им позорно сливал - это и послужило толчком к выпуску вторых пней.

Что будет сейчас - трудно сказать - мутно все ...

Будут чегото делать - ясен перец.

anonymous (*) (2003-09-05 20:31:43.524446):

Просто слов нет.

У тебя с логикой БОЛЬШИЕ проблемы.

>> Есть же масса других библиотечных функций, принимающих УКАЗАТЕЛИ на целые!

...

> никто не заставляет вас их использовать.

Спорить с тобой, конечно, глупо, но вот (например) в данный момент я отвлекся от изучения того, что мне возвращает такая функция:

man MPI_Iprobe

int MPI_Iprobe(int src, int tag, MPI_Comm comm, int *flag, MPI_Status *stat)

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

Ладно, спор, в общем-то, беспредметный. Я не по наслышке знаком с проблемами, возникающими при портировании программ с 32 бит на 64. Если ты считаешь, что проблем таких нет - что ж, ты не прав.

> Я могу только повториться: в 32-битных системах разница поинтеров
> всегда int.

А не long? ;)

> Про это говорили создатели языка, этим люди широко пользовались, и это не считалось ошибкой.
> При переходе 32->64 это может породить проблемы.
> С чем ты не согласен?

Странный ты человек. В одном месте жалуешься, что программисты предполагают sizeof(long)==sizeof(int), а в другом утверждаешь, что
ptrdiff==int.

Существует _специальный_ тип для разницы указателей. Если программист использует вместо него любой другой тип -- он ССЗБ.

> Кстати, под ДОСом в распространенной large модели вычитание
> поинтеров вообще приводило к бредовым результатам.

Так в чём проблема-то? Придумай такой ptrdiff и такую арифметику указателей, которые работали бы с этой моделью памяти (и поддерживались компилятором). Не используй вместо типа ptrdiff тип int.

> #include <stdio.h>
> #define int long
>
> int main(void)
> {
> int a=-1;
> long b=0;
> scanf("%d",&a);
> b=a;
> printf("Res:%ld\n",b);
> return 0;
> }

Добавляем в список требований неиспользование *scanf/*printf. Либо коррекцию форматов ввода/вывода.
Хотя ты прав, разумеется. ;)

ЗЫ: И в целом я с тобой согласен: программы, написанные безо всяких мыслей о переносимости, портировать тяжело. ;)

мда... переносимость... как много в этом звуке... для сердца... русского... фигня всё. unaligned access, endianness и binary storage-- вот главные враги переносимости _внутри_одной_системы_. Из которых тока binary storage важен для x86 -> x86-64. Если кто не в курсе, то на 64бит-платформах sizeof(int) == 4, sizeof(long) == 8, именно для упрощения переносимости. ptrdiff_t по сути своей _эквивалентен_ size_t, не надо ломать копья, malloc принимает именно size_t, strlen возвращает size_t -- значит size_t _достаточен_ для разницы указателей _в_рамках_одного_массива_, как и ptrdiff_t. Пример с far указателями ДОС не корректен, там не давали для массива больше 64к, вообще этот тип указателя не укладывался в модель процессора для языка Си.

Мурр -- дурак. "крепкий орешек" никада не писал переносимо, тока видел на картинках. И только автор ifcico никого не обидел...

AMD процы с Power-ским, ядром надерут задницу в на рынке 64

> Просто слов нет.

Зачем тогда отвечать? В свете такого вашего заявления и следующая ваша фраза звучит глуповато.

> У тебя с логикой БОЛЬШИЕ проблемы.

Не только с логикой. Но это мои проблемы.

> Спорить с тобой, конечно, глупо,

Не надо спорить. Просто приведите кусок проблемного кода (имхо проблем быть не должно, если НЕ делать #define int long). И имейте в виду, что вы даете повод для ответа - "Нефиг пользоваться разными кривыми библиотеками, авторы которых не задумываллись о портабельности".

Или вы рекламируете http://www-unix.mcs.anl.gov/mpi/?

> Если ты считаешь, что проблем таких нет - что ж, ты не прав.

Если вы считаете что в 192. году Земля налетела на небесную ось - вы не правы.

"народ, а какая разница в скорости для цикла for на 32-х битной и 64-х битной системах?"

А какая разница в mmap на 64 и 32 системах? И в чем разница между read() и mmap? А ведь за сэкономленное время можно столько циклов накрутить....

anonymous (*) (2003-09-06 12:05:57.25037):

> Если кто не в курсе, то на 64бит-платформах sizeof(int) == 4, sizeof(long) == 8, именно для упрощения переносимости.

Нет. Вот тебе ссылка: http://www.opengroup.org/public/tech/aspen/lp64_wp.htm Посмотри в конец, на SUMMARY. Portability там выступает только одним из 5 критериев выбора LP64.

> ptrdiff_t по сути своей _эквивалентен_ size_t, ...

("... - Дык, где же суть? - А прямо на песочек...")

Это - 5! Оказывается, знаковые целые по своей сути _эквивалентны_ беззнаковым! То есть мне понятно происхождение следующей фразы:

> Мурр -- дурак. "крепкий орешек" никада не писал переносимо, тока видел на картинках.

2anonymous (*) (2003-09-06 18:12:32.090309):

> ...приведите кусок проблемного кода (имхо проблем быть не должно, если НЕ делать #define int long)

Вы, эта... Сами с собой переписываетесь?

Впрочем, пожалуйста:

{char **c=calloc(32536, 4);c[32535]="Hellow, anonymous!\n";printf(c[32535]);}

Все Ваши требования выполнены: #define int long не делается, на ILP32 все работает, на LP64 немедленный сегфолт.

Я не понимаю, что Вы хотите сказать. Т.е. ВООБЩЕ не вижу смысла в Ваших ответах.

anonymous (*) (2003-09-06 03:10:05.395395):

> Странный ты человек. В одном месте жалуешься, что программисты предполагают sizeof(long)==sizeof(int), а в другом утверждаешь, что ptrdiff==int.

А чего странного? Я говорю о проблемах перехода 32->64. В ILP32 long==int; ptrdiff_t==int; в LP64 это не так. Что непонятного?

> Существует _специальный_ тип для разницы указателей. Если программист использует вместо него любой другой тип -- он ССЗБ.

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

Мои программы должны работать не только на Интелях и компилиться не только ЖеЦеЦе. Не везде есть ptrdiff_t. Не всегда можно работать с ptrdiff_t, пример: ...char *a1,*a2; ptrdiff_t d; ... d=a1-a2; - Оп! Как мне распечатать, чему оно равно? Единственный способ "совместимый" с ILP32 <-> LP64: {long dd=d; printf("%ld",dd);} А если LLP64 (int=long!=longlong; pointer 64)?

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

Die-Hard (*) (2003-09-05 14:19:39.039894)

SunFire V1280 вас спасет.

> char **c=calloc(32536, 4);

Ха-ха-ха. Про sizeof, я так понимаю, уважаемый Die-Hard ничего не знает? Даю намек char **c = calloc(32536, sizeof(char*));

> c[32535]="Hellow, anonymous!\n";printf(c[32535]);}

И вы здравствуйте.

> Все Ваши требования выполнены: #define int long не делается, на ILP32 все работает, на LP64 немедленный сегфолт.

Не все. Код должен быть на Си.

> Я не понимаю, что Вы хотите сказать. Т.е. ВООБЩЕ не вижу смысла в Ваших ответах.

anonymous (*) (2003-09-08 16:41:55.768684):

> Не все. Код должен быть на Си.

Ага. Теперь понимаю.

Вы не знаете, что такое Си. Наверное, Вы думаете, что я привел Вам пример на C#.

> Вы не знаете, что такое Си.

Как трогательно слышать это от Die-Hard, не подозревающего о существовании sizeof и поразившего ЛОР нетривиальным использованием оператора ",".

anonymous (*) (2003-09-08 17:21:47.547675)

Про оператор "," - признаЮ, позорно прогнал. Кстати, если Вы помните ту дискуссию, я САМ же и поправился, пока анонимус (Вы, наверное?) изголялся в оскорблениях.

> Как трогательно слышать это от Die-Hard, не подозревающего о существовании sizeof

А почему Вы решили, что я не подозреваю о его существовании? Вы просили (Зачем? - не знаю) пример проблемного кода на Си. Я привел Вам пример, удовлетворяющий всем Вашим требованиям. Почему-то Вы после этого сделали вывод, что я не подозреваю о существовании sizeof. Сразу напрашивается соответствующий вывод об уровне Вашей логики и умению вести дискуссию.

Мой же вывод ("Вы не знаете, что такое Си") вполне логически обоснован:

anonymous (*) (2003-09-08 16:41:55.768684):

>> Все Ваши требования выполнены: #define int long не делается, на ILP32 все работает, на LP64 немедленный сегфолт.

> Не все. Код должен быть на Си.

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

Вариант: у Вас свое, глубоко интимное определение того, что же такое "Код на Си". Тогда, конечно, я не в силах привести пример - впрочем, зачем Вам понадобился пример, не совсем понятно.

> Кстати, если Вы помните ту дискуссию, я САМ же и поправился, пока анонимус (Вы, наверное?) изголялся в оскорблениях.

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

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

Предлагалось привести кусок грамотно написанного кода на Си, который порождал бы проблемы при переходе с 32 на 64 битовую систему. Ваш кусок содержал ужасающе неправдоподобный ляпсус.

> Т.о. Вы полагаете, что приведенный мной кусок кода не на Си. Утвержение, очевидно, ложное, поскольку приведенный кусок кода скомпилится любым Си компилером.

Кусок кода написан безграмотно и приводит к ошибкам, вывод - этот текст не является "кодом на Си", а является просто набором Си-конструкций. Если я на бумажке напишу "100 рублей", деньгами она от этого не станет.

anonymous (*) (2003-09-08 20:11:55.389059):

> На ошибку вам указал сразу, а извиняться (с большой неохотой) вы принялись лишь на следующий день.

У Вас провалы в памяти? Ваше "указание на ошибку" состояло в утверждении, что приведенный мною код "просто ужасен".

> Предлагалось привести кусок грамотно написанного кода на Си, который порождал бы проблемы при переходе с 32 на 64 битовую систему.

Это Вам, наверное, приснилось. Вы сначала почему-то взъелись на функцию scanf в моей демонстрации проблем, порождаемых #define int long, а потом зачем-то попросили "Просто приведите кусок проблемного кода ... если НЕ делать #define int long..." Я привел требуемый Вами кусок - исключительно с целью демонстрации отсутствия логики в ваших ответах. Вы же продолжаете спорить сами с собой.

> Кусок кода написан безграмотно и приводит к ошибкам, вывод - этот текст не является "кодом на Си", а является просто набором Си-конструкций.

Т.е. верной оказалась моя вторая гипотеза - у Вас особое, глубоко интимное понятие того, что удовлетворяет определению "код на Си".

Ладно, наш спор беспредметен. Вам не нравятся функция scanf и библиотека MPI, зато очень нравится функция atoi и еще Вы любите lex. У Вас есть некое нетривиальное сугубо личное определение того, что такое "код на Си". Кроме того, Вы уверены, что я не знаю про оператор sizeof и плотно не работаю с Си.

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