C programming, float возвращает 0

почему нельзя сразу написать if((int)Y < X) ?

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

которое у тебя почему-то беззнаковое?

Не почему-то а как правило потому что идет работа с чужим кодом где программист придерживается другого стиля.

может типа этого: http://en.wikipedia.org/wiki/Variadic_templates

Слишком сложно для вещи, которая должна быть простой.

Ну например if(x=foo(y)) это тоже ошибка

С чего это? Ошибки нет. Чтобы не смущало надо конечно еще одни круглые скобки добавить.

И даже наверняка - в 64х битных архитектурах int по идее должен быть 64х битный (естественный), а long & long long побольше.

Вот что 32-bit-only слака с людьми делает. «Программисты» даже не знают размеров типов на 64х битных системах.

Вот только для printf(3) какая нафиг разница, что выводить? Лишь-бы не обрезало...

Тогда ответь с какими модификаторами надо выводить int64_t, чтобы не было ворнингов. Считаем, что sizeof(int64_t) == sizeof(long long).

твой int64_t это и есть шаманство (typedef, #define не важно). Сюрприз?

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

И по определению НЕ кросплатформено.

Не правда. В C99 есть эти типы.

Это - объект. Хоть и тривиальный

Не спец в C++ но разве к объектам применим спецификатор register

Я уже выше сказал: хренушки!

Не нужно прилюдно хвалиться веществами.

Тут уже страницы на 3 веществ: Reset упорно пропихивает свои плюсы туда, куда не нужно.

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

Не умеешь ты сливать с достоинством. Уже дважды за тред с позором.

input = fopen(«input.txt»,«r»); //assigning file to a variable

untill it will be the End Of File

жжошь. напалмом.

ну давай, расскажи как кроссплатформенно вывести int64_t в printf

Если не брать во внимание, что такого типа может не существовать:

#include <stdio.h>
#include <inttypes.h>

int main(void)
{
    int64_t val = 42;
    printf("%" PRId64 "\n", val);
    return 0;
}

Или речь шла именно о C++?

Во-первых, теряем всю лаконичность printf'а, во-вторых, это в стандарте есть или обвешивать ifdef'ами надо?

Не спец в C++ но разве к объектам применим спецификатор register

этот спецификатор уже лет 20 не используют. Но в принципе - почему нет? Класс вполне может влезать в регистр.

работает

#include <stdio.h>


class X
{
	private:
		int data;
	public:
		X(): data(100)
		{
		}
		~X()
		{
		}
		int xxx(int x)
		{
			printf("%d\n", x);
			return 0;
		}
};


int main()
{
	register X x;
	x.xxx(123);
	printf("%d\n", sizeof(x));
	return 0;
}

Во-первых, теряем всю лаконичность printf'а

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

это в стандарте есть или обвешивать ifdef'ами надо?

В C99

отлично, блин. Ради одного жалкого принтфа тащить весь буст. Отличная идея. Просто офигительная.

> equery size boost
 * dev-libs/boost-1.51.0-r1
         Total files : 31339
         Total size  : 289.30 MiB

а потом ещё удивляются хренли фаерфогз так много памяти жрёт. Нет, правда.

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

с этим я согласен. но что делать, если так ДОЛЖНО быть?

Не почему-то а как правило потому что идет работа с чужим кодом где программист придерживается другого стиля.

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

Слишком сложно для вещи, которая должна быть простой.

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

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

С чего это? Ошибки нет.

это СЕЙЧАС нет. А ПОТОМ я пойму этот код неправильно. Впрочем для writeonly пойдёт.

Вот что 32-bit-only слака с людьми делает.

подотри хладагент. слака уже давно 64х битная.

«Программисты» даже не знают размеров типов на 64х битных системах.

и не должны знать. Которые без кавычек. Нормальный программист должен писать код, который одинаково хорошо работает на ЛЮБОЙ архитектуре.

Тогда ответь с какими модификаторами надо выводить int64_t, чтобы не было ворнингов. Считаем, что sizeof(int64_t) == sizeof(long long).

ни с какими. тип int по определению нативный, т.е. такой, с которым ЭТОТ процессор работает без костылей, как родной. Типы long и long long нужны для того, что-бы работать с большИми числами, они могут быть больше int, и могут быть медленнее, и с костылями. А вот конкретный размер для того и не фиксирован, что-бы код для 16и битных машин без изменений работал и на 32х битных и на 64х битных системах, при этом, большинство расчётов будет в нативном самом быстром на ЭТОЙ машине типе.

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

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

И по определению НЕ кросплатформено.

Не правда. В C99 есть эти типы.

правда. если ты везде натыкаешь своих int64, а я своих int, то мой код будет работать в разы быстрее как на устаревших 32х битных, так и на прогрессивных 128и битных. А твой будет привязан к 64м битам.

и? Это всё равно туева хуча кода, который делает то же, что есть уже в libc (не считая проверки типов). Меня несколько смущает ситуация, когда тот же firefox компилируется дольше ядра и отжирает по 6 гигабайт места для сборки.

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

выше уже показано, во сколько раз твой код длиннее printf(3).

подотри хладагент. слака уже давно 64х битная.

Судя по вот этому отжигу «И даже наверняка - в 64х битных архитектурах int по идее должен быть 64х битный (естественный), а long & long long побольше.» 64х битные системы ты видел только на картинках.

Нормальный программист должен писать код, который одинаково хорошо работает на ЛЮБОЙ архитектуре.

Судя по твоим высказываниям ты на это не способен.

не единственный. учи матчасть.

Давай тогда второй способ, «знаток» матчасти.

является-ли этот тип нативным или костыльным.

Что такое «нативный» тип, а что такое «костыльный»? И в чем заключаются «костыли»?

правда.

стандарт открой и не позорься

я своих int, то мой код будет работать в разы быстрее

Во-первых, в разы быстрее работать не будет, во-вторых, ты наловишь глюков, связанных с сериализацией/десериализацией некроссплатформенных типов, в-третьих, как делать счетчики (32-bit int это часто очень мало)?

А твой будет привязан к 64м битам.

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

Ну и? Это ничто по сравнению с размерами целого софта.

И даже наверняка - в 64х битных архитектурах int по идее должен быть 64х битный (естественный)

Поискал архитектуры использующие модель ILP64. Нашел только Cray.

отлично, блин. Ради одного жалкого принтфа тащить весь буст. Отличная идея. Просто офигительная.

boost::format - «header only» либа.

Судя по вот этому отжигу «И даже наверняка - в 64х битных архитектурах int по идее должен быть 64х битный (естественный), а long & long long побольше.» 64х битные системы ты видел только на картинках.

уважаемый, ты очевидно не видел 16и битных и 32х битных систем, и не знаешь, какой был весёлый переход из-за таких как ты #&##^*(, которые «точно знали ширину int'а».

а вот что пишут те люди, которые эти твои int'ы и придумали:

- Можно использовать до трех размеров целых, описывае- мых как short int, int и long int. Длинные целые занимают не меньше памяти, чем короткие, но в конк- ретной реализации может оказаться, что либо короткие целые, либо длинные целые, либо те и другие будут эквивалентны простым целым. «Простые» целые имеют естественный размер, предусматриваемый архитектурой используемой машины; другие размеры вводятся для удовлетворения специальных потребностей.

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

из-за таких как ты #&##^*(, которые «точно знали ширину int'а».

Я где-то сказал, что я знаю точно ширину инта? Я знаю ширину на актуальных для меня платформах, а когда мне нужно быть 100% уверенным в том, что sizeof(int) == 4 я использую int32_t.

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

Не смотря на твой «огромный опыт в программировании» (в чем я очень сильно сомневаюсь по твоим безграмотным отжигам в development) вот это — «И даже наверняка - в 64х битных архитектурах int по идее должен быть 64х битный (естественный), а long & long long побольше.» не верно! Размер инта сейчас почти везде равен 4 (32 бита) и даже на 64х битных архитектурах (!!!)

когда мне нужно быть 100% уверенным в том, что sizeof(int) == 4 я использую int32_t.

Тут ты дал маху, т.к. на некоторых платформах sizeof(int32_t) != 4

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

Хм... интересно. Это на каких же платформах int32_t != 32 бита?

Ы! Я загуглил и нашел! Клево! Не знал, что такое бывает.

Короче, на некоторых микроконтроллерах байт - не всегда 8 бит.

Тут ты дал маху, т.к. на некоторых платформах sizeof(int32_t) != 4

Ты попутал с int_least32_t и int_fast32_t. sizeof(int32_t) == 4 по определению и другого быть не может.

В древности были компы с 9 битными байтами. Только вот я не могу понять как в них может вписаться тип фиксированного размера в битах?

Не смотря на твой «огромный опыт в программировании» (в чем я очень сильно сомневаюсь по твоим безграмотным отжигам в development) вот это — «И даже наверняка - в 64х битных архитектурах int по идее должен быть 64х битный (естественный), а long & long long побольше.» не верно! Размер инта сейчас почти везде равен 4 (32 бита) и даже на 64х битных архитектурах (!!!)

читать-то научись... Где тут написано «везде 64 бита в int»? В твоих влажных мечтах?

Хм... интересно. Это на каких же платформах int32_t != 32 бита?

очевидно в тех, где char не 8и битный. Потому-как sizeof меряет не в байтах, а в char'ах. Кстати никто никогда не гарантировал, что char == байт.

влажные мечты как раз озвучил ты своим «__по идее__ __должен__ ...»

Короче, на некоторых микроконтроллерах байт - не всегда 8 бит.

есть разница между char и байтом. char это вообще-то «символ», и не более того.

sizeof(int32_t) == 4 по определению и другого быть не может.

пруф можно?

влажные мечты как раз озвучил ты своим «__по идее__ __должен__ ...»

это если и мечты, то совсем не мои, а Кернигана и Ричи. Цитата из них выше, а вот то, что ты с классикой жанра не знаком, говорит очень многое о твоей квалификации. Это как «физик» незнакомый с трудами Ньютона. Впрочем, такому ГСМу как ты не понять... Ну как «художник», не понимающий, что за картинка под названием Мона Лиза. Не вызывает ничего, кроме улыбки...

Да ну? Тогда давай номер страницы.

Да ну? Тогда давай номер страницы.

параграф 3.1

страницы не было в той версии, которую я когда-то читал(извиняй, тот файл давно утерян. вот нагуглил что-то похожее: http://lib.ru/MAN/DEMOS210/c.txt).

ISO/IEC 9899:1999, p255

7.18.1.1 Exact-width integer types
1 The typedef name intN_t designates a signed integer type with width N, no padding
bits, and a two’s complement representation. Thus, int8_t denotes a signed integer
type with a width of exactly 8 bits.
2 The typedef name uintN_t designates an unsigned integer type with width N. Thus,
uint24_t denotes an unsigned integer type with a width of exactly 24 bits.
3 These types are optional. However, if an implementation provides integer types with
widths of 8, 16, 32, or 64 bits, it shall define the corresponding typedef names.

То есть на платформах с 8ми битным байтом, коих 99.99999%, будет именно так. На платформах с 9ти битным байтом, очевидно, этих типов не будет.

понятно, слив засчитан

sizeof(int32_t) == 4 по определению и другого быть не может.

7.18.1.1 Exact-width integer types 1 The typedef name intN_t designates a signed integer type with width N, no padding bits, and a two’s complement representation. Thus, int8_t denotes a signed integer type with a width of exactly 8 bits. 2 The typedef name uintN_t designates an unsigned integer type with width N. Thus, uint24_t denotes an unsigned integer type with a width of exactly 24 bits. 3 These types are optional. However, if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, it shall define the corresponding typedef names.

где тут хоть слово про sizeof?

sizeof(char) == 1 (по определению) Размер char'а в битах = 8 почти всегда. Дальше сам догадаешься?

sizeof(char) == 1 (по определению) Размер char'а в битах = 8 почти всегда. Дальше сам догадаешься?

демагогия. char не всегда имеет размер 8 бит. Этого нигде не записано. И не записано, что так будет всегда. Потому ты опять позорно слил...

Ну учи же матчасть, или хоть голову подключи - на кой хрен через 30 лет после изобретения ЯП застандартиризировали твои intN_t? А до этого как жили? Городили костыли #define? Дурачки? Или в этом есть какой-то сакральный смысл, который ты по неопытности/дурости не осилил?

демагогия. char не всегда имеет размер 8 бит. Этого нигде не записано. И не записано, что так будет всегда

не записано, но это стандарт де факто и никто не будет переделывать over9000 софта и железа, которое уже считает, что в чаре 9 бит.

Потому ты опять позорно слил...

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

Городили костыли #define?

ога

Дурачки?

нет, потому что эти костыли в виде stdint.h стандартизировали

Или в этом есть какой-то сакральный смысл, который ты по неопытности/дурости не осилил?

Ты что предлагаешь? везде свои велосипедные ifdef'ы генерить вместо уже написанных? Да тебя на пушечный выстрел к разработке пускать нельзя!

Интересно, спасибо.

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

я тебе намекал на две вещи:

1. сколько битов в char'е нигде не записано, и не стандартизировано.

2. сколько char'ов в int'е тоже нигде не записано, и стандартов нет, и быть не может

И это не баг, а фича - учи историю, язык C стал популярен как раз по большей части потому, что позволял писать кросплатформенный код, в котором был тип «символ», и тип «целое число», и это при том, что в том-же ассемблере такие типы тоже имелись, для любой архитектуры. Но конкретный размер их был везде разный, и мало того, ещё и менялся. Именно потому код для старого CPU можно было выкидывать в помойку, с выходом нового. А вот код на C отлично работал, разве что с незначительными переделками.

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

не записано

ну и кто слил?

нет, потому что эти костыли в виде stdint.h стандартизировали

т.е. 30 лет - это совсем недолго для языка программирования? Ну подумаешь - чутка забыли, и вот, через 30 лет - ВНЕЗАПНО вспомнили! Ну откуда тебе это знать-то? Ладно, расскажу - эти 30 код, который был жёстко привязан к железу, предпочитали писать на ассемблере. Потому фиксированные intN_t были не слишком и нужны. За 30 лет процессоров стало настолько много, и они стали настолько разными, что уже был смысл использовать компилятор, да к тому-же мы подошли к пределу битности - увеличивать число битов более 32х или 64х уже нет смысла - в нашем мире просто считать нечего с такой детализацией. Натуральные числа - всего лишь никому не нужная абстракция, которая IRL нужна лишь тогда, когда приложена к конкретным объектам. А где найти 18 446 744 073 709 551 616 объектов которые имеет смысл считать?

Ты что предлагаешь? везде свои велосипедные ifdef'ы генерить вместо уже написанных? Да тебя на пушечный выстрел к разработке пускать нельзя!

ты упоролся? какие ifdef'ы я предлагал? Ты вообще читаешь мои посты? Если тебе НУЖНА битность в 32 бита - юзай int32_t, но расскажи, ГДЕ она нужна? Обычно IRL нужно целое число, которое является естественным для процессора. Конкретное число бит очевидно зависит от самого процессора, и не забывай про тот факт, что в общем случае 32х битное целое вычисляется ровно вдвое быстрее и занимает ровно вдвое меньше памяти, чем 64х битное. Потому предлагать использовать ВЕЗДЕ 64х битное число может только идиот.

я тебе намекал на две вещи:

1. сколько битов в char'е нигде не записано, и не стандартизировано.

2. сколько char'ов в int'е тоже нигде не записано, и стандартов нет, и быть не может

Я знаю и что?

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

Чтобы без переделок сделали типы (u)intN_t

ну и кто слил?

Очевидно, что ты, ибо приписал Кернигану то, чего у него нет.

Ну подумаешь - чутка забыли, и вот, через 30 лет - ВНЕЗАПНО вспомнили!

Очевидно, что оно было и до стандартизации.

А где найти 18 446 744 073 709 551 616 объектов которые имеет смысл считать?

В реальных системах их число часто переваливает за 1<<32

ты упоролся? какие ifdef'ы я предлагал? Ты вообще читаешь мои посты?

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

Если тебе НУЖНА битность в 32 бита - юзай int32_t, но расскажи, ГДЕ она нужна?

Например, при передачи данных по сети, сохранении в файл ...

Потому предлагать использовать ВЕЗДЕ 64х битное число может только идиот.

Согласен, но если бы ты умел читать (а история с Керниганом говорит, что ты на это не способен), то увидел бы, что я этого _нигде_ не предлагал.

Чтобы без переделок сделали типы (u)intN_t

ну тебе осталось указать мне, неразумному, КОГДА надо юзать int, а когда intN_t?

1. сколько битов в char'е нигде не записано, и не стандартизировано.

Я знаю и что?

то, что «sizeof(int32_t)==4» не является тождеством.

Кроме того, мы не можем знать того, что sizeof(int)!=8. Если архитектура 64х битная, то int вполне логично 64х битный.

ну тебе осталось указать мне, неразумному, КОГДА надо юзать int, а когда intN_t?

Я уже говорил это. Когда важен фиксированный размер, например, при передачи данных по сети, сохранении в файл ...

то, что «sizeof(int32_t)==4» не является тождеством.

В случае 8ми битного чара это так.

Кроме того, мы не можем знать того, что sizeof(int)!=8.

да

Если архитектура 64х битная, то int вполне логично 64х битный.

нет, запусти наконец компилятор на 64х битной слаке и проверь

Я уже говорил это. Когда важен фиксированный размер, например, при передачи данных по сети, сохранении в файл ...

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

В случае 8ми битного чара это так.

и кто с этим спорил?

Если архитектура 64х битная, то int вполне логично 64х битный.

нет, запусти наконец компилятор на 64х битной слаке и проверь

ну посмотри на, скажем Borland C 3.1, на котором я быдлокодил в молодости (90е годы прошлого века), там int 16и битный, хотя компьютеры тогда были уже 32х битные. И пионэры тех времён тоже кричали - «запусти и посмотри!».