int main(void) is better than int main()

[x_knifer_x]

read the subject it says it all

int main(void) is better than int main()

[Juha Nieminen]

x_********@hotmail.com wrote:

read the subject it says it all

int main(void) is better than int main()

Why?

[Rolf Magnus]

x_********@hotmail.com wrote:

read the subject it says it all

int main(void) is better than int main()

There is no difference.

[Lars Uffmann]

x_********@hotmail.com wrote:

read the subject it says it all

your point being...?

[Jim Langston]

Lars Uffmann wrote:

x_********@hotmail.com wrote:

>read the subject it says it all

your point being...?

His point being he is a troll.

--
Jim Langston
ta*******@rocketmail.com

[Salt_Peter]

On Jan 2, 9:34 am, [e-mail] wrote:

read the subject it says it all

int main(void) is better than int main()

That assumes you have noticed a difference then.

[Bill - Cincinnati, OH USA]

You are not a troll. The quest for knowledge is not troll-ish.
On Jan 2, 9:34*am, [e-mail] wrote:

read the subject it says it all

int main(void) * * * *is better than * * * int main()

[Jim Langston]

Bill - Cincinnati, OH USA wrote:

On Jan 2, 9:34 am, [e-mail] wrote:

>read the subject it says it all

int main(void) is better than int main()

You are not a troll. The quest for knowledge is not troll-ish.

He did not ask a question, he made a statment. One that is contradictory to
common knowledge.

If he had asked which is better, then that is different. He is a troll.
--
Jim Langston
ta*******@rocketmail.com

[Jack Klein]

On Wed, 2 Jan 2008 06:34:45 -0800 (PST), x_********@hotmail.com wrote
in comp.lang.c++:

read the subject it says it all

int main(void) is better than int main()

Read the body, says it all:

*plonk*

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[James Kanze]

On Jan 2, 3:46 pm, Rolf Magnus <[e-mail]:

[e-mail] wrote:

read the subject it says it all

int main(void) is better than int main()

There is no difference.

As far as the compiler is concerned, no. As far as anyone who
reads the code is concerned, the first marks you as a C hacker,
who doesn't understand C++.

(FWIW: even the C experts find the first an abomination. To be
lived with in C, because there's no other alternative.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Lars Uffmann]

Now we're getting to where it becomes interesting :)

James Kanze wrote:

>>int main(void) is better than int main()

There is no difference.

As far as the compiler is concerned, no. As far as anyone who
reads the code is concerned, the first marks you as a C hacker,
who doesn't understand C++.

Maybe I don't understand C++ then - after all I did start with Ansi C -
I always thought "int main (void)" was the way to go because - as you
stated later in your post - compilers would complain otherwise. As for
C++, if there is no difference on compiler side, I don't see what the
problem is keeping void in there, even if it is not required. Please
enlighten me...

Best Regards,

Lars

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-01-03 13:10, Lars Uffmann wrote:

Now we're getting to where it becomes interesting :)

James Kanze wrote:

>>>int main(void) is better than int main()
There is no difference.

As far as the compiler is concerned, no. As far as anyone who
reads the code is concerned, the first marks you as a C hacker,
who doesn't understand C++.

Maybe I don't understand C++ then - after all I did start with Ansi C -
I always thought "int main (void)" was the way to go because - as you
stated later in your post - compilers would complain otherwise. As for
C++, if there is no difference on compiler side, I don't see what the
problem is keeping void in there, even if it is not required. Please
enlighten me...

It slows down reading (and writing), foo() clearly indicates that there
are no arguments, foo(void) at a glance looks like it takes an argument
and you have to see that the type is void before you understand that
there are no arguments. Why should we have to tell the compiler that
there are no arguments when an empty list works just as well, and is
more consistent.

--
Erik Wikström

[jkherciueh]

Erik Wikström wrote:

On 2008-01-03 13:10, Lars Uffmann wrote:

>Now we're getting to where it becomes interesting :)

James Kanze wrote:

>>>>int main(void) is better than int main()
There is no difference.
As far as the compiler is concerned, no. As far as anyone who
reads the code is concerned, the first marks you as a C hacker,
who doesn't understand C++.

Maybe I don't understand C++ then - after all I did start with Ansi C -

Obviously, I don't understand C++, too. I, however, came from Pascal and
Modula 2. I have never programmed in C.

>I always thought "int main (void)" was the way to go because - as you
stated later in your post - compilers would complain otherwise. As for
C++, if there is no difference on compiler side, I don't see what the
problem is keeping void in there, even if it is not required. Please
enlighten me...

It slows down reading (and writing),

I cannot not confirm that. But then again, I am used to much more verbose
languages.

foo() clearly indicates that there
are no arguments, foo(void) at a glance looks like it takes an argument
and you have to see that the type is void before you understand that
there are no arguments.

I don't think the psychology of reading code (as opposed to the logic of
parsing) works that way.

