also an inheritance problem

[David]

Hi all,

I am really new in C++. I met a problem. Could someone help me?

I have a base class:
class a
{
protected:
int b;
public:
int getint(){return b;};
setint (int a){ b=a};
};
class b:public a
{
.......
}
class c:public a
{
}

main
{
int k;
b *p1;
c *p2;
p1->setint(3);
k=p2->getint();
}

why the value of k is not 3? please help me. how can do that. thanks

[Victor Bazarov]

David wrote:

Hi all,

I am really new in C++. I met a problem. Could someone help me?

I have a base class:
class a
{
protected:
int b;
public:
int getint(){return b;};
setint (int a){ b=a};
};
class b:public a
{
......
}
class c:public a
{
}

main
{
int k;
b *p1;
c *p2;
p1->setint(3);
k=p2->getint();
}

why the value of k is not 3? please help me. how can do that. thanks

Even if we remove all syntax errors, you still have a very bad problem
there: both p1 and p2 pointers do not actually point to anything.
Trying to call a member function through a pointer that doesn't point
to a real (valid) object has undefined behaviour.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Salt_Peter]

David wrote:

Hi all,

I am really new in C++. I met a problem. Could someone help me?

I have a base class:
class a
{
protected:
int b;
public:
int getint(){return b;};
setint (int a){ b=a};
};
class b:public a
{
......
}
class c:public a
{
}

main
{
int k;
b *p1;
c *p2;
p1->setint(3);
k=p2->getint();
}

why the value of k is not 3? please help me. how can do that. thanks

Pointers are not objects. A pointer is nothing more than an address
that points to nothing.
The mailman will not construct a home because you sent a letter to a
fictitious address.
A car's license plate does not belong to a car until you put it on the
car.

#include <iostream>

class A
{
int a;
public:
A() : a(0) { } // default constructor
int get() const { return a; }
void set(int n) { a = n; }
};

int main()
{
A instance; // an object
std::cout << "&instance = " << &instance << std::endl;
A* p_a; // a pointer to nothing
p_a = 0; // a null pointer
std::cout << "pointer p_a = " << p_a << std::endl;
p_a = &instance; // p_a now actually points to something real
std::cout << "pointer p_a = " << p_a << std::endl;
p_a->set( 3 );
std::cout << "p_a->get() = " << p_a->get() << std::endl;
int k = p_a->get();
std::cout << "k = " << k << std::endl;
}

/*
&instance = 0x7fff42d853c0
pointer p_a = 0
pointer p_a = 0x7fff42d853c0
p_a->get() = 3
k = 3
*/

Whenever you declare a pointer, remember to always initialize it.

A a;
A* ptr = 0; // null pointer
ptr = &a; // a valid pointer to an object

[Dan Bloomquist]

David wrote:

Hi all,
b *p1;

....

p1->setint(3);

A reasonable compiler would have warned the uninitialized pointer. Have
you compiled this code?

Best, Dan.

[melix]

If you wanto to get same number whenever you called getInt function you
should declare int b as static.

And Its very right, dont forget to initialize the pointer. Because NULL
pointers has always been a trouble...

On Nov 9, 7:31 am, Dan Bloomquist <[e-mail]:

David wrote:

Hi all,
b *p1;

...

p1->setint(3);A reasonable compiler would have warned the uninitialized pointer. Have

you compiled this code?

Best, Dan.

[VJ]

Salt_Peter wrote:

A* ptr = 0; // null pointer

should be

A *ptr = NULL;

0 is not a null pointer

[Alf P. Steinbach]

* VJ:

Salt_Peter wrote:

>A* ptr = 0; // null pointer

should be

A *ptr = NULL;

0 is not a null pointer

Please only correct when the correction is correct.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[VJ]

Alf P. Steinbach wrote:

* VJ:

>Salt_Peter wrote:

>>A* ptr = 0; // null pointer

should be

A *ptr = NULL;

0 is not a null pointer

Please only correct when the correction is correct.

Isn't the correction correct?

The 1st googled page about c++ NULL pointer gives:
http://www.fredosaurus.com/notes-cpp...llpointer.html
and I am sure there are more

Same goes for
bool check = 0;
and similar definitions

[Jim Langston]

"David" <cl*****@gmail.comwrote in message
news:11*********************@f16g2000cwb.googlegro ups.com...

