Do I use std::vector<void *>?
Thanks
Jack
Printable View
Do I use std::vector<void *>?
Thanks
Jack
No, you change your design such that you don't need a god-object.
The equivalence is std::list<myBaseObjectClass&>
but there is probably a better design approach altogether.
I better off redesign my program. Let me have a good thought about it
Thanks
Jack
List in Java is an interface. The two most common concrete implementations of List are ArrayList and LinkedList. The first corresponds with std::vector and the second with std::list.Quote:
Originally Posted by lucky6969b
The notion of a top class doesn't exist in C++ but one could think of void being such a class and then void* is pretty close to a reference to Object in Java (although void doesn't have any methods).
So std::vector<void*> of C++ corresponds very well with ArrayList<Object> of Java.
Anyone writing code that uses std::vector<void*> (or std::list<void*> or anything like this) that comes across my desk had better keep walking towards the exit.:thumbd:
As others have correctly pointed out, this is a design problem which needs to be re-thought.
Do they have desks at McDonalds now? Is it to raise the status of burger flipping? Just kidding, but you're jumping to conclusions. Did you see a design? No? So how can it be bad?Quote:
Originally Posted by 2kaud
There's nothing inherently wrong with std::vector<void*>. That, or something similar, is what you can expect to find in low level C++ designs when you can't or don't want to make assumptions about type.
Maybe the OP realized he couldn't access hardware in Java and is now looking to do it in C++. And up pops a bunch of besserwissers yelling bad design. Lucky you to have a desk to hide your red face under. :)
Nothing wrong with it other than turning something most likely caught by a compiler into a runtime error. Unless you're used to program C with classes, you can restructure to get rid of the void*.Quote:
Originally Posted by razzle
And sometimes even if you're used to object oriented C++ no amount of restructuring can factor out a downcast. You simply have to deal with "a pointer to an unknown type" (the C++ Programming Language 4'th ed. by Stroustrup p. 172).Quote:
Originally Posted by Arjay
Lets face it, C++ is a versatile language and one of its strengts is that it allows you to program without contraceptives (at your own discression). Otherwise why don't we all switch to Java?
--- doubleposting by mistake ---
I agree that use of a void* pointer is sometimes useful and sometimes cannot be avoided. The point I was making clumsily (after a bad day :eek:) was that I wouldn't expect to see containers/arrays of this type.
PS McDonalds do a good medium-rare flame war :D - and no, I couldn't hide under the desk as there's too much kit there.
Sure, there are always rare cases, but most times you need a pointer to an unknown type about as often as you need a goto. For some, that's more frequently than others.Quote:
Originally Posted by razzle
You're allowing yourself a superior and condescending tone.Quote:
Originally Posted by Arjay
If you're such a genious why don't you enlighten us mere mortals as to why anyone should select C++ over Java if it isn't for the versatility of the former (and legacy is no issue)?
And does your oppsition to goto also include break in loops and return not at the end of functions? Should these also be used as rarely as void* in your view?
And while you're at it. What would you suggest to better correspond to ArrayList<Object> than std::vector<void*> ?
I only use that tone when working at McDonald's - a nod toward your previous superior and condescending comment:Quote:
Originally Posted by razzle
Btw, ever notice the irony of folks that condescendingly refer to others as geniuses often misspell the word when doing so?Quote:
Do they have desks at McDonalds now? Is it to raise the status of burger flipping?
It does, except that primitive types in java do not derive from Object, and would have to be wrapped.Quote:
Originally Posted by razzle
If void* was God, then Object would be no better than Jesus I guess.
So you feel superior indeed.Quote:
Originally Posted by Arjay
Interesting. I thought your tone was unintentional.
But then reply to the questions I asked you in my previous post if you dare and I'll cut you to size. It's a promise.
Yes, but this "wrapping" takes place automatically in Java by way of so called boxing/unboxing. It's a coersion polymorphism that's part of the Java language.Quote:
Originally Posted by zerver
So it's trinity that makes void* and Object the same in spirit. :)
Chill out, razzle. From your previous post in the thread, you don't seem to mind taking the superior tone. Or perhaps it was unintentional?Quote:
Originally Posted by razzle
First of all, List<Object> is kind of bad design itself, so you're absolutely right about redesign thing. Object is too much abstract interface, and I would expect it be more a trouble than a benefit.Quote:
Originally Posted by lucky6969b
Besides, C++ is not Java, and therefore is not obliged to provide semantically equivalent constructs to what Java developers got used to.
I don't know Java, but I suppose a List<Object> implies some form of lifetime management of its owned "objects", and I suppose a Java programmer can always use reflection to "cast" an Object to its actual runtime content, doesn't it ?Quote:
Originally Posted by razzle
Conversely, the only thing you can legally do with a void* is essentially to cast it back to its original typed value ( so you cannot even delete a void* ), a vector<void*> is not quite the same thing as a type erased list of objects, it's essentially just a vector of scalar values suitable to represent memory locations, not much more I think.
better alternatives ( modulo usual good design recommendations ) could be vector<shared_ptr<void>> ( which perform true type erasure allowing lifetime management ) or vector<my_smart_ptr<MyBase>>, as OReubens already suggested, or vector<boost::any<MyConcepts>>, vector<boost::variant<...>>, etc ...
BTW, IMO vector<void*> should be a last resort in "low-level" container programming too, because erasing type information inhibits compile-time optimizations, makes dubugging a pain in the ***, etc...