Thread: What would be the best way to name these typedefs?

Originally Posted by whiteflags

It's nice that you state that as if it were a fact. Attention toward the actual type I pointed out, please? Variable declarations are the among the longest things you can type in C++, (all that scoping and template instantiation in "my heavily templated code") and among the longest compared to any other language.

I'm having trouble assimilating what you are saying. AFAIC, you're example to the contrary (list_of_strings) is a meaningful name, because I still need to know the type. Typedef is not a variable name -- it is a "type definition", or, if you prefer, a type alias. It doesn't matter what you use an alias for, because you would only use them to shorten long declarations. There is really no other reason around.

There is simply no, or little benefit, to use list_of_strings instead of std::vector<std::wstring>. All you do IMO is obfuscate the fact.
For insanely long types, typedefs are necessary. But again, if you try to name the typedef after your type, it too, would get insanely long.

Example:
typedef std:air<StringVector, BoolDeprecatedBoolPair> StringVectorBoolDeprecatedBoolPairPair
What does this typedef add? It clearly just mimicks the name of the type, making it just as long.

typedef std:air<StringVector, BoolDeprecatedBoolPair> SVecBoolDepBoolPairPair
This is shorter, but obfuscated. What is S? What is Vec? What is Dep?

If you instead name it for what it will be used for, like looking up user agent or something, it might look like
typedef std:air<StringVector, BoolDeprecatedBoolPair> UserAgentLookup_t
Much shorter. Yet it describes much more closely for what it will be used.

Originally Posted by kmdv

It's one of the worst thing you can do IMO. I don't say I don't do it at all, but you can replace something you didn't want to.

for example:

Code:

std::shared_ptr<deque<std::string> > var1
deque<std::string> absolutely_not_related_to_var1;

I know what you mean, but there is also something writing too many typedefs. Too much of things can obfuscate. There is a fine line. I just prefer not to write typedefs that mimicks the type.

Originally Posted by Elysia

There is simply no, or little benefit, to use list_of_strings instead of std::vector<std::wstring>. All you do IMO is obfuscate the fact.
For insanely long types, typedefs are necessary. But again, if you try to name the typedef after your type, it too, would get insanely long.

There is a (not so little) benefit and not with list but with deque. With vector you should be careful about reallocations. With deque you don't care about it. Why would you still want to bother with vector then.

Originally Posted by Elysia

Example:
typedef std:air<StringVector, BoolDeprecatedBoolPair> StringVectorBoolDeprecatedBoolPairPair
What does this typedef add? It clearly just mimicks the name of the type, making it just as long.

You are right, as I have already stated he should give a name related to what it is actually doing. I posted this typedef as an example of naming convention. It should be: StringVectorAndBoolDeprecatedBoolPair.

typedef std:air<StringVector, BoolDeprecatedBoolPair> SVecBoolDepBoolPairPair
This is shorter, but obfuscated. What is S? What is Vec? What is Dep?

Please burn this typedef.

Originally Posted by kmdv

There is a (not so little) benefit and not with list but with deque. With vector you should be careful about reallocations. With deque you don't care about it. Why would you still want to bother with vector then.

How about contiguous memory layout? Faster access? Less memory overhead?
If deque was as good as you pointed out, there would be no need for a vector.
But such is not the case. All containers have different strengths and weaknesses.

Originally Posted by Elysia

How about contiguous memory layout? Faster access? Less memory overhead?
If deque was as good as you pointed out, there would be no need for a vector.
But such is not the case. All containers have different strengths and weaknesses.

laserlight has already written what I meant, in a clear way. String operations take pretty much time and benefit of accessing vector's element does not outweigh benefits of deque semantics. For strings of course.
Not to mention that contiguous memory has also its disadvantages.

Again, what string operations? If the vector needs to reallocate, it matters not whether it's a string or T.
The vector works with bytes. It allocates room for N elements of type T. Then it just copies all of those bytes over to the new range, so it makes no difference if it's T or a string. It only matters how big the type is.
But then again, the allocations are amortized constant, so you don't get a lot of reallocations. And the bigger the size of the vector, the less reallocations you get.

Sorry, but unless I find it to be a bottleneck, I'm sticking with vector.

Originally Posted by whiteflags

Vector if you need it. And be sure that you need it, instead of only random access: they are not the same. deque only breaks trying to access elements by pointer arithmetic.

Which, by definition, means that random access in a deque cannot be as fast as in a vector.

The difference is negligible. It is still constant time.

Constant time is a convenient term when comparing algorithms, but is only good for a starting guess. I can easily write two different algorithms with the same Big-oh time, but one radically faster than the other.

