Why does address-of-char give me non-terminated c-string gibberish?

[sherifffruitfly]

Hi all,

This isn't minimal code, but at least it gives the idea reasonably well
- and yes, I'm a newb

The point of me giving this code is that all three vars look to my eye
as though they're being treated in exactly the same way, so that I end
up confused about why the address-of-char doesn't get returned the way
the other address-of-types do.

(Sorry for bad formatting - I copy/pasted straight out of my IDE...)

Lil insight?

Thanks!

==============
#include <iostream>

using namespace std;

void main()
{
int a = 1;
char b = 'q';
double c = 1.3456;

cout << "Type Size Value Address" << endl;

cout << "int" << " " << sizeof(a) << " " << a << "
" << &a << endl;
cout << "char" << " " << sizeof(b) << " " << b << "
" << &b << endl;

//Why does the above line give gibberish for the address-of-char?

//It's as though it's related to the issue of a c-style string being
an array of char + a null
//on the end, and if you forget to put the null when making a string
"manually", and
//try to print it out, you end up with every memory location being
printed until it
//happens to run across a null. But I really have no idea what the
deal here is.

//Note that I get the expected result if I use the following to begin
with, and put in the obvious
//changes later on:
//char* b = new char('q'); (etc...)

cout << "double" << " " << sizeof(c) << " " << c << " "
<< &c << endl;

return;
}

 

[Neil Cerutti]

Hi all,

This isn't minimal code, but at least it gives the idea
reasonably well - and yes, I'm a newb

The point of me giving this code is that all three vars look to
my eye as though they're being treated in exactly the same way,
so that I end up confused about why the address-of-char doesn't
get returned the way the other address-of-types do.

(Sorry for bad formatting - I copy/pasted straight out of my
IDE...)

Check if your IDE has an option to convert tabs to spaces. That
will correct any problems when posting the code.

If not, consider writing your own converter, as an exercise.

#include <iostream>

using namespace std;

void main()

main returns an int.

{
int a = 1;
char b = 'q';
double c = 1.3456;

cout << "Type Size Value Address" << endl;

cout << "int" << " " << sizeof(a) << " " << a << "
" << &a << endl;
cout << "char" << " " << sizeof(b) << " " << b << "
" << &b << endl;

//Why does the above line give gibberish for the address-of-char?
//It's as though it's related to the issue of a c-style string being
an array of char + a null

That's right. The standard ostream thinks a pointer to char is a
C-string. Cast your pointers to void* to output them.

cout << "int" << " " << sizeof(a) << " "
<< a << " " << static_cast<void*>(&a) << endl;
cout << "char" << " " << sizeof(b) << " "
<< b << " " << static_cast<void*>(&b) << endl;

As an aside, you should look into the io manipulators. They may make
building your little table simpler.

return;

return 0;

 

[John Carson]

Check if your IDE has an option to convert tabs to spaces. That
will correct any problems when posting the code.

You'd think so wouldn't you. As it happens, it is not true if pasting
directly from the VC++ IDE into Outlook Express. Observe below how "spaces
only" code comes out (the two lines inside main are both indented in the
VC++ IDE with 4 spaces):

int main()
{
int x = 1;
return 0;
}

If you follow a more indirect route: VC++ to Notepad to Outlook Express,
then it comes out OK:

int main()
{
int x = 1;
return 0;
}

 

[Neil Cerutti]

You'd think so wouldn't you. As it happens, it is not true if pasting
directly from the VC++ IDE into Outlook Express. Observe below how "spaces
only" code comes out (the two lines inside main are both indented in the
VC++ IDE with 4 spaces):

int main()
{
int x = 1;
return 0;
}

Yikes!

 

[sherifffruitfly]

re: tab/space/xfer-code-from-IDE - all good - I'm familiar with the
origin-notepad-desitination cycle - will do next time

re: \t (I assume that's one of the things you're referring to by "io
manipulators") - a fine idea!

re: main() returning something - what's wrong with void? (Not to argue,
just curious)

re: My original issue: awesome, thanks! (awesome because that means
that I wasn't *just* being stupid


Thanks again!

cdj

 

[Ian]

re: main() returning something - what's wrong with void? (Not to argue,
just curious)

It's non-standard.

If you application is being run from a script or environment that wants
to know if the application succeeded or failed....

Ian

 

[Marcus Kwok]

re: \t (I assume that's one of the things you're referring to by "io
manipulators") - a fine idea!

<snip>

No, "I/O manipulators" are things such as those declared in <iomanip>,
like std::setw() to set the minimum width of an output field,
std::setprecision() to control how many digits will get printed, etc.

 

[sherifffruitfly]

Ah. Well then a fine idea that I'm too newbish to take advantage of at
the moment. I.e., I have no idea what you're talking about - lol

Lemme look in Prata's C++ Primer real quick.... Ok, that stuff doesn't
seem to be addressed until the last chapter of the book.... I'll take a
look at the material, and will happily make use of that which I'm able
to make sense of at this stage.

Thanks!

cdj

 

[Old Wolf]

It's non-standard.

If you application is being run from a script or environment that
wants to know if the application succeeded or failed....

..... or compiled with a standard-conforming compiler ...

 

[Mike Wahler]

<snip>

No, "I/O manipulators" are things such as those declared in <iomanip>,
like std::setw() to set the minimum width of an output field,
std::setprecision() to control how many digits will get printed, etc.

For completeness:

iostream manipulators are declared in two headers:
<ios> and <iomanip>. The easy way to remember which
ones are where is the fact that the ones which take
arguments are in <iomanip>, the others are in <ios>.
E.g. 'setw()' is in <iomanip>, 'std::left' is in <ios>.

-Mike

 

[sherifffruitfly]

Wow - lol - I'm so glad I asked my question - had a bit of trepidation
after seeing the jillionth "Off-topic go ask somewhere else"
response.... lol - Thanks all!