468,457 Members | 1,603 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,457 developers. It's quick & easy.

int* ptr=10;.......issue.

hi ,

whats the issue with the following declaration, is it correct and what
exactly is happening here.

int main()
{
//.....
int* ptr=10; // i suppose ptr is pointing to the memory location which
stores the value 10.
//
.......
}
on gcc it gives no error...but when i compile it using g++ it gives
"invalid conversion of int * to int"

please advise on this.
regards.

Aug 28 '06 #1
25 4375
"al pacino" <si*************@gmail.comwrote:
whats the issue with the following declaration, is it correct and what
exactly is happening here.
[...]
int* ptr=10; // i suppose ptr is pointing to the memory location which
stores the value 10.
Nope, this would make the pointer point to the memory ADDRESS 10
(0xa).
on gcc it gives no error...but when i compile it using g++ it gives
"invalid conversion of int * to int"
You need to add a typecast:
int* ptr = (int *) 10;
or
int *ptr = new int[1];
*ptr = 10;
delete [] ptr;

Best Regards,

Lars
Aug 28 '06 #2

Lars Uffmann wrote:
"al pacino" <si*************@gmail.comwrote:
whats the issue with the following declaration, is it correct and what
exactly is happening here.
[...]
int* ptr=10; // i suppose ptr is pointing to the memory location which
stores the value 10.

Nope, this would make the pointer point to the memory ADDRESS 10
(0xa).
maybe i was confused as,
char *s="hello";
implies 's' pointing to the string HELLO.

but in the original case..what was happning was
int *ptr; and
ptr=10; //ptr now points to address 10;

why is it so in the case of int as in char.

thanks and regards.

on gcc it gives no error...but when i compile it using g++ it gives
"invalid conversion of int * to int"

You need to add a typecast:
int* ptr = (int *) 10;
or
int *ptr = new int[1];
*ptr = 10;
delete [] ptr;

Best Regards,

Lars
or

Aug 28 '06 #3

al pacino wrote:
hi ,

whats the issue with the following declaration, is it correct and what
exactly is happening here.

int main()
{
//.....
int* ptr=10; // i suppose ptr is pointing to the memory location which
stores the value 10.
no, thats wrong and a big no-no.
You don't understand pointers.
//
......
}
on gcc it gives no error...but when i compile it using g++ it gives
"invalid conversion of int * to int"

please advise on this.
regards.
That is expected. You are inducing undefined behaviour.
You are not trying to *set* what is *at* the pointer to the value of
10.
You are trying to set the memory address *in* ptr to 10.
A very big no-no (thankfully caught by most C++ compilers).

This too is illegal:

int *ptr; // ptr holds some residual value, its unitialized (bad,
no-no, danger)
*ptr = 10;

How do you know what is at that residual location?
Imagine what happens when the compiler lets you overwrite any memory
location.
Answer: UB (format the hard drive, crash the computer, etc)
You think thats a common joke - but its not a joke

Pointers are always set using the address_of (&) operator or new.

int n; // reserve integer n on the stack, although n is uninitialized
int *ptr = &n; // reserve pointer ptr on stack & its now valid: it
holds n's address
*ptr = 10; // same as n = 10

Again, ptr holds an address, *ptr is the variable at that address.
And the term in question is "dereferencing the pointer".
One way or another, its the program that sets the pointer.
Pointers are not a toy, when you see a pointer, except for
polymorphism, a buzzer should go off in your head. Pointers are nearly
always bad news.

pointers are hell
pointers create bugs
pointers generate headaches
a pointer is a disease
etc

Stay away from pointers, use a reference instead.
hmm, how the hell are we going to explain references to you?

Aug 28 '06 #4
pointers are hell
pointers create bugs
pointers generate headaches
a pointer is a disease
etc

Stay away from pointers, use a reference instead.
Do you come from Java? Don't make pointers that bad, because they do
have their right of existance.
hmm, how the hell are we going to explain references to you?
It's apointer - but not really a pointer.
Aug 28 '06 #5
Do you come from Java? Don't make pointers that bad, because they do
have their right of existance.
Yes, when wrapped in a tr1::shared_ptr<>, or some other suitable
exceptionsafe, leak-free method of handling them.

