memset(this, 0, sizeof(CLASS)) ?
Timur Tabi
I found this code in a sample:
IRQ::IRQ( unsigned irq_level )
{
memset(this, 0, sizeof(IRQ) ); // Set all data to 0.
_usIRQLevel = irq_level;
pIrqObject[ _usIRQLevel ] = this;
}
Does the memset really work? Is this compiler-specific?
Will it trash the virtual function table?
So far, it appears to with Watcom C/C++ 11.0, but class IRQ
is not inherited from anything, nor does anything inherit from
it. Did the programmer just get lucky, or does he know something
that I don't?
--
Timur Tabi, tt...@crystal.cirrus.com
Crystal Semiconductor, a division of Cirrus Logic
Want the best OS/2 soundcard? http://www.io.com/~timur/crystalos2.html
Mark Goddard
The virtual function table is NOT stored with the class, so I don't see why
this wouldn't work as long as this class does not inherit from any other
classes with data you do not want to clear.
Mark
Timur Tabi wrote in message <3532427C...@crystal.cirrus.com>...
Phlip
Mark Goddard wrote:
>The virtual function table is NOT stored with the class, so I don't see why
>this wouldn't work as long as this class does not inherit from any other
>classes with data you do not want to clear.
The secret pointer to that table _is_ stored in your class, so this 'memset'
zeros that pointer and introduces your program to crash-land.
The rule here is only convert a pointer into a pointer to void if that
pointer is typed to point to a PODS - a Plain Ol' Data Structure.
Alfred Kellner
Mark Goddard <mgod...@planeteers.com> wrote :
> The virtual function table is NOT stored with the class, so I don't see why
> this wouldn't work as long as this class does not inherit from any other
> classes with data you do not want to clear.
... but the pointer to virtual function table IS usually stored with the object
(IF virtual members are defined).
However, since class IRQ is not inherited from anything, nor does anything
inherit from it, there's no use (need) for virtual members and (likely) no vfptr.
IRQ looks (to me) like plain old data (POD) - so you're right - it should work.
> Mark
> Timur Tabi wrote :
> >I found this code in a sample:
> >
> > IRQ::IRQ( unsigned irq_level )
> > {
> > memset(this, 0, sizeof(IRQ) ); // Set all data to 0.
[---]
> >Will it trash the virtual function table?
> >
> >So far, it appears to with Watcom C/C++ 11.0, but class IRQ
> >is not inherited from anything, nor does anything inherit from
> >it. Did the programmer just get lucky, or does he know something
> >that I don't?
[---]
--ALfred
Michael J. Tobler
In article <3532427C...@crystal.cirrus.com>,
tt...@crystal.cirrus.com said...
> I found this code in a sample:
>
> IRQ::IRQ( unsigned irq_level )
> {
> memset(this, 0, sizeof(IRQ) ); // Set all data to 0.
> pIrqObject[ _usIRQLevel ] = this;
> }
Stay away from this sort of thing. I hope this isnt code
from the Greenleaf library!
My opinion: this is a very dangerous thing to do. It shows
laziness on the developers part who instilled this code.
Now others will see this and go: "Oh, this looks like a
quick and easy way to initialize my class". These will
eventually, if not already, lead to bad programming
practices. Let's looks at this seamingly innocent
line of code (found within a member function):
this = 0 ;
--
<<<<<<<<<< Blue Skies >>>>>>>>>>>
* Michael J. Tobler *
* mto...@no-spam-ibm.net *
* remove "no-spam-" when replying *
***********************************
Gary Mussar
Michael J. Tobler wrote:
> My opinion: this is a very dangerous thing to do. It shows
> laziness on the developers part who instilled this code.
> Now others will see this and go: "Oh, this looks like a
> quick and easy way to initialize my class". These will
> eventually, if not already, lead to bad programming
> practices. Let's looks at this seamingly innocent
> line of code (found within a member function):
> this = 0 ;
It is easy to spout "holier than thou"-isms, especially if you
do not have to worry about performance or memory. Please don't
delude yourself that anyone who has used memset like this is lazy
or a crappy programmer.
There are lots of dangerous things in both C nad C++. There are lots
of things that can bloat your code. There are lots of ways of programming
that are extremely inefficient. Using memset to init a POD is a tool
just like any other tool. If it is used, the developer should make
note of the potential side effects like killing the vtable ptr (if
that is the way virtual functions are implemented in the particular
compiler/platform) and overwriting the effects of member initializers
and constructors of contained members.
--
Gary Mussar <mus...@nortel.ca> Phone: (613) 763-4937
Nortel FAX: (613) 763-9406
Michael J. Tobler
In article <3534EB04...@ecars147.nortel.ca>,
mus...@ecars147.nortel.ca said...
> Michael J. Tobler wrote:
[snip]
> It is easy to spout "holier than thou"-isms, especially if you
> do not have to worry about performance or memory. Please don't
> delude yourself that anyone who has used memset like this is lazy
> or a crappy programmer.
My statement stands; I've been doing the C++ thing
since the mid 80's...I feel like I have a good
understanding of what might/might not be good practice.
Now, please demonstrate that this is GOOD practice by
citing some articles in CUJ or C++ Report, etc. I'm sure
someone such as Pete (Becker) would say this could be
used in a VERY VERY special situation, but, would probably
lean to the "not really a good thing to do" principle. I
might agree that it could be useful is a VERY focused
and specialized situation (maybe embedded system), but
would not display this as a mentoring excercise.
Gary Mussar
Michael J. Tobler wrote:
>
> In article <3534EB04...@ecars147.nortel.ca>,
> mus...@ecars147.nortel.ca said...
> > Michael J. Tobler wrote:
> [snip]
> > It is easy to spout "holier than thou"-isms, especially if you
> > do not have to worry about performance or memory. Please don't
> > delude yourself that anyone who has used memset like this is lazy
> > or a crappy programmer.
> [snip]
> My statement stands; I've been doing the C++ thing
> since the mid 80's...I feel like I have a good
> understanding of what might/might not be good practice.
I'm not talking about good/recommended practices. I'm taking exception
to those folk who claim that it is an abomination that has absolutely
no place in any code what so ever. I heard: "It shows laziness on the
developers part who instilled this code." There is never a mention that there
just might be reasonable places to use such a construct. Consider a POD
with 50-100 members (bit fields, etc.) that needs to be initialize. Many
compilers will emitted huge amounts of code to init each and every field
to zero which takes valuable CPU cycles and significant code space.
Of course the non lazy programmer doesn't care about efficiency since
CPU cycles and memory are insignificant.
Unfortunately, in embedded systems you will find that cycles and memory
are a fixed resource that you do not waste with abandon. Perhaps you are
one of the people who believe that C++ has no place in the embedded market?
I have heard that remark before but I believe C++ does have a place in
embedded apps.
> but
> would not display this as a mentoring excercise.
I wouldn't display this as a recommended practice or mentoring exercise
either. The original post didn't indicate that this was a sample from a
text book or course. They asked the question, "Did the programmer just get lucky"
and the answer is no, the developer knew exactly what they were doing. I
personally would have had warning comments around this code and vivid
note in the documentation for this class if this construct were used.
Michael J. Tobler
In article <35378BE8...@ecars147.nortel.ca>,
mus...@ecars147.nortel.ca said...
[snip]
> developers part who instilled this code." There is never a mention that there
> just might be reasonable places to use such a construct.
"I might agree that it could be useful is a VERY focused
and specialized situation (maybe embedded system), but
would not display this as a mentoring excercise."
So, although I didnt mention it in my ORIGINAL reply-post,
I did previously. Now, I am "guilty" of performing this
practice; I would not deny this. You have to understand the
point I'm trying to make: (first, let's look at the original
post):
<original>
Does the memset really work? Is this compiler-specific?
Will it trash the virtual function table?
So far, it appears to with Watcom C/C++ 11.0, but class IRQ
is not inherited from anything, nor does anything inherit from
it. Did the programmer just get lucky, or does he know something
that I don't?
</original>
I am reflecting the general opinion expressed by the
C++ community. It is NOT wise to do this, but in special
situations it could be implemented. Why didnt I say this
in my original reply? Because, it is obvious that this
poster doesnt understand the ramifications of doing this.
Sometimes it is best to say, "It's not good to do this"
without suggesting that it IS possible (I'm sure I'll get
a reply about this one). It's a good idea to get a tight
grip on the language before attempting this type
of "workaround".
Now, what was YOUR answer to the poster? Thank you.