void* in a struct

hi
i am using a struct which contains "void *" I am using void * bcoz i need to assign any data type to the vdptrVal

Code:

---

struct myStruct
{
CString strVal;
void *vdptrVal;
};

typedef myStruct testStruct;

---

assume a class foo

Code:

---

class foo
{
 private:
        foo();
        virtual ~foo();
        CString valStr;
        int valInt;
        testStruct temp;
public:
        void someFoo()
        {
        ..
        }
};

foo::foo()
{
        CString str = "HELLO";
        valInt = 10;       
        temp.strVal = str;
        temp.vdptrVal = (void*) &valInt;//here acutally i want to store the address of the variable valInt whose value keeps chgning
}

---

Now can i retrieve the value of valInt from the struct variable temp. At any point of time when the app is executing.

If a pointer's type is void *, the pointer can point to any variable that is not declared with the const or volatile keyword.

A void pointer cannot be dereferenced unless it is cast to another type.

A void pointer can be converted into any other type of data pointer.

You should be very careful when using void pointer, you must know the exact datatype the void pointer is holding when you cast back from void to specfic data type.

For Example

Code:

---


void *pV;
int i = 7;
int *pInt;
pV = &i;
// Cast optional in C required in C++
pInt = (int *)pV;

---

Is there is any problem doing this?

Code:

---

int i =*((int*)temp.vdptrVal)  ///within member function i assume it is int GetValInt();

---

Quote:

---

Originally Posted by santoct2002

If a pointer's type is void *, the pointer can point to any variable that is not declared with the const or volatile keyword.

A void pointer cannot be dereferenced unless it is cast to another type.

A void pointer can be converted into any other type of data pointer.

---

hi thnx,
its a typo thr in my original post instead of void* say int*

Quote:

---

Originally Posted by venkyhyd

foo::foo()
{
CString str = "HELLO";
valInt = 10;
temp.strVal = str;
temp.vdptrVal = (void*) &valInt;//here acutally i want to store the address of the variable valInt whose value keeps chgning
}

---

Quote:

---

Originally Posted by upashu2

Is there is any problem doing this?

Code:

---

int i =*((int*)temp.vdptrVal)  ///within member function i assume it is int GetValInt();

---

---

there is no problem using this but now assume if ur using this vector of type myStruct, then how like

Quote:

---

class foo
{
private:
foo();
virtual ~foo();
CString valStr;
int valInt;
testStruct temp;
vector<testStruct > vectStruct;
public:
void someFoo()
{
..
}
};

foo::foo()
{
CString str = "HELLO";
valInt = 10;
temp.strVal = str;
temp.vdptrVal = (void*) &valInt;
vectStruct.push_back(temp);
}

---

here how do i retrieve the value from the vector vectStruct and assume that thr r different types variables like int, float, double ...etc...then how...

Why would you make tempStruct a member of the class Foo which contains the integer variable you are dealing with???

Also, if you know it is supposed to deal with an integer variable then why would you make a void*??? Else santoct2002's post gives the answer.

Cheers,
Exterminator.

Quote:

---

Originally Posted by venkyhyd

here how do i retrieve the value from the vector vectStruct and assume that thr r different types variables like int, float, double ...etc...then how...

---

You might need to keep track of the datatype that you would be storing in testStruct's vdptrVal member. For this you could add another member in testStruct. I hope there must be some better way to accomplish this though.

Cheers

Have you anytime heard about VARIANT type?? variant data type is used to extensively in COM programming. This may help you to hold different data type value. but It needs some considerable time to spend on this datatype to use your requirements, that I leave it to you. You can get more details in MSDN and in Codeguru also. Search for Variant.

Variant

Quote:

---

Originally Posted by santoct2002

Have you anytime heard about VARIANT type?? variant data type is used to extensively in COM programming. This may help you to hold different data type value. but It needs some considerable time to spend on this datatype to use your requirements, that I leave it to you. You can get more details in MSDN and in Codeguru also. Search for Variant.

---

i was giving thought on variant too but as i have never used it and never had a free hand on it...i thought of using vector

anyhow shld work on variant too, any small example will do good in using variant for me.

thnx
venky

How about a thin template?

Code:

---

template <typename T>
 struct foo
 {
        void setval(T* v)
        {
                val_ = v;
        }
 
        T* getval() const
        {
                return static_cast<T*>(val_);
        }
 
 private:
        void* val_;
 };

---

Some people claim that thin templates are more space-efficient than full-blown templates, but I remain to be convinced...

Quote:

---

Originally Posted by Graham

Some people claim that thin templates are more space-efficient than full-blown templates, but I remain to be convinced...

---

THIN TEMPLATE :confused: needto browse :rolleyes: on this first then i shll try this suggestion, thnx

venky :thumb:

I've never heard of a "thin" template. And with your template since you're tied to type T anyway why not use a T* pointer. Or is that the concept of a thin template (no typed data-members).

I prefer to use a binary buffer and have your class know how to create one and create itself from one such that it is a reversible process. You can then specialise common cases such as int, float, double, std::string whilst keeping it extensible.

I just looked up thin templates and found it on the Symbian page (and I know Graham works on the Symbian platform which is used for mobile-phone software, because he's stated that a few times).

The concept is that the compiler will only create one set of code for all template parameter types.

Quote:

---

Originally Posted by Graham

Some people claim that thin templates are more space-efficient than full-blown templates, but I remain to be convinced...

---

I got some stuff about thin templates at this link :
http://www.codeguru.com/Cpp/Cpp/cpp_...cle.php/c7927/
There is a small note there:

Quote:

---

Some compilers can be configured to automatically inline class member functions if they are called from class itself. This can eliminate "thin templates" effects. In the "Microsoft C++ compiler," you can use the /Ob0 command-line switch to disable inline function expansion or use functions with variable number of arguments (for example - void ThinAdd(SThinItem *a_poDst, ...) ); such functions can't be inlined.

---

Is this the reason (in-lining) why you are not convinced if this can be space-efficient? Any other reasons?

I just read about "thin templates" and i feel if you are separting out the template-dependent code and the template-independent code, then for sure it is going to save some extra copies of the template-independent code into the final executable.

How do we implement thin templates? I mean how is their implementation different from usual templates? The declarations etc seem same to me or am I missing something?

Cheers

Quote:

---

Originally Posted by venkyhyd

Code:

---

struct myStruct
{
CString strVal;
void *vdptrVal;
};

typedef myStruct testStruct;

---

assume a class foo

Code:

---

class foo
{
 private:
        foo();
        virtual ~foo();
        CString valStr;
        int valInt;
        testStruct temp;
public:
        void someFoo()
        {
        ..
        }
};

foo::foo()
{
        CString str = "HELLO";
        valInt = 10;       
        temp.strVal = str;
        temp.vdptrVal = (void*) &valInt;//here acutally i want to store the address of the variable valInt whose value keeps chgning
}

---

---

The problem with your code is that you give another function the pointer to a function foo local variable which get's destroyed after the function foo returns, thus any other function after returning from foo cannot use this pointer anymore. If you want to store an int in the void* you can simply store the value of the integer as pointer...:

Code:

---

temp.vdptrVal = (void*)valInt;

---

And reuse it in another function.:

Code:

---

void foo::foo2 ( const testStruct& argument )
{
  int intVal = (int)argument.vdptrVal;
  // ...
}

---

This is just a fix for your code for understanding. There are many better solutions here than your's for example creating a template or using VARIANT type if you work on Windows.

I would go for the template.

Best Regards

Quote:

---

Originally Posted by venkyhyd

Code:

---

struct myStruct
{
CString strVal;
void *vdptrVal;
};

typedef myStruct testStruct;

---

---

Just one small thing...basically there is no need for 'typedef'ing structure that way in C++....the keyword 'struct' already defines a new type...thus, you can use it directly...

Code:

---

myStruct temp;

---

Quote:

---

Originally Posted by exterminator

Is this the reason (in-lining) why you are not convinced if this can be space-efficient? Any other reasons?

---

I'm not convinced that templates are the horrible bloat-monsters that they get portrayed as. On the principle that you don't pay for what you don't use, then the mere existence of a template won't bloat code, and if you only use one function from a templated class, that's the only function that the compiler will expand from the template - which may be an improvement over writing separate versions of the class. On the assumption that if you're going to use the template, you would have written it longhand, anyway, I don't see how templates are worse than what you would have written. On the other hand, if you would have written something a bit less type-safe (so as to use one function where two or three would be better), then templates are encouraging you into better programming practices.

Anyway, this is all just gut feel and I have no data to back it up, but then I've seen no data to back up the code bloat theory, either (not that I've really looked).

As such, my preferred solution to the problem raised would be:

Code:

---

  template <typename T>
  struct myStruct
  {
    CString strVal;
        T*vdptrVal;
  };

---

actually, it would be:

Code:

---

  template <typename T>
    struct myStruct
  {
          std::string sensible_name_for_string_member;
          T* sensible_name_for_pointer_member;
  };

---

where you can substitute something appropriate for the "sensible" names. I might keep the CString if the struct was directly associated with MFC classes, otherwise, I'd use std::string and convert to CString as late as possible. Plus, I detest Hungarian warts on variable names.

Quote:

---

Originally Posted by Graham

I'm not convinced that templates are the horrible bloat-monsters that they get portrayed as. On the principle that you don't pay for what you don't use, then the mere existence of a template won't bloat code, and if you only use one function from a templated class, that's the only function that the compiler will expand from the template - which may be an improvement over writing separate versions of the class. On the assumption that if you're going to use the template, you would have written it longhand, anyway, I don't see how templates are worse than what you would have written. On the other hand, if you would have written something a bit less type-safe (so as to use one function where two or three would be better), then templates are encouraging you into better programming practices.

---

I completely agree to this but you talked about the comparison between thin templates and (what i should i call) regular templates. I think you would agree upon the improvement though (caused by thin templates).

Quote:

---

Originally Posted by exterminator

I completely agree to this but you talked about the comparison between thin templates and (what i should i call) regular templates. I think you would agree upon the improvement though (caused by thin templates).

---

Not necessarily - and for much the same reasons I gave for regular templates over non-templates. Again, I've not done any studies on this - it's just a gut feeling, so could easily be wrong.

My guess is that where a thin template might show an improvement is if you are going to have something like a collection of pointers, where you could create a vector (say) of void* pointers then cast them to the type the pointers really are, but to make the code typesafe, you instead are using templates.

Now, the question is what the compiler does. (In the real case of vector it doesn't have to be a vector of pointers, so we can assume here that the compiler has little choice).

If we have 20 different types and are going to use our vector< T* > on all 20 types calling the most common functions, is our compiler going to generate 20 different versions of vector or 1?

So that, I guess, is the basis behind a thin template (one set of generated code). Now I'm not sure exactly how you implement them.

Here's a (very) simplified example:

Code:

---

class arraybase
 {
 public:
        // stuff
 
 protected:
        void* arr;
 };
 
 template <typename T>
 class array : public arraybase
 {
 public:
        T& operator[](int index)
        {
                return *(static_cast<T*>(arr) + index);
        }
        // more stuff
 };

---

I still don't see how this is an improvement over moving the pointer into the templated class and making it a T*.

And can I just say that I work with Symbian - I don't defend it. Needs must and all that; I don't have to like it particularly.

Quote:

---

Originally Posted by NMTop40

If we have 20 different types and are going to use our vector< T* > on all 20 types calling the most common functions, is our compiler going to generate 20 different versions of vector or 1?

---

You'll get 20 different versions because the function signatures will be different for each type.

Code:

---

void vector<int*>::push_back( const int* &val );
void vector<char*>::push_back( const char* &val );

---

The compiler views those each as unique functions, even though the generated code may be identical given that a pointer is the same size regardless of its declared type. If it was vector<int> and vector<char>, then absolutely you would have multiple versions of the code because the size of each type is different.

The code bloat problem comes from the fact that templates are expanded inline. That means each compilation unit gets its own copy. So if you use those 20 different versions of vectors in 3 different source files, then you'll have a total of 60 copies of the code. That is the code bloat problem of templates. Or at least that's the way it used to be; newer compilers may be able to eliminate the duplicate code. I thought I saw that mentioned somewhere here on CodeGuru.

I've used the pattern shown by Graham above, where there is a non-template base class that performs as much type-independent processing as possible. Then a derived template class provides the code that is type-dependent. The intent is to minimize the amount of code that is duplicated as a result of template expansion.

For example, if all of the type-independent code can operate with void pointers, then most of the code would be in the base class and the template class would just provide methods to cast to/from the real data type, i.e. it would be very "thin". Maybe that's what the term "thin template" refers to? I don't know, I've never heard that term before.

Well I do work a lot with smart pointers, which always contain pointers, never objects, so they are generally the same size, and they do point to different types.

Perhaps I should try some experiment with thin templates, although where I work the code size is not a major issue (unlike on mobile phones where it is a much bigger issue).

Quote:

---

Originally Posted by Graham

As such, my preferred solution to the problem raised would be:

Code:

---

  template <typename T>
  struct myStruct
  {
    CString strVal;
        T*vdptrVal;
  };

---

actually, it would be:

Code:

---

  template <typename T>
    struct myStruct
  {
          std::string sensible_name_for_string_member;
          T* sensible_name_for_pointer_member;
  };

---

---

Sorry for the delayed response was not online all these days.. here in the above suggested case how do i use this struct template with vectors, like i want to use this vetor of this struct template.
like

Code:

---

vector<myStruct> vectStruct

---

Quote:

---

Originally Posted by Graham

I might keep the CString if the struct was directly associated with MFC classes, otherwise, I'd use std::string and convert to CString as late as possible. Plus, I detest Hungarian warts on variable names.

---

Yes i am associating this with MFC so i am using CString.

thanks for the suggestion
venky :thumb:

Quote:

---

Originally Posted by santoct2002

Have you anytime heard about VARIANT type?? variant data type is used to extensively in COM programming. This may help you to hold different data type value. but It needs some considerable time to spend on this datatype to use your requirements, that I leave it to you. You can get more details in MSDN and in Codeguru also. Search for Variant.

Variant

---

There's also Boost Variant and Boost Any with included usage examples.

Quote:

---

Originally Posted by venkyhyd

Sorry for the delayed response was not online all these days.. here in the above suggested case how do i use this struct template with vectors, like i want to use this vetor of this struct template.
like

Code:

---

vector<myStruct> vectStruct

---

Yes i am associating this with MFC so i am using CString.

thanks for the suggestion
venky :thumb:

---

Code:

---

vector<myStruct<myType> > vectstruct;

---

Note the space between the two '>' characters - this is very important.

Variants are useful for when you have a collection of fields which may be of different types but you want to treat them as a whole. For example, a generic record of a database, which is a collection of fields of different types.

boost::any works with a common paradigm used in C++ (not sure if it has an official design pattern name) whereby you have a single base-class and from there you derive a template. (That pattern was used above). The base class has methods that are expected to have some meaning for any types that might be held, eg streaming.

This is a way to make all your classes derive from one common base class even when they don't.

I haven't looked at boost::variant in detail.