This is probably more a general C++ question, but I'm working on a POV
project, so I know you'll be glad to help.  How do I assign some typed
pointer X to an element of a void pointer array?  Here's what I have
(greatly simplified):

void **array;
array=(void **) malloc(sizeof(void *)*NumberOfElements);

CMyObject *thing;
thing=new CMyObject();

location=&array[4];
//compiler chokes here (invalid indirection):
*location=thing;

Thanks in advance for your invaluable help.

Post a reply to this message

In article <3d20cb07$1@news.povray.org> , "cadman" 
<REM### [at] povraycouk> wrote:

> *location=thing;

Make sure location is of type (CMyObject **) , then use casting.

    Thorsten

Post a reply to this message

cadman wrote:

> This is probably more a general C++ question, but I'm working on a POV
> project, so I know you'll be glad to help.  How do I assign some typed
> pointer X to an element of a void pointer array?  

Are you sure that there's no better way? Something like 
"Pointer to base class" or even better an auto_pointer to a base class.
If you put these auto_pointers into the standard container "vector",
deallocation could be handled cleanly by the destructor.

Of course, it depends heavily on your application, whether my suggestions
make sense, but that's why they are suggestions. (Personally, I try to 
avoid pure pointers and arrays whenever it's possible.)

Best regards 
Thomas

Post a reply to this message

Therein lies the problem.  I guess I forgot that part of the code:  location
is of type (void *).  I want location (and all elements of the array) to be
able to hold anything (pointer to a texture, an object, a vector,...).  MFC,
of course, has untyped pointer collection classes, but I'm hoping for a
certain degree of portability here...


"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3d20da0f$1@news.povray.org...
> In article <3d20cb07$1@news.povray.org> , "cadman"
> <REM### [at] povraycouk> wrote:
>
> > *location=thing;
>
> Make sure location is of type (CMyObject **) , then use casting.
>
>     Thorsten

Post a reply to this message

In article <3d2194d3$1@news.povray.org> , "cadman" 
<REM### [at] povraycouk> wrote:

> Therein lies the problem.  I guess I forgot that part of the code:  location
> is of type (void *).  I want location (and all elements of the array) to be
> able to hold anything (pointer to a texture, an object, a vector,...).  MFC,
> of course, has untyped pointer collection classes, but I'm hoping for a
> certain degree of portability here...

Well, if you really, really want such a mess, this

    ((CMyObject *)(*location))=thing;

and/or this should work

    *location=(void*)thing;

depending on what you are really doing.

However, I strongly suggest you don't mess around with void pointers in such
a way.  The proper way is to inherit everything array can hold from a common
base class and let array point to those.

It is absolutely inappropriate to use void for what you try to do in C++ and
there is no excuse.  Of course, I know you will probably ignore this advice
and in a few weeks fight against constant crashes, but then don't ask how to
fix those -- you already know the answer now ;-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> The proper way is to inherit everything array can hold from a common
> base class and let array point to those.

  Yes, that's the right way of doing it. This is one thing where Java
*forces* you to make good code: There is no void*, but you must use
inheritance instead in order to achieve this.

  Also, I'm not sure if the ISO-C++ standard guarantees that a
pointer-to-class will always have the same size as void*.
  If the standard does not guarantee this, then theoretically storing
a pointer-to-class into a void* may lead to non-portable code (even though
every single C++ compiler I know uses regular pointers for classes as well,
so this is just very theoretical).

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:

> Thorsten Froehlich <tho### [at] trfde> wrote:
>> The proper way is to inherit everything array can hold from a common
>> base class and let array point to those.
> 
>   Yes, that's the right way of doing it. This is one thing where Java
> *forces* you to make good code: There is no void*, but you must use
> inheritance instead in order to achieve this.

No, it doesn't. It's just that the thing is named "object" instead of
"void*". Furthermore, you are forced to use it, if you want to create
generic container classes. In C++, you can easily avoid void* in most
if not all cases and still have static type checking.

(No flame war please. IMO Java has its strengths in other fields.)

Thomas (who really misses templates/generics in Java)

Post a reply to this message

Thomas Willhalm <tho### [at] uni-konstanzde> wrote:
> No, it doesn't. It's just that the thing is named "object" instead of
> "void*". Furthermore, you are forced to use it, if you want to create
> generic container classes.

  Firstly, what is so bad about having to inherit your classes from a
common base class?
  Secondly, no-one forces you to do so. You can make a more rational design
by creating your own base class, which has common things to all classes.

> In C++, you can easily avoid void* in most
> if not all cases and still have static type checking.

  I can't think of any way of avoiding void* other than using a common
base class, as in Java.
  Of course you can make your container a template, but that doesn't allow
you to put objects of different types in that container. All the objects
must be of the same type.

> Thomas (who really misses templates/generics in Java)

  I think they are planning to add template support to Java.
  That's really funny when you think about how Java-freaks hate(d) templates.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:

> Thomas Willhalm <tho### [at] uni-konstanzde> wrote:
>> No, it doesn't. It's just that the thing is named "object" instead of
>> "void*". Furthermore, you are forced to use it, if you want to create
>> generic container classes.
> 
>   Firstly, what is so bad about having to inherit your classes from a
> common base class?
>   Secondly, no-one forces you to do so. You can make a more rational
>   design
> by creating your own base class, which has common things to all classes.

Sorry, when talking about _generic_container_classes_ I meant a class
like linked list, dynamic array, heap, hashtable, and so on, where the
type of the content is not known to the programmer of the container class.  

In C++, you can use templates to design them generic in the sense that the
coder of the container class does not have to know the type of objects
that are inserted while still ensuring at compile time that the same kind
of objects is inserted or returned. (In case you want to insert objects
of different type the right way to do it is of course - as you wrote -
to create a common base class.) 

In Java however, I don't know any other way than inserting and returning
objects of type "object". IMO this is as bad as inserting and returning
"void*". So you can avoid "object" in Java and "void*" in C++ if you
design the items that are inserted in your container, but you can't
avoid "object" if you don't.
 
Thomas

Post a reply to this message

Thomas Willhalm <tho### [at] uni-konstanzde> wrote:
> In C++, you can use templates to design them generic in the sense that the
> coder of the container class does not have to know the type of objects
> that are inserted while still ensuring at compile time that the same kind
> of objects is inserted or returned. (In case you want to insert objects
> of different type the right way to do it is of course - as you wrote -
> to create a common base class.) 

  Yes, templates are really handy for things like this (and that's why AFAIK
they are planning to add templates to Java as well).
  Of course it has the limitation that you can only store one type of objects
inside a certain instance of the container. If you need to store different
type of objects, you need to store only base-class-type pointers (and the
objects themselves have to be created separaterly, usually dynamically).

> In Java however, I don't know any other way than inserting and returning
> objects of type "object". IMO this is as bad as inserting and returning
> "void*". So you can avoid "object" in Java and "void*" in C++ if you
> design the items that are inserted in your container, but you can't
> avoid "object" if you don't.

  Even though in most cases an Object reference is practically the same
thing as a void*, it still is better than void*. I think that Object has
some properties (ie. methods).

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message