Why should we have to tell the compiler that
there are no arguments when an empty list works just as well, and is
more consistent.

On the other hand, I find it very nice that

foo( void )

does not look like the function call and clearly indicates that I am looking
at a declaration. For that reason, it also increases grep-ability of the
code.
Best

Kai-Uwe Bux

[Lars Uffmann]

Erik Wikström wrote:

>foo() clearly indicates that there
are no arguments, foo(void) at a glance looks like it takes an argument
and you have to see that the type is void before you understand that
there are no arguments.

@Erik: point taken, at this point I was ready to accept this and apply
it to my own code, but then...

jk********@gmx.net wrote:

On the other hand, I find it very nice that
foo( void )
does not look like the function call and clearly indicates that I am looking
at a declaration. For that reason, it also increases grep-ability of the
code.

Kai-Uwe also has a very good point there. Especially on the grep-ability :)

I'm thinking especially about forward declarations that will look
exactly like a function call. Have to chew on this for a bit - unless
someone comes up with better arguments ;) Thanks to both of you!

Best Regards,

Lars

[James Kanze]

Lars Uffmann wrote:

Now we're getting to where it becomes interesting :)

James Kanze wrote:

>int main(void) is better than int main()
There is no difference.

As far as the compiler is concerned, no. As far as anyone who
reads the code is concerned, the first marks you as a C hacker,
who doesn't understand C++.

Maybe I don't understand C++ then - after all I did start with
Ansi C - I always thought "int main (void)" was the way to go
because - as you stated later in your post - compilers would
complain otherwise.

When I first started C++, "int main( void )" wouldn't work in
either C or C++. In C, you could define main as either:
int main() { }
or
int main( argc, argv )
int argc ;
char** argv ;
{ }
if you had arguments. The C I learned (around 1982) didn't have
prototypes. (You could also leave out the initial int, and a
lot of programmers did.)

And when I first learned C++, some of the C++ compilers I used
wouldn't accept int main( void ) { } (which wasn't legal in the
original C++).

As for C++, if there is no difference on compiler side, I
don't see what the problem is keeping void in there, even if
it is not required. Please enlighten me...

Because it doesn't belong there. It wasn't there to begin with.
It got added by C when C adopted prototypes, because int main()
already had a defined meaning (which was different). C++ then
adopted it, but only for reasons of C compatibility.

It's ugly, and it's a lie.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Ian Collins]

Lars Uffmann wrote:

Now we're getting to where it becomes interesting :)

James Kanze wrote:

>>>int main(void) is better than int main()
There is no difference.

As far as the compiler is concerned, no. As far as anyone who
reads the code is concerned, the first marks you as a C hacker,
who doesn't understand C++.

Maybe I don't understand C++ then - after all I did start with Ansi C -
I always thought "int main (void)" was the way to go because - as you
stated later in your post - compilers would complain otherwise. As for
C++, if there is no difference on compiler side, I don't see what the
problem is keeping void in there, even if it is not required. Please
enlighten me...

It doesn't belong in C++, but it does in C where K&R style function
declarations are still legal. In C, f() and f(void) have different
meanings, where they do not in C++.

--
Ian Collins.

[Lars Uffmann]

Ian Collins wrote:

It doesn't belong in C++, but it does in C where K&R style function
declarations are still legal. In C, f() and f(void) have different
meanings, where they do not in C++.

After reading James' comments - especially on the grepability - that
function declarations should (and in my case do) start in the first
column, I've decided to use "int main() {}" in the future.
But could you explain the different meanings of f() and f(void) in C to
me? Or rather - point me to a source where it is explained?

Thanks in advance!

Lars

[Ian Collins]

Lars Uffmann wrote:

Ian Collins wrote:

>It doesn't belong in C++, but it does in C where K&R style function
declarations are still legal. In C, f() and f(void) have different
meanings, where they do not in C++.

After reading James' comments - especially on the grepability - that
function declarations should (and in my case do) start in the first
column, I've decided to use "int main() {}" in the future.
But could you explain the different meanings of f() and f(void) in C to
me? Or rather - point me to a source where it is explained?

The C standard :)

C compilers accept old K&R style function declarations:

void f(); /* Declares a function with unknown parameters */
void f(void); /* Declares a function with no parameters */

--
Ian Collins.

[Lars Uffmann]

Ian Collins wrote:

void f(); /* Declares a function with unknown parameters */

o_O unknown parameters! :) I've always meant to use that at some point -
will have to have a look into the equivalent in C++. Thanks a ton!

Best Regards,

Larsa

[James Kanze]

On Jan 4, 10:48 am, Lars Uffmann <[e-mail]:

Ian Collins wrote:

void f(); /* Declares a function with unknown parameters */

o_O unknown parameters! :) I've always meant to use that at some point -
will have to have a look into the equivalent in C++.

There isn't an equivalent, and this feature has been declared
"obsolete" in C99 as well. When I started in C, it was the only
possibility to declare a function. There was no way of telling
the compiler how many parameters there were, or what their types
were. You just had to be very careful to pass the right number
and types when you called the function. (E.g. if the function
took a double, and you called it with f(0), the compiler
wouldn't complain, but it would just pass an int, and not a
double.)

Believe me, this is one feature of K&R C I definitely don't miss.

--
James Kanze (GABI Software) mailto:ja*********@gmail.com
Conseils en informatique orient�e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, [phone]

[Lars Uffmann]

James Kanze wrote:

>o_O unknown parameters! :) I've always meant to use that at some point -
will have to have a look into the equivalent in C++.

There isn't an equivalent, and this feature has been declared
"obsolete" in C99 as well.

Oh - I was mainly thinking of functions that take any amount of
parameters like... printf, for example...

[Ian Collins]

Lars Uffmann wrote:

James Kanze wrote:

>>o_O unknown parameters! :) I've always meant to use that at some point -
will have to have a look into the equivalent in C++.

There isn't an equivalent, and this feature has been declared
"obsolete" in C99 as well.

Oh - I was mainly thinking of functions that take any amount of
parameters like... printf, for example...

Variadic functions. The same conditions James mentioned apply to these
as well!

--
Ian Collins.

[Rolf Magnus]

Lars Uffmann wrote:

James Kanze wrote:

>>o_O unknown parameters! :) I've always meant to use that at some point -
will have to have a look into the equivalent in C++.

There isn't an equivalent, and this feature has been declared
"obsolete" in C99 as well.

Oh - I was mainly thinking of functions that take any amount of
parameters like... printf, for example...

Those do exist in C++, and are implemented in just the same way, but should
be avoided.

[Lars Uffmann]

Rolf Magnus wrote:

Lars Uffmann wrote:
[.. variadic functions ..]
Those do exist in C++, and are implemented in just the same way, but should
be avoided.

Well - of course - _should be_ - but at some point it might be helpful
to know they are there :) printf is a nice example of when they come in
handy - unless cout can cover the full functionality of that :)

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-01-04 13:23, Lars Uffmann wrote:

Rolf Magnus wrote:

>Lars Uffmann wrote:
[.. variadic functions ..]
Those do exist in C++, and are implemented in just the same way, but should
be avoided.

Well - of course - _should be_ - but at some point it might be helpful
to know they are there :) printf is a nice example of when they come in
handy - unless cout can cover the full functionality of that :)

I am quite sure that there is no formatting that you can achieve with
printf() that you can not make with cout, but it is a lot harder with
cout. However in the next version of the standard we will see something
called variadic templates which should allow for a typesafe
implementation of printf().

--
Erik Wikström

[James Kanze]

On Jan 4, 1:23 pm, Lars Uffmann <[e-mail]:

Rolf Magnus wrote:

Lars Uffmann wrote:
[.. variadic functions ..]
Those do exist in C++, and are implemented in just the same
way, but should be avoided.

Well - of course - _should be_ - but at some point it might be helpful
to know they are there :) printf is a nice example of when they come in
handy - unless cout can cover the full functionality of that :)

ostream has considerably more functionality than printf. There
are a lot of things that you can do with ostream that you cannot
do with printf/fprintf/sprintf.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jan 4, 2:13 pm, Erik Wikström <[e-mail]:

On 2008-01-04 13:23, Lars Uffmann wrote:

Rolf Magnus wrote:

Lars Uffmann wrote:
[.. variadic functions ..]
Those do exist in C++, and are implemented in just the same
way, but should be avoided.

Well - of course - _should be_ - but at some point it might be helpful
to know they are there :) printf is a nice example of when they come in
handy - unless cout can cover the full functionality of that :)

I am quite sure that there is no formatting that you can
achieve with printf() that you can not make with cout, but it
is a lot harder with cout.

It's generally a lot easier with cout. About the only
printf formatting I know that you can't easily achieve with
ostream is the ' ' modifier, i.e.: "% d".

However in the next version of the standard we will see
something called variadic templates which should allow for a
typesafe implementation of printf().

You *can* simulate printf formatting with ostream today,
although why you would want to? Boost::format supports almost
all of the printf formatters (I think the ' ' flag is one of the
exceptions), and a bit more. I also used to have a class Format
which was 100% compatible with the X/Open printf, including the
X/Open extensions, and attempted, at least, to make it simple to
support user defined classes as well. (I stopped maintaining it
because in the end, I couldn't think of a context where printf
style formatting was preferable over ostream style formatting.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Tomás Ó hÉilidhe]

James Kanze <ja*********@gmail.comwrote in comp.lang.c++:

As far as the compiler is concerned, no. As far as anyone who
reads the code is concerned, the first marks you as a C hacker,
who doesn't understand C++.

Actually I coded for a few years in C++ and always used () instead of
(void). Now I've been programming in C for the last year or so I'm
(obviously) using (void) instead of ().

Now that I'm doing a bit of C++ again, I'm more comfortable with (void).
So contrary to your claim, I'm someone who writes (void) in C++, but who
also understands C++.

(FWIW: even the C experts find the first an abomination.

Of course not. What could be wrong with "int main(void)"?

To be lived with in C, because there's no other alternative.)

I like having (void) instead of () in C, because then when I see empty
parentheses I know straight away that it's the invocation of a function.

--
Tomás Ó hÉilidhe

[Tim H]

On Jan 4, 11:59 am, James Kanze <[e-mail]:

It's generally a lot easier with cout. About the only
printf formatting I know that you can't easily achieve with
ostream is the ' ' modifier, i.e.: "% d".

"can't achieve" or "can't easily achieve" ?

You *can* simulate printf formatting with ostream today,
although why you would want to? Boost::format supports almost
all of the printf formatters (I think the ' ' flag is one of the

It also lacks the * formatter, which hurts me.

exceptions), and a bit more. I also used to have a class Format
which was 100% compatible with the X/Open printf, including the
X/Open extensions, and attempted, at least, to make it simple to
support user defined classes as well. (I stopped maintaining it
because in the end, I couldn't think of a context where printf
style formatting was preferable over ostream style formatting.)

common things I do:

printf("%3d: %#08x\n", x, y);

std::cout << boost::format("%3d: %#08x\n") %x %y;

How do you do this easily with plain old cout?

Tim

p.s.

If format supported * I'd have said:

printf("%3d: %#0*x\n", x, y_width/4, y);

[James Kanze]

On Jan 6, 1:02 am, Tim H <[e-mail]:

On Jan 4, 11:59 am, James Kanze <[e-mail]:

It's generally a lot easier with cout. About the only
printf formatting I know that you can't easily achieve with
ostream is the ' ' modifier, i.e.: "% d".

"can't achieve" or "can't easily achieve" ?

Can't achieve directly. You can achieve anything if you format
into an std::ostringstream, and then do padding, etc. manually.

You *can* simulate printf formatting with ostream today,
although why you would want to? Boost::format supports almost
all of the printf formatters (I think the ' ' flag is one of the

It also lacks the * formatter, which hurts me.

What do you mean by "the * formatter"? The only place you can
use a '*' in a format specification of printf is for width and
precision. From what I understand of boost::format (but
admittedly, I've never used it), it allows all of the normal
manipulators as well, so you can use setw() and setprecision()
to achieve the same effect as the '*'. (setprecision() will
affect all of the following variables, where as ".*" won't, so
they effect isn't exactly the same.)

Another thing which I think is lacking, however, is precision of
an int or a string, e.g. printf( "%-10.8s|%5.3d",
"abcdefghijklmnopqrstuvwxyz", 2 ) will output:
"abcdefgh | 002"
From what I've seen, however, most people don't actually know
the embedded language used by printf very well, and aren't aware
of such features to begin with.

exceptions), and a bit more. I also used to have a class Format
which was 100% compatible with the X/Open printf, including the
X/Open extensions, and attempted, at least, to make it simple to
support user defined classes as well. (I stopped maintaining it
because in the end, I couldn't think of a context where printf
style formatting was preferable over ostream style formatting.)

common things I do:

printf("%3d: %#08x\n", x, y);

std::cout << boost::format("%3d: %#08x\n") %x %y;

How do you do this easily with plain old cout?

std::cout << std::setw( 3 ) << x
<< Gabi::HexFmt( 8, ios::showbase ) << y << '\n' ;

Except that I'd usually write:

std::cout << std::setw( 3 ) << x
<< "0x" << Gabi::HexFmt( 8, ios::uppercase ) << y <<
'\n' ;

since I prefer the format "0x0000ABCD" for hex.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[LR]

James Kanze wrote:

On Jan 6, 1:02 am, Tim H <[e-mail]:

>On Jan 4, 11:59 am, James Kanze <[e-mail]:

>>It's generally a lot easier with cout. About the only
printf formatting I know that you can't easily achieve with
ostream is the ' ' modifier, i.e.: "% d".

>"can't achieve" or "can't easily achieve" ?

Can't achieve directly. You can achieve anything if you format
into an std::ostringstream, and then do padding, etc. manually.

Isn't this, or can't this be, assuming int x;

std::cout << (x >= 0 ? std::string(' ') : std::string());
std::cout << x;

Or have I missed something?

>

>>You *can* simulate printf formatting with ostream today,
although why you would want to? Boost::format supports almost
all of the printf formatters (I think the ' ' flag is one of the

>It also lacks the * formatter, which hurts me.

What do you mean by "the * formatter"? The only place you can
use a '*' in a format specification of printf is for width and
precision. From what I understand of boost::format (but
admittedly, I've never used it), it allows all of the normal
manipulators as well, so you can use setw() and setprecision()
to achieve the same effect as the '*'. (setprecision() will
affect all of the following variables, where as ".*" won't, so
they effect isn't exactly the same.)

And even if it is lacking, there's always code like this, no matter how
annoying and bad it might be,

std::string df(const unsigned int width) {
std::ostringstream ox;
ox << "%" << width << "d\n";
return ox.str();
}
....
printf(df(5).c_str(),x);
....

>
Another thing which I think is lacking, however, is precision of
an int or a string, e.g. printf( "%-10.8s|%5.3d",
"abcdefghijklmnopqrstuvwxyz", 2 ) will output:
"abcdefgh | 002"
From what I've seen, however, most people don't actually know
the embedded language used by printf very well, and aren't aware
of such features to begin with.

>common things I do:

printf("%3d: %#08x\n", x, y);

> std::cout << boost::format("%3d: %#08x\n") %x %y;

>How do you do this easily with plain old cout?

std::cout << std::setw( 3 ) << x
<< Gabi::HexFmt( 8, ios::showbase ) << y << '\n' ;

Except that I'd usually write:

std::cout << std::setw( 3 ) << x
<< "0x" << Gabi::HexFmt( 8, ios::uppercase ) << y <<
'\n' ;

I'm not familiar with 'Gabi'. Is that part of the standard?

Adding to the snippet above,
const int x = 123;
const int y = 0xabcd;

my compiler produces,
123: 0x00abcd
for the OP's printf statement. I can't tell from reading the only draft
copy of a C standard I have, but I'm going to guess that the '%#08x'
format width calculations include the '0x'. Assuming that in the OPs
snippet x and y were meant to be int and sizeof(int) is 4 and the number
of bits per char is 8, I wonder if the OP meant '%#010x'?

So using plain old cout, what's wrong with,

std::cout
<< std::dec
<< std::setw(3)
<< x
<< ": "
<< (y == 0 ? std::string() : std::string("0x")) << std::setfill('0')
<< std::setw(6) // or std::setw(8) if you wanted 8 hex digits
<< std::hex
<< y
<< std::endl;

>
since I prefer the format "0x0000ABCD" for hex.

I suppose it would be superfluous to mention std::uppercase.

I'm not sure I understood the OP's question or your response. What am I
missing, please?

LR

[LR]

LR wrote:

James Kanze wrote:

>On Jan 6, 1:02 am, Tim H <[e-mail]:

>>On Jan 4, 11:59 am, James Kanze <[e-mail]:

>>>It's generally a lot easier with cout. About the only
printf formatting I know that you can't easily achieve with
ostream is the ' ' modifier, i.e.: "% d".

>>"can't achieve" or "can't easily achieve" ?

Can't achieve directly. You can achieve anything if you format
into an std::ostringstream, and then do padding, etc. manually.

Isn't this, or can't this be, assuming int x;

std::cout << (x >= 0 ? std::string(' ') : std::string());
std::cout << x;

Or have I missed something?

>>

>>>You *can* simulate printf formatting with ostream today,
although why you would want to? Boost::format supports almost
all of the printf formatters (I think the ' ' flag is one of the

>>It also lacks the * formatter, which hurts me.

What do you mean by "the * formatter"? The only place you can
use a '*' in a format specification of printf is for width and
precision. From what I understand of boost::format (but
admittedly, I've never used it), it allows all of the normal
manipulators as well, so you can use setw() and setprecision()
to achieve the same effect as the '*'. (setprecision() will
affect all of the following variables, where as ".*" won't, so
they effect isn't exactly the same.)

And even if it is lacking, there's always code like this, no matter how
annoying and bad it might be,

std::string df(const unsigned int width) {
std::ostringstream ox;
ox << "%" << width << "d\n";
return ox.str();
}
...
printf(df(5).c_str(),x);
...

>>
Another thing which I think is lacking, however, is precision of
an int or a string, e.g. printf( "%-10.8s|%5.3d",
"abcdefghijklmnopqrstuvwxyz", 2 ) will output:
"abcdefgh | 002"
From what I've seen, however, most people don't actually know
the embedded language used by printf very well, and aren't aware
of such features to begin with.

>>common things I do:

printf("%3d: %#08x\n", x, y);

>> std::cout << boost::format("%3d: %#08x\n") %x %y;

>>How do you do this easily with plain old cout?

std::cout << std::setw( 3 ) << x
<< Gabi::HexFmt( 8, ios::showbase ) << y << '\n' ;

Except that I'd usually write:

std::cout << std::setw( 3 ) << x
<< "0x" << Gabi::HexFmt( 8, ios::uppercase ) << y <<
'\n' ;

I'm not familiar with 'Gabi'. Is that part of the standard?

Adding to the snippet above,
const int x = 123;
const int y = 0xabcd;

my compiler produces,
123: 0x00abcd
for the OP's printf statement.

Sorry. I wrote OP, but I meant Tim H. And below as well.

I can't tell from reading the only draft
copy of a C standard I have, but I'm going to guess that the '%#08x'
format width calculations include the '0x'. Assuming that in the OPs
snippet x and y were meant to be int and sizeof(int) is 4 and the number
of bits per char is 8, I wonder if the OP meant '%#010x'?

So using plain old cout, what's wrong with,

std::cout
<< std::dec
<< std::setw(3)
<< x
<< ": "
<< (y == 0 ? std::string() : std::string("0x")) << std::setfill('0')
<< std::setw(6) // or std::setw(8) if you wanted 8 hex digits
<< std::hex
<< y
<< std::endl;

>>
since I prefer the format "0x0000ABCD" for hex.

I suppose it would be superfluous to mention std::uppercase.

I'm not sure I understood the OP's question or your response. What am I
missing, please?

LR

[Tim H]

On Jan 7, 7:40 am, James Kanze <[e-mail]:

>
Gabi is a namespace, and HexFmt is a manipulator, which works
more or less like std::setw(). HexFmt is also a poor example,
because it's really designed more to be an example of how to
write these sort of things. In an actual application, you's use
something similar, but which wouldn't require the ios::uppercase
argument---whether you output hex in upper or lower case would
be determined centrally, and not at each output site. (An
application specific manipulator could also output the "0x",
although it's not really very idiomatic for manipulators to
generate output.)

That's a fine answer. But not the end-all. I can think of many times
where the format is very context-specific. Where sometimes hex is 2
hexits, 4 hexits, 8 hexits, etc. But Your answer could work here too.

Where do you reset the stream's settings? Or do they get left in
"whatever was last" state?

printf uses a language in a language. The language is very,
very terse (it was invented by people who programmed on real
tty's), and thus, not particularly readable. It contains a lot
of little known features.

but it really doesn't take long to master 90% of the useful features
of
it. Don't make it sound harder than it is.

And the advantage of having stringstreams, fstreams and
standard input, output and error all use the same interface?

printf, fprintf and sprintf all use the same language in a
language as well. The real advantage is when you start writing
your own streambuf's.

Again, I'd never advocate printf() proper, when typesafe alternatives
are
available. And boost::format DOES work with user defined types.
Also,
you're mentioned specifically in the boost::format docs, which I did
not
realize until yesterday :)

I guess we'll just agree to do things differently. I am very
comfortable
with printf() style formatters, and can read them almost as quickly as
plain code. I know how to use them when I need them, and they express
the
vas majority of what I need to output. I find boost::format to be a
very
useful tool when I need to do formatted IO very simply.

When I have a custom type, I almost always add a operator<<(ostream),
and
when appropriate I make it check the flags on the stream for it's
formatting. Thus, it works with boost::format or ostream directly.

Lastly, I admit to being a C programmer still learning C++. Iostreams
do
feel weird to me (I really liked Java's to_string() model, iostreams
is
similar but inside out).

Cheers.

Tim

[James Kanze]

On Jan 7, 8:08 pm, Tim H <[e-mail]:

On Jan 7, 7:40 am, James Kanze <[e-mail]:

Gabi is a namespace, and HexFmt is a manipulator, which
works more or less like std::setw(). HexFmt is also a poor
example, because it's really designed more to be an example
of how to write these sort of things. In an actual
application, you's use something similar, but which wouldn't
require the ios::uppercase argument---whether you output hex
in upper or lower case would be determined centrally, and
not at each output site. (An application specific
manipulator could also output the "0x", although it's not
really very idiomatic for manipulators to generate output.)

That's a fine answer. But not the end-all. I can think of many times
where the format is very context-specific. Where sometimes hex is 2
hexits, 4 hexits, 8 hexits, etc. But Your answer could work here too.

Exactly. For something rather general, like HexFmt, I'd
probably leave the first parameter, which specifies the number
of digits. But I wouldn't necessarily leave the second, which
in HexFmt allows adding any flags you might want.

Where do you reset the stream's settings? Or do they get left
in "whatever was last" state?

I reset them in the destructor. Since the object is always a
temporary, it gets destructed at the end of the full expression.

printf uses a language in a language. The language is very,
very terse (it was invented by people who programmed on real
tty's), and thus, not particularly readable. It contains a
lot of little known features.

but it really doesn't take long to master 90% of the useful
features of it. Don't make it sound harder than it is.

Experience has shown me that most C programmers, even
experienced ones, only know about 10% of it.

It works well for debugging output, where you're not too
concerned with the format: almost everyone does retain that %d
outputs integers, %x does the same but in hex, and %f is for
fixed point. Most programmers quickly assimulate the x.y for
width and precision. Almost no one knows much about the
flags---note that one of the respondants here wondered why you
used octal in "%#08x" (Which, of course, isn't octal. The 0 is a
flag, and not part of the numeric value. Which can't be octal:
even in "%20.010f", the precision is 10, and not 8.)

And the advantage of having stringstreams, fstreams and
standard input, output and error all use the same interface?

printf, fprintf and sprintf all use the same language in a
language as well. The real advantage is when you start writing
your own streambuf's.

Again, I'd never advocate printf() proper, when typesafe
alternatives are available. And boost::format DOES work with
user defined types.

Yes. Under the hood, boost::format uses ostream. *All* it
does, in fact, is set formatting flags. (I had a discussion
with the author in one of the forums at one point. I believe
that one of his goals was that formatting specifiers would only
affect the flags. In my case, in Gabi::Format (or GB_Format, as
it was back then---this was long before namespaces, or even
templates), someone challenged me to attain 100% compatibility,
so I did. Which meant intercepting some of the types (integral,
floating point, etc.) and doing some extra formatting by hand; I
then extracted this logic so that it would be easy to provide it
for user defined numeric types.

Quite frankly, the author of boost::format made the right
decision here. Well over half of my code was there to handle
special cases involving flags which 99% of the programmers have
never heard of. (On the other hand, the use of the % operator
for streaming is a disaster with regards to program
readability.)

Also, you're mentioned specifically in the boost::format docs,
which I did not realize until yesterday :)

I guess we'll just agree to do things differently. I am very
comfortable with printf() style formatters, and can read them
almost as quickly as plain code.

I'm very comfortable with them as well, having actually
implemented printf in the past, but most of my collegues aren't.
And of course, it still means specifying physical formatting
directly at the site of the output, which is a maintenance
nightmare.

I know how to use them when I need them, and they express the
vas majority of what I need to output. I find boost::format
to be a very useful tool when I need to do formatted IO very
simply.

When I have a custom type, I almost always add a
operator<<(ostream), and when appropriate I make it check the
flags on the stream for it's formatting. Thus, it works with
boost::format or ostream directly.

Lastly, I admit to being a C programmer still learning C++.
Iostreams do feel weird to me (I really liked Java's
to_string() model, iostreams is similar but inside out).

If it wasn't implicit, I'd go with the Java model as well.
Although both it and ostream have the disadvantage of cutting up
the output text into small bits and pieces, which causes
troubles for the translator. I've not looked at it lately, but
boost::format does support a simpler form of the format
specifier (i.e. "id = %1%, value = %2%"), and allows
manipulators, so you may be able to get the best of both worlds.
Provided they change the '%', of course. (I sort of like
something like:
Format( "%1%: %2%" ).with( id ).with( value )
But you'd not want a separate "with()" for the manipulators;
something like:
Format( "%1%: %2%" ).with( id, 3 ).with( HexFmt( 8 ), value ) ;
would be more like it.

Maybe I should go back and see what I can do with my old code,
incorporating ideas from Boost. (My code did allow specifying
width and precision in three different ways: as a constant in
the format specifier, like printf; as an additional "argument",
by specifying a "*" in the format specifier, again like printf;
or as a second or third argument to with() (if you were using
with(), instead of <<---my code supported both). Or just grab
the Boost code, and add support for with()---it seems to do
everything I want, except allow a readable format in the
expression using it.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[LR]

James Kanze wrote:

It works well for debugging output, where you're not too
concerned with the format: almost everyone does retain that %d
outputs integers, %x does the same but in hex, and %f is for
fixed point. Most programmers quickly assimulate the x.y for
width and precision. Almost no one knows much about the
flags---note that one of the respondants here wondered why you
used octal in "%#08x" (Which, of course, isn't octal. The 0 is a
flag, and not part of the numeric value. Which can't be octal:
even in "%20.010f", the precision is 10, and not 8.)

I seem to have missed the post where someone wondered about the use of
octal in "%#08x". Could you please point out which post that is?

LR

[Tim H]

On Jan 8, 2:09 am, James Kanze <[e-mail]:

That's a fine answer. But not the end-all. I can think of many times
where the format is very context-specific. Where sometimes hex is 2
hexits, 4 hexits, 8 hexits, etc. But Your answer could work here too.

Exactly. For something rather general, like HexFmt, I'd
probably leave the first parameter, which specifies the number
of digits. But I wouldn't necessarily leave the second, which
in HexFmt allows adding any flags you might want.

Where do you reset the stream's settings? Or do they get left
in "whatever was last" state?

I reset them in the destructor. Since the object is always a
temporary, it gets destructed at the end of the full expression.

Can you point me at example code of your formatters? I'm not saying
you'll make a convert out of me, but I'll try it.

with(), instead of <<---my code supported both). Or just grab
the Boost code, and add support for with()---it seems to do
everything I want, except allow a readable format in the
expression using it.

Can you add %* support, while you're in there? :)

Tim

[Lars Uffmann]

Bill - Cincinnati, OH USA wrote:

[..bullcrap..]

Don't feed the trolls. Nothing to see here, move along please.

....

PS: Why do people believe this attention-whore to begin with? He is
probably lying, and even if not, no one should care, because the debate
wasn't directed at the stupid original poster, and this troll here
probably didn't even understand a fraction of it