Aug 28 '06 #6
al pacino wrote:
>
Lars Uffmann wrote:
>"al pacino" <si*************@gmail.comwrote:
whats the issue with the following declaration, is it correct and what
exactly is happening here.
[...]
int* ptr=10; // i suppose ptr is pointing to the memory location which
stores the value 10.

Nope, this would make the pointer point to the memory ADDRESS 10
(0xa).
maybe i was confused as,
char *s="hello";
implies 's' pointing to the string HELLO.
Well, there is a difference here. That string literal is of array type. An
array gets in most cases converted to a pointer to its first element.
but in the original case..what was happning was
int *ptr; and
ptr=10; //ptr now points to address 10;

why is it so in the case of int as in char.
It's not char, it's char[6].

Aug 28 '06 #7
Gernot Frisch wrote:
>
>pointers are hell
pointers create bugs
pointers generate headaches
a pointer is a disease
etc

Stay away from pointers, use a reference instead.

Do you come from Java? Don't make pointers that bad, because they do
have their right of existance.
I'd say that Java references are closer to C++ pointers than to C++
references.

Aug 28 '06 #8

Gernot Frisch wrote:
Saltiers(?) wrote:
pointers are hell
pointers create bugs
pointers generate headaches
a pointer is a disease
etc

Stay away from pointers, use a reference instead.

Do you come from Java? Don't make pointers that bad, because they do
have their right of existance.
Is it not rather the other way around - that Java people abuse pointers
because that is the only thing they have? We "real" C++ people normally
do know that Saltiers advice (avoid pointers whenever possible) is
sound and correct.
>
hmm, how the hell are we going to explain references to you?

It's apointer - but not really a pointer.
2% truth 98% false!

/Peter

Aug 28 '06 #9
Salt_Peter <pj*****@yahoo.comwrote:
Pointers are always set using the address_of (&) operator or new.
Or the null pointer value (integral constant 0).

--
Marcus Kwok
Replace 'invalid' with 'net' to reply
Aug 28 '06 #10

Gernot Frisch wrote:
pointers are hell
pointers create bugs
pointers generate headaches
a pointer is a disease
etc

Stay away from pointers, use a reference instead.

Do you come from Java? Don't make pointers that bad, because they do
have their right of existance.
I do enjoy Java. Did you know that a Java reference is the equivalent
of a C++ pointer? Java would love to have the equivalent of a C++
reference.
>
hmm, how the hell are we going to explain references to you?

It's apointer - but not really a pointer.
No, a reference is an object (even when it is implemented as a pointer
down under -which is often not the case). A plain pointer is nothing
more than an adrress to something or nothing that may or may not be
valid.

Aug 28 '06 #11

Marcus Kwok wrote:
Salt_Peter <pj*****@yahoo.comwrote:
Pointers are always set using the address_of (&) operator or new.

Or the null pointer value (integral constant 0).
Indeed.
>
--
Marcus Kwok
Replace 'invalid' with 'net' to reply
Aug 28 '06 #12
"Salt_Peter" <pj*****@yahoo.comwrote:
pointers are hell
pointers create bugs
pointers generate headaches
a pointer is a disease
etc
Stay away from pointers, use a reference instead.
Lol - now come on - pointers are pretty useful and impossible
to work without in many cases.

Best Regards,

Lars
Aug 28 '06 #13
Salt_Peter wrote:
>
Gernot Frisch wrote:
pointers are hell
pointers create bugs
pointers generate headaches
a pointer is a disease
etc

Stay away from pointers, use a reference instead.

Do you come from Java? Don't make pointers that bad, because they do
have their right of existance.

I do enjoy Java. Did you know that a Java reference is the equivalent
of a C++ pointer? Java would love to have the equivalent of a C++
reference.
>>
hmm, how the hell are we going to explain references to you?

It's apointer - but not really a pointer.

No, a reference is an object
No. That's exactly what a reference is not.
(even when it is implemented as a pointer down under -which is often not
the case).
Really? Could you elaborate? Which compilers implement them differently? I'm
seriously interested in that.

Aug 28 '06 #14

"al pacino" <si*************@gmail.comskrev i meddelandet
news:11**********************@i42g2000cwa.googlegr oups.com...
>
Lars Uffmann wrote:
>"al pacino" <si*************@gmail.comwrote:
whats the issue with the following declaration, is it correct and
what
exactly is happening here.
[...]
int* ptr=10; // i suppose ptr is pointing to the memory location
which
stores the value 10.