Memory layout for deque actually improves "memory overhead" unless you actually possibly mean "less space" which I am not sure is true. By memory overhead, I am assuming that you mean that when deque needs to extend itself, you will incur a cost in overhead greater than vector's cost. This is not really true. deque will never need to reallocate when it extends itself. It stores everything and allocates in blocks. Since memory does not need to be contiguous, you will never have to copy elements into new bigger places. That is a performance cost, overhead, that you could only mitigate in vector with reserve(). It doesn't work so well in an area where expectations are unclear.

Like storing a bajillion primes.

I meant the number of bytes of data the container needs to contain aside from the data to make it work.

Acknowledge them please and "be sure you know what you are doing, don't just jump to vector containers." After all:
If vector was as good as you want it to be, then there would be no need for deque.

Then again, what does the standard state about deque? That it has faster insert and removal at the end and beginning? And that operations are the same Big-oh as for vector?
This does not guarantee that it will be faster on memory allocations. And even if it were, wouldn't it still be... O(cN), where c is a constant? Oh, but that's the same as O(N), which is the same as for vector.
Therefore, this is not good enough for a starting guess. There is absolutely no need to jump over to a deque over a vector because you're using strings.
The same argument holds if you're using deque as your standard container. No need to jump over to vector for ints.

Stick with one, or better yet, time which is better for your application.

Originally Posted by Elysia

Again, what string operations? If the vector needs to reallocate, it matters not whether it's a string or T.
The vector works with bytes. It allocates room for N elements of type T. Then it just copies all of those bytes over to the new range, so it makes no difference if it's T or a string. It only matters how big the type is.
But then again, the allocations are amortized constant, so you don't get a lot of reallocations.

Sorry, but unless I find it to be a bottleneck, I'm sticking with vector.

Comparison (N), copy(N), find substring (N*M or N+M), nearly every operation which comes to my mind is at least N.

I will not be arguing about advantages and disadvantages of contiguous memory. For me deque fits better for general-purpose string container.

Unless I find accessing elements a bottleneck, I'm sticking with deque.

Originally Posted by kmdv

Comparison (N), copy(N), find substring (N*M or N+M), nearly every operation which comes to my mind is at least N.

I don't see deque doing any better, though.

I will not be arguing about advantages and disadvantages of contigious memory. For me deque fits better for general-purpose string container.

Unless I find accessing elements a bottleneck, I'm sticking with deque.

Best thing I heard all day!
That is exactly what I wanted to hear. Don't switch container unless you can a) guess it's better in a given situation and b) prove it.

Originally Posted by kmdv

Comparison (N), copy(N), find substring (N*M or N+M), nearly every operation which comes to my mind is at least N.

Obtaining the string length and accessing an element by index are in O(1). But my point is that most of these, including comparison and obtaining a substring are irrelevant to the matter at hand, so you should talk about string copying, not about string operations in general.

Originally Posted by kmdv

For me deque fits better for general-purpose string container.

Unless I find accessing elements a bottleneck, I'm sticking with deque.

Did you really find the occasional reallocation due to expansion of vector to be a bottleneck, in general?

Originally Posted by whiteflags

I don't know what you mean to say by this, but we are comparing algorithms here, and I am using it as a starting guess, and you are implying that the difference is not negligible.

What I mean is that Big-oh time is not the same as real time.
Take a vector and linked list an example. Insert an element at the end in both containers. Both as O(1), but the vector is radically faster, nevertheless.

But no, I'm not appreciating how you're implying I'm actually advocating something like replacing vector with deque at all times. If you're going to demand things from me, like profiler digests, then at least ask for them in an appropriate time. I don't think we've reached that time today.

You seem to forget that I am not writing these programs. Don't direct such things to me.

Erm, so let's take a different approach. So what are arguing about?
I am arguing that you shouldn't jump over to a deque over a vector simply because you are using strings.
I am arguing that you must have a reason for it, such as inserting at the beginning of a vector.

Originally Posted by whiteflags

Let me ask again, as directly as possible. Are you saying that deque's random access is radically slower than vector's? Are you sure that is a question you can answer without data?

Can I for sure? No.
Can I make an educated guess? Yes.
Is it radically slower? I don't know. Is it slower? Yes, probably. By how much? I don't know.

Do you have such an enormous problem with me, and other people, enumerating other reasons for a switch?

I'm neutral in that. I don't have a problem with most people. There is but one, and that someone appears gone. Or I just cannot detect his/her presence.
I was simply chiming in the fact that you shouldn't switch containers based on a hunch. But it seems it needlessly escalated, unfortunately.