also an inheritance problem

G

Gavin Deane

VJ said:
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
 
S

Salt_Peter

[rearranged]

Can you please, please not top post?
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.
 
S

Salt_Peter

VJ said:
I know, but whats the error?

nullptr != nullPtr
I did not say it is not.


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.
 
M

Marcus Kwok

Salt_Peter said:
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.
 
S

Salt_Peter

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

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.
 
V

VJ

Salt_Peter said:
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.
 
V

Victor Bazarov

VJ said:
[..]
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top