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

извини, дядя, но в C++ никакого boost:: нет

В стандарте нет, но никто не запрещает его использовать.

Как и printf(3), кстати, нет в C.

4.2

The fprintf(), printf(), sprintf(), vprintf(), vfprintf(), and vsprintf() functions conform to C89 and C99.

А если он у тебя СЕЙЧАС в голове, то что ты не напишешь a<b ? b:a; Почему?

Потому что max(a,b) написать быстрей.

В стандарте нет, но никто не запрещает его использовать.

тем более никто не запрещает использовать какие-то свои методы. не обязательно boost::.

The fprintf(), printf(), sprintf(), vprintf(), vfprintf(), and vsprintf() functions conform to C89 and C99.

точно. это я как-то позабыл...

А если он у тебя СЕЙЧАС в голове, то что ты не напишешь a<b ? b:a; Почему?

Потому что max(a,b) написать быстрей.

Если без пробелов и точек с запятой, то мой вариант короче на 1 символ. Не цепляйся, моё конгфу всё равно круче (:

IRL я предпочитаю inline функцию для удобочитаемости.

тем более никто не запрещает использовать какие-то свои методы. не обязательно boost::.

Сейчас это имеет смысл делать только для обучения.

Сейчас это имеет смысл делать только для обучения.

тогда какой смысл в СВОИХ классах? А если ты навернул СВОЙ класс, то разве не логично выводить его в поток как-то по-своему? А уж там внутри через printf, или через boost, раз он так тебе нравится.

тогда какой смысл в СВОИХ классах?

В своих классах имеет смысл делать только то, чего нет в библиотеках.

А если ты навернул СВОЙ класс, то разве не логично выводить его в поток как-то по-своему?

Логично

В своих классах имеет смысл делать только то, чего нет в библиотеках.

в какой библиотеке есть вывод МОЕГО класса?

Логично

логично что cout это вообще-то частный случай std::ostream, и вообще говоря, для своего класса можно и свой интерфейс сделать для любого std::ostream. А ещё и например для ofstream, что-бы в файлы выводить.

в какой библиотеке есть вывод МОЕГО класса?

Я не про твой класс, а про твой type-safe аналог printf'а. Зачем его изобретать, если он уже изобретен ?

логично что cout это вообще-то частный случай std::ostream, и вообще говоря, для своего класса можно и свой интерфейс сделать для любого std::ostream. А ещё и например для ofstream, что-бы в файлы выводить.

Можно, только речь о том, что iostream не годится для форматированного вывода. Примеры в этом треде уже были.

http://stackoverflow.com/questions/3437404/min-and-max-in-c

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

Я не про твой класс, а про твой type-safe аналог printf'а. Зачем его изобретать, если он уже изобретен ?

а кто тебе сказал, что мне нужен именно аналог printf(3), который умеет выводить все тривиальные типы во всех мыслимых форматах? мне очевидно нужен просто вывод в одном каком-то конкретном формате. И тривиальный int мне проще вывести тривиальным printf(3) или там std::ostriam::operator<<().

Можно, только речь о том, что iostream не годится для форматированного вывода. Примеры в этом треде уже были.

потому-что формат нужно не к потоку привязывать, а к объекту, который выводится. Например, как ты предлагаешь, через boost::format(). Вот только, если я хочу в своём методе вывести как-то свои приватные данные, то как я их выводить буду-то? Наворачивать константные методы-костыли для доступа только для чтения?

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

ладно, скобок хватит, но побочные эффекты и двойное вычисление всё равно осталось. max(a=foo(x), b) это в твоём случае дважды неверно, а не трижды.

И тривиальный int мне проще вывести std::ostriam::operator<<().

Годится для выдачи только в совсем тривиальном случае.

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

Предлагаешь на каждый чих по классу создавать?

class IntegerWith10Signs {
   int i;
...
};

class IntegerWith5Signs {
   int i;
...
};

побочные эффекты и двойное вычисление

а это никто и не оспаривает — это просто нужно знать.

Предлагаешь на каждый чих по классу создавать?

не по классу, а по методу. И не на каждый чих. Если тебе нужен вывод какого-то поля класса типа int как %03d, вряд-ли тебе надо %07dhh или ещё что-то. Ну если ты действительно не знаешь, что и как выводить(ага, в СВОЁМ-ТО классе!), то да, boost::format() тебе поможет.

Годится для выдачи только в совсем тривиальном случае.

ИМХО классы std::iostream годны лишь для отладочной печати и сериализации в текстовый файл. Эти случаи вряд-ли назовёшь «сложными».

не по классу, а по методу.

Тоже жесть

Если тебе нужен вывод какого-то поля класса типа int как %03d, вряд-ли тебе надо %07dhh или ещё что-то.

И почему ты говоришь о полях класса? А если я хочу вывести не поле класса, а локальную переменную?

ИМХО классы std::iostream годны лишь для отладочной печати и сериализации в текстовый файл. Эти случаи вряд-ли назовёшь «сложными».

Не годны они для этого. Пример был на первой странице.

Еще раз убеждаюсь, что разработчик из тебя как из меня оперный певец.

Зачем скатывать тему про нормальный язык программирования в плюсосрач?

Может, на танцпол перейдем?

а это никто и не оспаривает — это просто нужно знать.

а нафига мне такой макрос max(), который я постоянно в уме должен разворачивать в целях контроля?

В таком случае — нафига тебе C? Макросы надо или избегать или использовать с умом.

И почему ты говоришь о полях класса? А если я хочу вывести не поле класса, а локальную переменную?

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

Не годны они для этого. Пример был на первой странице.

а для чего годны?

Еще раз убеждаюсь, что разработчик из тебя как из меня оперный певец.

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

а для чего годны?

_Только_ для вывода уже _отформатированных_ строк.

тебя послушать, так C++ это такой пыхапэ, программирование на котором заключается в комбинировании чужих методов из boost::

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

C++ это такой пыхапэ, программирование на котором заключается в комбинировании чужих методов из boost::

Обычно программист должен писать тот код который еще не написан, а не изучать computer science за счет организации.

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

тебе никогда в голову не приходило, что в ПРИМЕРАХ на ЛОРе сознательно всё упрощают, а IRL всё намного сложнее? И если твой любимый boost катит на простых примерах, то IRL - может и не катит. В данном случае вообще вопрос по C, в котором boost'а нет, не было, и не будет. Тебя понимать как «бросайте нафиг C, переходите на boost!!!1111»? Скажи это Линусу, и ещё 100500 разрабов.

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

Я не про твой класс, а про твой type-safe аналог printf'а.

Я тут подумал - а gcc ведь знает про небезопасные функции из стандартной библиотеки наподобие printf и аргументы он таки проверяет на соответствие паттерну. Учитывая что printf в 100500 раз проще, iostream теряет свое единственное приемущество.

Я тут подумал - а gcc ведь знает про небезопасные функции из стандартной библиотеки наподобие printf и аргументы он таки проверяет на соответствие паттерну

gcc пишет только warning и только на стандартные функции, что по сути не избавляет от ошибок.

iostream теряет свое единственное приемущество.

я за iostream не агитирую, а агитирую за boost::format

Я тут подумал - а gcc ведь знает про небезопасные функции из стандартной библиотеки наподобие printf и аргументы он таки проверяет на соответствие паттерну

gcc пишет только warning и только на стандартные функции, что по сути не избавляет от ошибок.

Если рассматривать только реально встречающиеся юзкейсы, то единственное для чего нужны функции типа printf это общение программы с внешним миром, который на производных UNIX имеет только один тип данных - текст. Внутри себя программы на Си текстом не разговаривают, они всегда обмениваются указателями на структуры. Так что проверяя паттерн только в стандартных функциях мы покрываем 99.9% всех подобных ошибок.

Так что проверяя паттерн только в стандартных функциях мы покрываем 99.9% всех подобных ошибок.

Часто можно встретить обвязки над vsnprintf. В этом случае паттерн не проверяется. Да, можно конечно вкрутить костыли с помощью #ifdef'ов и __attribute__, но это костыли. И опять же, warning это warning, его можно и не заметить.

в плюсах дела обстоят _лучше_ чем в си с printf.

да? а вот эти твои %a%b после функции что означают?

А чего означают << при записи в поток? И вообще это вопрос синтаксиса. Какая разница что писать запятую или процент?

А чего означают << при записи в поток?

std::iostream::operator<<(что-то там)

В boost::format что-ли operator% перезагрузили?

И вообще это вопрос синтаксиса. Какая разница что писать запятую или процент?

запятая в printf() операцией НЕ является, а является разделителем. А вот << является операцией. Потому разница есть.

Часто можно встретить обвязки над vsnprintf. В этом случае паттерн не проверяется

Подобный функционал ни С++ ни iostreams ни boost вообще не покрывают. Ну нет в С++ keyed parameters. Такое дело.

И опять же, warning это warning, его можно и не заметить.

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

В boost::format что-ли operator% перезагрузили?

Да

запятая в printf() операцией НЕ является, а является разделителем. А вот << является операцией. Потому разница есть.

Ну и?

Ну нет в С++ keyed parameters.

а что это такое?

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

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

почему нельзя сразу написать if((int)Y < X) ? Ну если ты _действительно_ хочешь сравнить знаковое со знаковым, которое у тебя почему-то беззнаковое?

Да

и что делать со своими классами? и как это всё типонезависимо реализовано?

Ну и?

просто ты написал ерунду:

Какая разница что писать запятую или процент?

очепятался я надеюсь.

и что делать со своими классами? и как это всё типонезависимо реализовано?

http://www.boost.org/doc/libs/1_52_0/libs/format/example/sample_userType.cpp

Переопределить оператор записи в поток.

просто ты написал ерунду:

С точки зрения простоты синтаксиса разницы нет. Есть непринципиальная семантическая разница.

http://www.boost.org/doc/libs/1_52_0/libs/format/example/sample_userType.cpp

cout << format(«%02d : [%0+9d] \n») % 1 % r ;

и чем это лучше

struct Rational{
    int d;
    int n;
}r;

printf("%02d : [%0+9] \n", r.d, r.n);

ну или соответствующей перезагрузки operator<<(iostream &i, Rational &r);

?

А для встроенных типов это всё не слишком-то и надо, ибо встроенные типы прекрасно работают с (s)printf(3), причём компилятор предупреждает о кривых типах.

и чем это лучше

Тем, что если класс будет чуть сложнее, то ты затрахаешься

ну или соответствующей перезагрузки operator<<(iostream &i, Rational &r);

Тем, что это (<<) просто вывод без форматирования. С помощью format я смогу вставить вывод в любое место текста, сделать дублирование и т.д. и т.п.

А для встроенных типов это всё не слишком-то и надо, ибо встроенные типы прекрасно работают с (s)printf(3), причём компилятор предупреждает о кривых типах.

Компилятор не обязан об этом предупреждать, предупреждение можно не увидеть, есть куча проблем с размерами типов и модификаторами, которые разные на разных платформах и т.д. и т.п. В общем, boost::format лучше по всем параметрам, поэтому не вижу никакого смысла использовать printf.

Тем, что если класс будет чуть сложнее, то ты затрахаешься

с boost'ом? угу.

Тем, что это (<<) просто вывод без форматирования. С помощью format я смогу вставить вывод в любое место текста, сделать дублирование и т.д. и т.п.

ну я рад за тебя. Правда, хочу заметить, что для вывода в stdout, мне хватает printf, а для вывода скажем в окошки Qt у меня есть соотв. фишки Qt. ну как понадобится boost - открою топик, тебя скастую...

Компилятор не обязан об этом предупреждать

у меня хороший компилятор. если мне это не нужно, я юзаю PHP или баш какой-нить...

предупреждение можно не увидеть

для быдлокода у меня есть php. там это просто отключить нафиг.

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

почему Кнут писал код который одинаково хорошо работал с 6и и с 8и битовыми байтами(на асме!), а я не могу даже на C писать? Неужто я настолько тупой?

и т.д. и т.п.

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

В общем, boost::format лучше по всем параметрам, поэтому не вижу никакого смысла использовать printf.

я рад за тебя.

с boost'ом? угу.

Так в чем сложности? В примере всё очень просто. Или опять ниасиливаешь? Всё с тобой ясно!

ну как понадобится boost - открою топик, тебя скастую...

Тут вопрос не в том понадобится или не понадобится, а в том, что он обладает достоинствами printf'а и лишен его недостатков.

у меня хороший компилятор. если мне это не нужно, я юзаю PHP или баш какой-нить...

надеяться на компилятор — признак быдлокода

почему Кнут писал код который одинаково хорошо работал с 6и и с 8и битовыми байтами(на асме!), а я не могу даже на C писать? Неужто я настолько тупой?

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

у меня одна всего

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

я за iostream не агитирую, а агитирую за boost::format

anon@nymous$ cat printf_format.c
#include <stdio.h>

void f(void)
{
        float a = 3.1415;
        int b   = 10;
        printf(«%5.2f %03d \n», a, b);
}

anon@nymous$ cat boost_format.cpp
#include <boost/format.hpp>
#include <iostream>

void f()
{
        float a = 3.1415;
        int b   = 10;
        std::cout << boost::format(«%5.2f %03d \n»)%a%b;
}

anon@nymous$ g++ -S boost_format.cpp 
anon@nymous$ gcc -S printf_format.c 
anon@nymous$ cat printf_format.s
	.file	«printf_format.c»
	.section	.rodata
.LC1:
	.string	«%5.2f %03d \n»
	.text
	.globl	f
	.type	f, @function
f:
.LFB0:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset 6, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register 6
	subq	$16, %rsp
	movl	.LC0(%rip), %eax
	movl	%eax, -4(%rbp)
	movl	$10, -8(%rbp)
	movss	-4(%rbp), %xmm0
	cvtps2pd	%xmm0, %xmm0
	movl	-8(%rbp), %eax
	movl	%eax, %esi
	movl	$.LC1, %edi
	movl	$1, %eax
	call	printf
	leave
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc
.LFE0:
	.size	f, .-f
	.section	.rodata
	.align 4
.LC0:
	.long	1078529622
	.ident	«GCC: (Debian 4.7.1-7) 4.7.1»
	.section	.note.GNU-stack,"",@progbits
anon@nymous$ wc printf_format.s
 38  86 641 printf_format.s
anon@nymous$ wc boost_format.s
 22782  52959 721994 boost_format.s
anon@nymous$ cat -n boost_format.s
 ...
 /* 22293 lines skipped */
 ...
 22294	_ZN5boost2io18basic_altstringbufIcSt11char_traitsIcESaIcEE8overflowEi:
 22295	.LFB2940:
 22296		.cfi_startproc
 22297		pushq	%rbp
 22298		.cfi_def_cfa_offset 16
 22299		.cfi_offset 6, -16
 22300		movq	%rsp, %rbp
 22301		.cfi_def_cfa_register 6
 22302		pushq	%rbx
 22303		subq	$88, %rsp
 22304		.cfi_offset 3, -24
 22305		movq	%rdi, -88(%rbp)
 22306		movl	%esi, -92(%rbp)
 22307		call	_ZNSt11char_traitsIcE3eofEv
 22308		movl	%eax, -68(%rbp)
 22309		leaq	-92(%rbp), %rdx
 22310		leaq	-68(%rbp), %rax
 22311		movq	%rdx, %rsi
 22312		movq	%rax, %rdi
 22313		call	_ZNSt11char_traitsIcE11eq_int_typeERKiS2_
 22314		testb	%al, %al
 22315		je	.L1392
 22316		leaq	-92(%rbp), %rax
 22317		movq	%rax, %rdi
 22318		call	_ZNSt11char_traitsIcE7not_eofERKi
 22319		jmp	.L1393
 22320	.L1392:
 22321		movq	-88(%rbp), %rax
 22322		movq	%rax, %rdi
 22323		call	_ZNKSt15basic_streambufIcSt11char_traitsIcEE4pptrEv
 22324		testq	%rax, %rax
 22325		je	.L1394
 22326		movq	-88(%rbp), %rax
 22327		movq	%rax, %rdi
 22328		call	_ZNKSt15basic_streambufIcSt11char_traitsIcEE4pptrEv
 22329		movq	%rax, %rbx
 22330		movq	-88(%rbp), %rax
 22331		movq	%rax, %rdi
 22332		call	_ZNKSt15basic_streambufIcSt11char_traitsIcEE5epptrEv
 22333		cmpq	%rax, %rbx
 22334		jae	.L1394
 22335		movl	$1, %eax
 22336		jmp	.L1395
 22337	.L1394:
 22338		movl	$0, %eax
 22339	.L1395:
 22340		testb	%al, %al
 22341		je	.L1396
 22342		leaq	-92(%rbp), %rax
 22343		movq	%rax, %rdi
 22344		call	_ZNSt11char_traitsIcE12to_char_typeERKi
 22345		movsbl	%al, %edx
 22346		movq	-88(%rbp), %rax
 22347		movl	%edx, %esi
 22348		movq	%rax, %rdi
 22349		call	_ZNSt15basic_streambufIcSt11char_traitsIcEE5sputcEc
 22350		movl	-92(%rbp), %eax
 ...
 /* 250 more lines skipped */
 ...
 22601		addq	$88, %rsp
 22602		popq	%rbx
 22603		popq	%rbp
 22604		.cfi_def_cfa 7, 8
 22605		ret
 22606		.cfi_endproc
 22607	.LFE2940:
 22608		.size	_ZN5boost2io18basic_altstringbufIcSt11char_traitsIcESaIcEE8overflowEi, .-_ZN5boost2io18basic_altstringbufIcSt11char_traitsIcESaIcEE8overflowEi
 22609		.section	.text._ZN9__gnu_cxx13new_allocatorIcE8allocateEmPKv,«axG»,@progbits,_ZN9__gnu_cxx13new_allocatorIcE8allocateEmPKv,comdat
 22610		.align 2
 22611		.weak	_ZN9__gnu_cxx13new_allocatorIcE8allocateEmPKv
 22612		.type	_ZN9__gnu_cxx13new_allocatorIcE8allocateEmPKv, @function
 22613	_ZN9__gnu_cxx13new_allocatorIcE8allocateEmPKv:
 22614	.LFB2943:
 22615		.cfi_startproc
 22616		pushq	%rbp
 22617		.cfi_def_cfa_offset 16
 22618		.cfi_offset 6, -16
 22619		movq	%rsp, %rbp
 22620		.cfi_def_cfa_register 6
 22621		subq	$32, %rsp
 22622		movq	%rdi, -8(%rbp)
 22623		movq	%rsi, -16(%rbp)
 22624		movq	%rdx, -24(%rbp)
 22625		movq	-8(%rbp), %rax
 22626		movq	%rax, %rdi
 22627		call	_ZNK9__gnu_cxx13new_allocatorIcE8max_sizeEv
 22628		cmpq	-16(%rbp), %rax
 22629		setb	%al
 22630		testb	%al, %al
 22631		je	.L1415
 22632		call	_ZSt17__throw_bad_allocv
 22633	.L1415:
 22634		movq	-16(%rbp), %rax
 22635		movq	%rax, %rdi
 22636		call	_Znwm
 22637		leave
 22638		.cfi_def_cfa 7, 8
 22639		ret
 22640		.cfi_endproc
 22641	.LFE2943:
 22642		.size	_ZN9__gnu_cxx13new_allocatorIcE8allocateEmPKv, .-_ZN9__gnu_cxx13new_allocatorIcE8allocateEmPKv
 22643		.section	.text._ZNK9__gnu_cxx13new_allocatorIcE8max_sizeEv,«axG»,@progbits,_ZNK9__gnu_cxx13new_allocatorIcE8max_sizeEv,comdat
 22644		.align 2
 22645		.weak	_ZNK9__gnu_cxx13new_allocatorIcE8max_sizeEv
 22646		.type	_ZNK9__gnu_cxx13new_allocatorIcE8max_sizeEv, @function
 22647	_ZNK9__gnu_cxx13new_allocatorIcE8max_sizeEv:
 22648	.LFB2945:
 22649		.cfi_startproc
 22650		pushq	%rbp
 22651		.cfi_def_cfa_offset 16
 22652		.cfi_offset 6, -16
 22653		movq	%rsp, %rbp
 22654		.cfi_def_cfa_register 6
 22655		movq	%rdi, -8(%rbp)
 22656		movq	$-1, %rax
 22657		popq	%rbp
 22658		.cfi_def_cfa 7, 8
 22659		ret
 22660		.cfi_endproc
 ...
 /* 120 lines to go */
 ...

Может я не до конца понял, но

КУДА - это _другой_ объект, его не должно волновать ЧТО.

float - ни разу не обьект в С++, это примитив. И где написано, что ostream волнует то, ему передали пару управляющих функций и затем примитив?

Если бы понадобилось вывести какую-нибудь диаграмму в ASCII, то было бы как-то так:

class Diagram : public Printable {
public:
    std::string toString() const;

    friend std::ostream& operator <<(std::ostream &out, const Diagram &diagram) {
        out << diagram.toString();
    }

   // ...
};

Diagram d;
cout << d;

pastebin.com

Так в чем сложности? В примере всё очень просто. Или опять ниасиливаешь? Всё с тобой ясно!

опять... осилил. просто. проще чем форматный вывод встроенными средствами iostream. Прям как printf(2). Осталось дождаться момента, когда printf(2) мне религия не позволит (:

Тут вопрос не в том понадобится или не понадобится, а в том, что он обладает достоинствами printf'а и лишен его недостатков.

ну я уже говорил - для меня warning == error. Первый говорит о том, что программа соберётся, и работать не будет. Ещё о том, что этот код сохранится в DVCS. Я вполне понятно изъясняюсь?

надеяться на компилятор — признак быдлокода

что значит «надеяться»? Если компилятор пишет «быдлокод», то ты надеешься, что авось заработает? Тогда - да. Ты - быдлокодер. Но я - не надеюсь.

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

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

очевидно не применять int64_t и printf(2) одновременно. В принципе, можно попробовать сравнить sizeof(int64_t) и sizeof(long long), если первый небольше второго, то преобразовать в long long, иначе прервать компиляцию (а иначе бывает?)

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

ну такое ТЗ. будет другое, буду думать...

OMG!!! НАХРЕН ваш boost!

Первый говорит о том, что программа соберётся, и работать не будет

не говорит

Ещё о том, что этот код сохранится в DVCS.

а это тут при чем?

Но я - не надеюсь.

ты полагаешься на то, что тебе компилятор напишет warning, отсюда вывод — ты - быдлокодер/

sizeof(int64_t) и sizeof(long long), если первый небольше второго

Какая разника какой у них sizeof? У них может быть одинаковый sizeof и при этом они будут разными типами, сюрприз?

иначе прервать компиляцию

шаманствами на #ifdef'ах? фтопку!

float - ни разу не обьект в С++, это примитив.

нет. Это - объект. Хоть и тривиальный, и потому много где неприменимый.

И где написано, что ostream волнует то, ему передали пару управляющих функций и затем примитив?

нигде не написано. Это просто костыль, связанный с тем, что мы не можем добавить в float свои методы. Вот и приходится либо впихивать кривой костыль между iostream и float, или оборачивать float в обёртку (расковыряв boost::format это видно).

Если бы понадобилось вывести какую-нибудь диаграмму в ASCII, то было бы как-то так:

ага. Вот это уже ООП.

Первый говорит о том, что программа соберётся, и работать не будет

не говорит

ну тем кодер от быдлокодера и отличается (:

сохранится в DVCS.

а это тут при чем?

при том, что мне будет стыдно (:

ты полагаешься на то, что тебе компилятор напишет warning, отсюда вывод — ты - быдлокодер/

я на это НЕ ПОЛАГАЮСЬ. warning == это ошибка, которую я случайно допустил, и которую заметил компилятор. Ну например if(x=foo(y)) это тоже ошибка, даже если я именно этого хотел - сейчас всё будет нормально, но через год я посмотрю на этот код, и ПОДУМАЮ, что тут написано if(x==foo(y)). Есть такое свойство человеческого разума, он САМ ошибки исправляет. Например зрительно «карова» читается «корова», и такие редкие опечатки даже не замечаются, если ты конечно не по слогам читаешь. Вот только в if(x=foo(y)) это НЕ ошибка, а наоборот - так и задумано.

Какая разника какой у них sizeof? У них может быть одинаковый sizeof и при этом они будут разными типами, сюрприз?

нет, может и разные. И даже наверняка - в 64х битных архитектурах int по идее должен быть 64х битный (естественный), а long & long long побольше. Что в этом странного? Вот только для printf(3) какая нафиг разница, что выводить? Лишь-бы не обрезало...

шаманствами на #ifdef'ах? фтопку!

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

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