Nope, this would make the pointer point to the memory ADDRESS 10
(0xa).
maybe i was confused as,
char *s="hello";
implies 's' pointing to the string HELLO.

but in the original case..what was happning was
int *ptr; and
ptr=10; //ptr now points to address 10;

why is it so in the case of int as in char.

thanks and regards.
Sorry, but you try to draw the conclusions the wrong way.

Here int follows the general rules, and char* is very special. It has
a whole set of extra rules, to be able to cope with the strange string
literal "hello" (which isn't a char!).
Bo Persson
Aug 28 '06 #15

Lars Uffmann skrev:
"Salt_Peter" <pj*****@yahoo.comwrote:
pointers are hell
pointers create bugs
pointers generate headaches
a pointer is a disease
etc
Stay away from pointers, use a reference instead.

Lol - now come on - pointers are pretty useful and impossible
to work without in many cases.
Correct. But that does not invalidate Salt_Peter's point. And I've seen
pointless cases where for one bad reason or the other pointers have
been used instead of a normal variable. Even in the cases where normal
variables can't be used raw pointers are almost never correct (unless
you garbage collect, of course).

/Peter

Aug 28 '06 #16
Marcus Kwok wrote:
Salt_Peter <pj*****@yahoo.comwrote:
>Pointers are always set using the address_of (&) operator or new.

Or the null pointer value (integral constant 0).
Or are explicitly casted from a "magic" value, usually in the case of
memory-mapped hardware.
Aug 28 '06 #17
Salt_Peter posted:
pointers are hell
pointers create bugs
pointers generate headaches
a pointer is a disease
etc

When posting to comp.lang.c++, it's wise to assume that your audience is
competant. Competant programmers can use pointers perfectly well.

--

Frederick Gotham
Aug 28 '06 #18

Frederick Gotham wrote:
Salt_Peter posted:
pointers are hell
pointers create bugs
pointers generate headaches
a pointer is a disease
etc


When posting to comp.lang.c++, it's wise to assume that your audience is
competant. Competant programmers can use pointers perfectly well.

--

Frederick Gotham
lol

If you do understand the limitations and intricacies of pointers, they
can certainly be very useful in the hands of a competant programmer.
I'm not one of those "competant" programmers.
As far as the audience here is concerned, i've learned way too much in
this newsgroup to hold its members in disrespect.

Aug 29 '06 #19
al pacino wrote:
maybe i was confused as,
char *s="hello";
implies 's' pointing to the string HELLO.

but in the original case..what was happning was
int *ptr; and
ptr=10; //ptr now points to address 10;

why is it so in the case of int as in char.
This is a reasonable question. I think you'll find that C++ has a
number of quirks and inconsistencies.

In this case, I think that C++ is handling the pointers consistently,
but that a string literal such as "hello" is actually a character array
- in this case char[ 6 ]. And when you set anything equal to an array
you get the starting address of the array.

This means, among other things, that if you derefernced "s" (in your
example) such as: char A = *s; A would take the value of the character
'h'.

Does that make sense?

Aug 29 '06 #20
Salt_Peter posted:
If you do understand the limitations

I don't think there's *anything* you can't do with a pointer.

and intricacies of pointers,

Two things to learn:

(1) A pointer stores a memory address.
(2) Pointer arithmetic is based upon the size of the pointed-to type.

There ain't much more to it.

they can certainly be very useful in the hands of a competant
programmer.

Competant programmers are the only ones I pay attention to (unless of
course someone is trying to learn and is asking a question).

I'm not one of those "competant" programmers.

Practise makes perfect.

--

Frederick Gotham
Aug 29 '06 #21

Frederick Gotham wrote:
Salt_Peter posted:
If you do understand the limitations


I don't think there's *anything* you can't do with a pointer.
What do you mean? You can't add two pointers for one thing, and
operator overloading is impossible with "only" pointers.
Aprart from that I agree there's a lot you can do with pointers. But
are you always interested in that? (The answer should be "NO").
>
and intricacies of pointers,


Two things to learn:

(1) A pointer stores a memory address.
(2) Pointer arithmetic is based upon the size of the pointed-to type.

There ain't much more to it.
Right! Come on.... look at the questions posed here. Loads of them come
from (ab)use of pointers.
>
they can certainly be very useful in the hands of a competant
programmer.