Hi all,

I am really new in C++. I met a problem. Could someone help me?

I have a base class:
class a
{
protected:
int b;
public:
int getint(){return b;};
setint (int a){ b=a};
};
class b:public a
{
......
}
class c:public a
{
}

main
{
int k;
b *p1;

b* p1 = new b();

c *p2;

c* p2 = new c();

p1->setint(3);
k=p2->getint();

delete p1;
delete p2;

}

why the value of k is not 3? please help me. how can do that. thanks

[Alf P. Steinbach]

* VJ:

Alf P. Steinbach wrote:

>* VJ:

>>Salt_Peter wrote:

A* ptr = 0; // null pointer
should be

A *ptr = NULL;

0 is not a null pointer

Please only correct when the correction is correct.

Isn't the correction correct?

Nope.

It's correct that literal 0 is not itself a null-pointer. It's
incorrect that the macro NULL is a null-pointer: NULL is required to be
defined as a zero constant integral rvalue, e.g. as 0 or 0L. Both
designate the null-pointer value of type T* when used in a context where
a T* is expected, such as the initializations above, and both designate
simply a zero integral value in other contexts.

Reason etc. In C, as opposed to C++, NULL can be defined as a pointer
value, e.g. as (void*)0, which can help good compilers and lint tools to
emit meaningful diagnostics. In C++ void* is not assignment compatible
with other pointer types, so (void*)0 is not a practical null-pointer
value in C++ -- you'd need casts peppered all over the code. In C++0x
it seems we'll get a special keyword nullptr. MSVC already uses that
keyword for .NET code, and IIRC it's been mentioned that g++ implements
that keyword, although the 3.4.4 compiler doesn't recognize it, and
although I'm unable to find any reference at the moment. It's possible
to define something similar, but part of the rationale for the keyword
is that such library solutions lead to gobbledegook error diagnostics.

The 1st googled page about c++ NULL pointer gives:
http://www.fredosaurus.com/notes-cpp...llpointer.html
and I am sure there are more

Yes, the net is full of disinformation.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[VJ]

Alf P. Steinbach wrote:

* VJ:

>>>>
A* ptr = 0; // null pointer

should be

A *ptr = NULL;

0 is not a null pointer
Please only correct when the correction is correct.

Isn't the correction correct?

Nope.

It's correct that literal 0 is not itself a null-pointer. It's
incorrect that the macro NULL is a null-pointer: NULL is required to be
defined as a zero constant integral rvalue, e.g. as 0 or 0L. Both
designate the null-pointer value of type T* when used in a context where
a T* is expected, such as the initializations above, and both designate
simply a zero integral value in other contexts.

Reason etc. In C, as opposed to C++, NULL can be defined as a pointer
value, e.g. as (void*)0, which can help good compilers and lint tools to
emit meaningful diagnostics. In C++ void* is not assignment compatible
with other pointer types, so (void*)0 is not a practical null-pointer
value in C++ -- you'd need casts peppered all over the code. In C++0x
it seems we'll get a special keyword nullptr. MSVC already uses that
keyword for .NET code, and IIRC it's been mentioned that g++ implements
that keyword, although the 3.4.4 compiler doesn't recognize it, and
although I'm unable to find any reference at the moment. It's possible
to define something similar, but part of the rationale for the keyword
is that such library solutions lead to gobbledegook error diagnostics.

I see you are using 0 instead of NULL, but which is more correct?

The way I see it, once they put the read nullPtr, it will be easier to do
#undef NULL
#define NULL nullPtr
instead of changing the whole code :P

>
Yes, the net is full of disinformation.

