This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: void pointer and map (fwd)
- From: Anitha Boyapati <anithab at sankhya dot com>
- To: Ted Byers <r dot ted dot byers at rogers dot com>
- Cc: Andrew Haley <aph at redhat dot com>, <gcc-help at gcc dot gnu dot org>
- Date: Sat, 22 Dec 2007 11:25:10 +0530 (IST)
- Subject: Re: void pointer and map (fwd)
On Fri, 21 Dec 2007, Ted Byers wrote:
>
> First, I don't see the point of reinterpret cast here,
> or even use of a void pointer. Unless this is a
> really dumbed down example, you probably ought to
> think about the types you'll be using for this.
It is really a badly tailored version of a bigger problem.
Actually, it all boils down to usage of types. With "Value", I need to
able to represent both C++ data types (int, long, long long) as well as
some of the user defined data types. Previously, I used a union for built
in types and objects of user defined types packed into Value. Now that
gave me a performance hit.(Everytime a Value is initialised, all the
constructors of user defined types have to be gone through unnecessarily
while an instance of Value reprensents only one of the types) It was
really slow. So came a void pointer and a reinterpret cast along with it.
I have one more question : Now that my code is heavily loaded with
reinterpret_cast, does this have a performance problem ? In short,
does exhaustive usage of reinterpret_cast hinder performance ?
That will be good to know.
>
> Second, why use a naked pointer instead of a smart
> pointer (such as that found in boost)? You can use
This is something I was unaware of. Maybe I will give it a try.
> the latter wherever you'd be tempted to use a naked
> pointer, and it becomes all the easier to avoid the
> sort of problem you posted about. With a smart
> pointer, you could even get rid of the destructor
> without losing anything, unless you need to make it
> virtual, should there be a chance another class could
> be derived from Value, which has a need for a
> non-trivial destructor.
Nothing virtual in the structure. Thanks!
>
> HTH
>
> Ted
>
--
Regards,
Anitha B
@S A N K H Y A