Competant programmers are the only ones I pay attention to (unless of
course someone is trying to learn and is asking a question).
And this is exactly the ones you find here (as original posters,
anyway).

[snip]

/Peter (competent)

Aug 29 '06 #22
"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:GH*******************@news.indigo.ie...
Salt_Peter posted:
If you do understand the limitations

I don't think there's *anything* you can't do with a pointer.
Dereference a null pointer.
Dereference a pointer which has been incremented beyond the end of the array
it points to.
Two things to learn:

(1) A pointer stores a memory address.
(2) Pointer arithmetic is based upon the size of the pointed-to type.

There ain't much more to it.
You're right, to an extent. Pointers in themselves are, in the right
situation, useful and simple to use. I think a lot of people's problems with
pointers come from the fact that they are closely linked to dynamic memory
allocation, which is something which is easy to mess up.
they can certainly be very useful in the hands of a competant
programmer.

Competant programmers are the only ones I pay attention to (unless of
course someone is trying to learn and is asking a question).
Competent programmers don't lay traps for themselves. Pointers are often
difficult to understand, and easy to mess up. Pointers are "evil" (see FAQ
for definition).

Philip

(Consistency is the hobgoblin of a small mind.)

Aug 29 '06 #23

Frederick Gotham wrote:
Salt_Peter posted:
If you do understand the limitations


I don't think there's *anything* you can't do with a pointer.
Thats the problem.
>
and intricacies of pointers,


Two things to learn:

(1) A pointer stores a memory address.
(2) Pointer arithmetic is based upon the size of the pointed-to type.

There ain't much more to it.
Let me correct you,
1) a pointer stores a memory address but not neccessarily an address to
an object. A pointer also cannot extend the lifetime of an object. A
reference cannot be broken, a pointer can.
2) pointer aritmetic is based on whatever pointer-type you've casted it
into as well. And what if the container is not sequential? Iterators
are a much better solution than pointer arithmetic. A pointer is not
bound to the type - its bound to the value, if any.
>
they can certainly be very useful in the hands of a competant
programmer.


Competant programmers are the only ones I pay attention to (unless of
course someone is trying to learn and is asking a question).

I'm not one of those "competant" programmers.


Practise makes perfect.
It certainly does. The more often an interface uses a pointer instead
of a reference the more often someone out there will find a way to
break that interface. The point here is why design with a pointer and
risk breakage when you can do it with a reference and guarantee
success?
>
--

Frederick Gotham
Aug 29 '06 #24
Salt_Peter posted:
1) a pointer stores a memory address but not neccessarily an address to
an object.

Indeed, it can also store the null pointer value.

A pointer also cannot extend the lifetime of an object.

And neither can a "reference to const". Read the rules for binding a
"reference to const" to an R-value, and all will become clear.

A reference cannot be broken, a pointer can.

Define "broken". Does the following reference become "broken"?

int &i = *new int;

delete &i;

i = 5;

2) pointer aritmetic is based on whatever pointer-type you've casted it
into as well.

Yes... it's relative to the pointed-to type.

And what if the container is not sequential? Iterators
are a much better solution than pointer arithmetic.

Not for simple things. I only resort to fancy features like vector, string,
etc. when things get overly complicated. For simple solutions, pointers are
just fine.

A pointer is not bound to the type - its bound to the value, if any.

I don't understand that statement.

>Practise makes perfect.

It certainly does. The more often an interface uses a pointer instead
of a reference the more often someone out there will find a way to
break that interface.

As long as we use bleach in our houses in the developed world, there's
going to be the occasional medical emergency whereby a child drank it.

I'm not going to stop using bleach just because it's not safe for two year
olds.

The point here is why design with a pointer and
risk breakage when you can do it with a reference and guarantee
success?

References are preferable in a lot of places. I was *not* advocating the
use of pointers everywhere, but rather I was expressing my own way of doing
things: I use pointers when they're good for getting the job done.

--

Frederick Gotham
Aug 29 '06 #25
When posting to comp.lang.c++, it's wise to assume that your audience is
competant. Competant programmers can use pointers perfectly well.
Competent programmers are rare, and their brains are better spent
solving new problems than tracking down memory leaks and
non-exception-safe code.

Pointers are best avoided. When avoiding them isn't possible, wrap
them in shared_ptr<>s or some other mechanism to make them safer and
easier to manage.

Aug 29 '06 #26

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.