I have to agree there :(

[Kirit Sælensminde]

David wrote:

Hi all,

I am really new in C++. I met a problem. Could someone help me?

I have a base class:
class a
{
protected:
int b;
public:
int getint(){return b;};
setint (int a){ b=a};
};

As others have pointed out your code doesn't compile so clearly isn't
the code that you've been running to get your output.

void setint( int a ) { b = a; }

class b:public a
{
......
}
class c:public a
{
}

main
{
int k;
b *p1;
c *p2;
p1->setint(3);
k=p2->getint();
}

why the value of k is not 3? please help me. how can do that. thanks

You have not initialised either p1 or p2 so both are probably just
pointing into random space. You must initialise them both.

The code implies that you have an incorrect mental model of how these
pointers should work. If you give us your explanation of what you are
expecting to do and how you think the code implements that expectation
then I think you will get a much more useful reply from the list.
K

[Alf P. Steinbach]

* VJ -Alf P. Steinbach:

>
I see you are using 0 instead of NULL,

Where?

>but which is more correct?

Both are technically correct.

The way I see it, once they put the read nullPtr, it will be easier to do
#undef NULL
#define NULL nullPtr
instead of changing the whole code :P

Apart from breaking the formal rules (§17.4.3.1/3), and apart from the
speling eror, this will break code that legitimately uses NULL as a zero
integral value.

But of course you may define your own NULLPTR macro, or whatever.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[VJ]

Alf P. Steinbach wrote:

* VJ -Alf P. Steinbach:

>>
I see you are using 0 instead of NULL,

Where?

I should have said "I assume you are using 0 instead of NULL".
So, which one are you using?

>

>The way I see it, once they put the read nullPtr, it will be easier to do
#undef NULL
#define NULL nullPtr
instead of changing the whole code :P

Apart from breaking the formal rules (§17.4.3.1/3), and apart from the
speling eror, this will break code that legitimately uses NULL as a zero
integral value.

What spelling error? There might be, because English is not my native
language.

It will not break code which uses NULL only as a null pointer, and
nothing else. Besides, if NULL is integer zero, then this will compile
as well:

bool status = NULL;
int number = NULL;

but are there people using NULL in such way?

[Alf P. Steinbach]

* VJ:

Alf P. Steinbach wrote:

>* VJ -Alf P. Steinbach:

>>The way I see it, once they put the read nullPtr, it will be easier
to do
#undef NULL
#define NULL nullPtr
instead of changing the whole code :P

Apart from breaking the formal rules (§17.4.3.1/3), and apart from the
speling eror, this will break code that legitimately uses NULL as a
zero integral value.

What spelling error? There might be, because English is not my native
language.

C++ is case-sensitive.

It will not break code which uses NULL only as a null pointer, and
nothing else. Besides, if NULL is integer zero,

It is.

>then this will compile
as well:

bool status = NULL;
int number = NULL;

but are there people using NULL in such way?

<url: http://preview.tinyurl.com/ylugxc>.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[VJ]

Alf P. Steinbach wrote:

* VJ:

>Alf P. Steinbach wrote:

>>* VJ -Alf P. Steinbach:

The way I see it, once they put the read nullPtr, it will be easier
to do
#undef NULL
#define NULL nullPtr
instead of changing the whole code :P

Apart from breaking the formal rules (§17.4.3.1/3), and apart from
the speling eror, this will break code that legitimately uses NULL as
a zero integral value.

What spelling error? There might be, because English is not my native
language.

C++ is case-sensitive.

I know, but whats the error?

>It will not break code which uses NULL only as a null pointer, and
nothing else. Besides, if NULL is integer zero,

It is.

I did not say it is not.

>

>then this will compile as well:

bool status = NULL;
int number = NULL;

but are there people using NULL in such way?

<url: http://preview.tinyurl.com/ylugxc>.

This code is really representative:

int i2d_GENERAL_NAME(GENERAL_NAME *a, unsigned char **pp)
{
unsigned char *p;

/* Save the location of initial TAG */
if(pp) p = *pp;
else p = NULL;
What kind of project is this?!? They are comparing unsigned char** to false!

I bet they are ignoring milion warnings

Also this:
if (a == NULL) return;
Easiest way to make a stupid error like this:
if (a = NULL) return;

[F.J.K.]

VJ schrieb:

Alf P. Steinbach wrote:

* VJ:

Alf P. Steinbach wrote:

* VJ -Alf P. Steinbach:

The way I see it, once they put the read nullPtr, it will be easier
to do
#undef NULL
#define NULL nullPtr
instead of changing the whole code :P

Apart from breaking the formal rules (§17.4.3.1/3), and apart from
the speling eror, this will break code that legitimately uses NULL as
a zero integral value.
What spelling error? There might be, because English is not my native
language.

C++ is case-sensitive.

I know, but whats the error?

Case-sensitive means an uppercase letter like 'P' is not the same as
the lowercase letter 'p'. So you have to take care, not to use the
wrong case in your source code. You are as sloppy in your example code
as you are in researching what is legal C++ and what is disinformation
on the web. This results in errors that you readily multiply over the
mailing list, resulting in even more disinformation on the web :-(

[Victor Bazarov]

VJ wrote:

>>>>The way I see it, once they put the read nullPtr, it will be
easier to do
#undef NULL
#define NULL nullPtr

I know, but whats the error?

nullptr, not nullPtr.

[..]

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[VJ]

F.J.K. wrote:

VJ schrieb:

>>Alf P. Steinbach wrote:

>>>* VJ:
Alf P. Steinbach wrote:
>* VJ -Alf P. Steinbach:
>
>
>>The way I see it, once they put the read nullPtr, it will be easier
>>to do
>>#undef NULL
>>#define NULL nullPtr
>>instead of changing the whole code :P
>
>
>
>Apart from breaking the formal rules (§17.4.3.1/3), and apart from
>the speling eror, this will break code that legitimately uses NULL as
>a zero integral value.
What spelling error? There might be, because English is not my native
language.
C++ is case-sensitive.

I know, but whats the error?

Case-sensitive means an uppercase letter like 'P' is not the same as
the lowercase letter 'p'. So you have to take care, not to use the

I said I know what is case-sensitive, but I did not know nullPtr is
actualy nullptr

wrong case in your source code. You are as sloppy in your example code
as you are in researching what is legal C++ and what is disinformation
on the web. This results in errors that you readily multiply over the
mailing list, resulting in even more disinformation on the web :-(

Do you have my example code to say I am sloppy?
I am not the one who assign integer numbers to a pointer, compare bool
variables to 0, compare integer to false, compare pointers to false, etc.

The page I found confirms what I said about using 0 as null pointer,
therefore someone else is spreading disinformation on the web :P

Also every normal c++ coding standard will tell you to use NULL(or
whatever there is), instead of 0
ps I am using NULL for null pointer, and have not seen nullptr yet

[Salt_Peter]

VJ wrote:

Salt_Peter wrote:

A* ptr = 0; // null pointer

should be

A *ptr = NULL;

0 is not a null pointer

The pointer is not a literal 0, its an *address*.
Note that NULL means nothing until a library defines it.
Its exactly like using EXIT_SUCCESS or EXIT_FAILURE or any other
definition.
They don't exist until you or some library defines the macro. < ewww-
macros !?x?!>

If you see something like:

A* ptr = NULL;

You have no way of knowing what NULL is except through inspection. As
far as i'm concerned, that NULL could be anything. Thats why its rather
rare in C++ code. On the other hand:

A* ptr = 0;

Is explicitly a nullified pointer with a very clear intention.
And as recommended, in modern code, nullptr (not nullPtr) can safely be
defined as 0.
Perhaps i might suggest the following for reference and an interesting
read:
http://www.research.att.com/~bs/bs_faq2.html

[Gavin Deane]

VJ wrote:

Also every normal c++ coding standard will tell you to use NULL(or
whatever there is), instead of 0

<Response>
I must have only read abnormal coding guidelines then. One of the
abnormal sources was Stroustrup's C++ Programming Language (3rd
edition). There have been many others, including this newsgroup. I must
have missed the normal ones.

Use any more macros than really necessary?
Type three extra characters to end up with precisely the same meaning
as far as the complier is concerned?
Risk confusing human readers on the occasion I forget the guideline and
revert to using 0 (as I surely will at some point, and the compiler
will equally surely not spot my "mistake").

Not my cup of tea I'm afraid.

Style guidelines that are not checked automatically need more careful
thought than that.

<Alternative Response>
If you make sweeping generalisations or assertions that are not true,
the only likely outcome is damage to your own credibility.

Gavin Deane

[Salt_Peter]

[rearranged]

Can you please, please not top post?

On Nov 9, 7:31 am, Dan Bloomquist <[e-mail]:

David wrote:

Hi all,
b *p1;

...

p1->setint(3);A reasonable compiler would have warned the uninitialized pointer. Have

you compiled this code?

Best, Dan.

melix wrote:

If you wanto to get same number whenever you called getInt function you
should declare int b as static.

Thats a misconception. If int b where declared as static, it would only
exist in that compilation unit. Statics have file scope. Static
variables have *internal linkage*. So static int b means one thing in
one compilation unit and a completely different variable in another.
Nasty, nasty bugs.
These create more problems than they solve. You should not use statics
until you realize the implications.

>
And Its very right, dont forget to initialize the pointer. Because NULL
pointers has always been a trouble...

[Salt_Peter]

VJ wrote:

Alf P. Steinbach wrote:

* VJ:

Alf P. Steinbach wrote:

* VJ -Alf P. Steinbach:

The way I see it, once they put the read nullPtr, it will be easier
to do
#undef NULL
#define NULL nullPtr
instead of changing the whole code :P

Apart from breaking the formal rules (§17.4.3.1/3), and apart from
the speling eror, this will break code that legitimately uses NULL as
a zero integral value.
What spelling error? There might be, because English is not my native
language.

C++ is case-sensitive.

I know, but whats the error?

nullptr != nullPtr

>

It will not break code which uses NULL only as a null pointer, and
nothing else. Besides, if NULL is integer zero,

It is.

I did not say it is not.

then this will compile as well:

bool status = NULL;
int number = NULL;

but are there people using NULL in such way?

<url: http://preview.tinyurl.com/ylugxc>.

This code is really representative:

int i2d_GENERAL_NAME(GENERAL_NAME *a, unsigned char **pp)
{
unsigned char *p;

/* Save the location of initial TAG */
if(pp) p = *pp;
else p = NULL;
What kind of project is this?!? They are comparing unsigned char** to false!

Thats not a comparison.

>
I bet they are ignoring milion warnings

Also this:
if (a == NULL) return;
Easiest way to make a stupid error like this:
if (a = NULL) return;

There is an easy fix to that. Always place the constant on the left
side since you can't assign to an rvalue:

if ( /*NULL*/ 0 == a)
{
....
}

That way the compiler will flag an error if you replace == with an
assignment.

[Marcus Kwok]

Salt_Peter <pj*****@yahoo.comwrote:

melix wrote:

>If you wanto to get same number whenever you called getInt function you
should declare int b as static.

Thats a misconception. If int b where declared as static, it would only
exist in that compilation unit. Statics have file scope. Static
variables have *internal linkage*. So static int b means one thing in
one compilation unit and a completely different variable in another.

However, in the context of the original post, int b is a class member,
so static has a different meaning in that context.

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

[Salt_Peter]

Marcus Kwok wrote:

Salt_Peter <pj*****@yahoo.comwrote:

melix wrote:

If you wanto to get same number whenever you called getInt function you
should declare int b as static.

Thats a misconception. If int b where declared as static, it would only
exist in that compilation unit. Statics have file scope. Static
variables have *internal linkage*. So static int b means one thing in
one compilation unit and a completely different variable in another.

However, in the context of the original post, int b is a class member,
so static has a different meaning in that context.

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

Yes, this is true, thanks for pointing that out.

<but>
In the context of the original post, a static variable is not
warranted.
The context being that somehow that integer would not be the same
integer if the object were accessed repeatedly. Which is clearly a
false pretext.

Then some guy comes along and pushes elements onto a container and
wonders why the elements are unable to keep state. Classes with only
static members are not good OO design like a Singleton Design Pattern
would be.

[VJ]

Salt_Peter wrote:

>>int i2d_GENERAL_NAME(GENERAL_NAME *a, unsigned char **pp)
{
unsigned char *p;

/* Save the location of initial TAG */
if(pp) p = *pp;
else p = NULL;
What kind of project is this?!? They are comparing unsigned char** to false!

Thats not a comparison.

They are comparing a pointer to zero in the if command. Or, to make
things worse and read it literaly what it says - they are treating a
pointer as a bool variable

I dont know why it is hard to write:
if ( NULL != pp )
{
p = *pp;
}
else
{
p=NULL;
}
It's easier to read and change such code.

But, I guess it is a matter of preferences.

[Victor Bazarov]

VJ wrote:

[..]
I dont know why it is hard to write:
if ( NULL != pp )

It's not hard to write. It's hard to read. Besides, have you
heard of "idiomatic use"? The 'if (pointer)' idiom has been
around since 1970s. Many people grew up reading it (and hence
writing it).

{
p = *pp;
}
else
{
p=NULL;
}
It's easier to read and change such code.

No, it's not.

>
But, I guess it is a matter of preferences.

Exactly.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask