Quote:Original post by Anonymous Poster
Switch to STL.

Statements such as "switch to STL" are exceedingly annoying. Give me an intelligent response, with intelligent reasoning. You gave no reasoning. "You can only have 2 of elegance, safety, and efficiency." If this is your reasoning, you forgot to specify which 2 STL is (and even if you had it would have been insufficient).
If STL is safety and efficiency, perhaps I prefer elegance and safety?
Please, give me a good reason why I should spend the next week revamping my game to use STL rather than spending 5 minutes implementing a new constructor.

With varargs, you'd still have to pass the number of parameters to know how many they passed. There is no good solution to this really. Using a function that returns a reference to 'this' and chaining calls is probably the best solution.

Well, you could do function overloads like make 15 versions of MakeArray that each take a different number of arguments (for 1-15), so it would only accept the proper number of the proper type.

Edit: Fruny said it wouldn't work so I deleted the guesswork code and made the idea really simple =-)

Quote:Original post by Erzengeldeslichtes
That's the same thing as option 2, except not in a single line. With option 2 I could do Array(3, {new bar, new bar2, new bar3}); and have exactly the same result except with my array.

Why do you even bother considering 'options' which are illegal? There is no such thing as an array literal.

Quote:Of course the downside with the overloaded operators is that it then only adds one at a time, requiring the most number of resizes, wheras with varg I'd be able to get the number of elements (I think), size it to that, and add them.

No. Varargs require you to, somehow, tell the compiler when the end of the argument list is reached. printf does it simply by counting the placeholders. Another option is to end the list with a null pointer (as the argv array is).

If you're worried about performance, add an initial parameter that calls std::vector::reserve(). All that an incorrect parameter costs you is some time - you won't have any correctness problem.

Quote:Same deal with static array, I size it to the size you give me and then copy that many from your static array.

Except you still have to find that size, somehow. There are template tricks you can pull to make sure a genuine array is given as parameter (yes, in two steps) and find the number of its elements.

[quote[If I were to switch to std::vector I'd still have to either create a wrapper or derive a new vector because I have functions in the array that work on the members of the array (as I said, it's specialized for my types)

What's wrong with creating wrappers?
STL containers are not designed to be inherited from.

Quote:Original post by Anonymous Poster

Dude, you can only have 2 of elegence, safety and efficiency. Switch to STL

You can have all three, though making code elegant from the user's point of view often requires much work from the implementor's point of view.


Extrarius - You've done function overloads, not template specialisations. I don't think that'll work as you want it to.

Quote:Original post by Fruny

Why do you even bother considering 'options' which are illegal? There is no such thing as an array literal.

Oh, is it illegal? My bad then. It would then need to be done in 2 lines:
Object* Arr[] = {new bar, new bar2, new bar3};
Array(3, Arr);

I had thought of the overloading, but I figured there had to be a better way then that.

However, I have used vargs before and I could have sworn that I was able to get the number of variables without providing it, though it's been a while so maybe I've just forgotten.
Edit: After testing out the vargs, you're right, I can't figure out the number without using either putting a 0 at the end or providing the number.

[Edited by - Erzengeldeslichtes on September 19, 2004 9:42:10 PM]

Quote:Original post by Anonymous Poster
Yep, but have you downloaded Alexandrescu's flex_string? It's long, real long. So long you could cut it in half, half again and half once more and it's still be long. Real long.

Doesn't look too bad to me.

This is a policy-based design, with four different storage policies (SimpleStringStorage, AllocatorStringStorage VectorStringStorage), two optimization storage adaptors (SmallStringOpt and CowString), and the flex_string itself which merely implements the requirements for a standard C++ string class.

I don't understand what you feel is wrong with that.

Quote:Original post by Anonymous Poster
It's long. More precisely, the flexibility of this design increases the amount of code.

That doesn't make it any less elegant in my eyes.
Elegant != über-clever hack that fits on one line.

Each of the Storage policy class stands on its own, if you only had a single of those, you wouldn't really have much more code than the standard std::string class (which does rely on an Allocator class).

The extra code really is a language characteristic : C++ does require a certain amount of scaffolding around the "core" of your code.