Your opinion on the functionality of a template dynamic list

[Joshua Flynn]

O(n) is worst-case and O(1) is best case, compared to my own class which is O(1) worst-case and O(1) best case.

Still, you should check with a profiler, if this worst-case O(n) is really a bottleneck and deserves spending so much time on it.

It does. List classes become highly useful when loading files (either in text mode or binary mode), because it's a reported problem using ftell may not accurately return the size of the file (the details were a bit sketchy, but what size the file is depends on which mode (text or binary) it's in). Apparently relying on this caused users issues so I wanted to bypass that altogether - just load the characters via fgetc, whilst counting how many there are in a list.

However, the list needs to be converted into a (dynamic) array, and walking a list of 89000+ is not pleasant. Especially if I plan to load bigger files or more of them. So a definite O(1) is required.

It's not whether or not it's a bottleneck now, but whether or not it will be a bottle neck later on.

Readability is not the exclusive criterion, nor should it really be expected in coding

I strongly disagree with you here. Readibilty is a very important criterion for maintainability and thus should be expected in coding. After all, others are supposed to read your code, too.

Very important criterion in maintainability yes, but code does not always have the benefit of being readable (hence comments, and programming courses), of which assembly is one such example. One cannot push the 'easy to read' element too far, otherwise code performance can suffer.

For example, a coder might complain the bitwise operation/function is not easy to read (?) but if it's the only way of achieving the solution there isn't much point.

If it's any reassurance. I look at other programmer's code/hacky methods and my eyes glass over. Comparatively, the code I'm writing is fairly clear cut (on the lower levels) as to what it is doing (with the help of the occasional comments to clarify specific functions).

It's not explicit - that's the problem.
It's implicit, that "Queue = ImageLoader" appends the image to the image queue.

Given Queue is of a type ImageQueue, it's obvious it queues images. Which means there is only one logical order for it: FIFO.

After all, it could also prepend or insert in the middle.

Not sure why it'll prepend (If you're thinking of LIFO, that's a stack, not a queue). And inserting in the middle is not even logically possible (where's the 'middle' for the first and second item?), even if it was, one would have to ask how that is a queue?

The same goes for overloading the ++ and -- operators. They don't have an intuitive meaning for lists and should thus not be overlaoded.

I'm more of the opinion they should be overloaded even if they aren't going to be used to supply that functionality down the line.

Is there any special reason, why you don't want an STL-like interface?

It's not intuitive enough. Ironically. I can't just pick it and use it, I have to do groundwork research on how they operate. Whilst you'd might say about research is a good practice, it really hinders learning curve. I'll build my tacky classes, once they're set, I'll release them with example code for review and feedback and see what people think of it.

One of the aims is to be able to add such functionality that I could create software with a decent GUI using SFML within a day. I know some coders can write weird code that pulls this off, but I'm a 'zoned out monkey coder', so I want to be able to write straight-forward calls like those above.

[Disch]

Point was, you can merge functions into one where applicable.

It's a maintenance thing.

My point was, there are things you can do with separate get/set functions that you can't do with an all-in-one get function.  The opposite is not true.

Hence, it limits your implementation.

If your particular implementation should happen to work into an all-in-one interface, then yeah you can combine it.

However, should the implementation need to change in the future (due to additional needs, or a change in overall design, or whatever), it might be difficult/impossible to keep the all-in-one function.  Which means you have an API break, which means you have to rewrite not only the class, but all code that uses it.

So yeah -- it's something to avoid.

you'll like the assignment operators.

As long as they make sense conceptually and aren't simply a way to avoid typing out a function name, then I'm fine with it  =P

Exceeding it's capacity (or changing it's size) is a resize.

But see, exceeding it's capacity or changing it's size are two different things, which I'm not sure you're grasping.

A vector may only have 10 elements in it, but will have space allocated for 20.  (ie:  a size of 10, a capacity of 20).

You can add and remove any number of elements to the end of that vector without needing any reallocation, until you exceed 20 elements, at which point, the capacity needs to be increased and the memory reallocated.

See std::vector::reserve and std::vector::capacity.  They're different from std::vector::resize and std::vector::size.

Aside from a hat-tip to realloc,

realloc causes complex types to explode, hence why it can't be used in such a class unless you limit that class to contain POD types only.

my point is it needs to copy less frequently rather than not at all. Latter statement is true, but classes shouldn't have the capacity to be used wrongly.

vector actually makes an effort to "guess" as to how much capacity you need in anticipation of future growth.  Yeah, it will get it wrong a lot, but it's pretty much impossible to get it right all the time (or even a high percentage of the time).

As for being able to use a class wrongly -- that's where the performance-vs-safety issue comes in.  Although in this case we're not really talking about using vector "wrong", just "inefficiently".

Optimisation usually requires you re-write the foundation code in the first place

I don't know about "usually".  Sometimes, yeah.

But we're not talking about ripping apart and reoptimizing an entire program, here.  We're talking about replacing one linked list with another.  They're both going to work more or less the same way, so really there's no reason why they couldn't/shouldn't be interchangable.

I find it better to optimise first. More specifically, write short example code to test assumptions, if assumptions wrong, update, if assumptions correct, expand, clarify, incorporate.

I find that optimizing is a very small part of the actual work I do on a project.

I keep it in mind when designing to avoid doing things that are obviously slow or wasteful, but other than that I just run with it.  Running into performance issues that actually needed to be seriously addressed afterward is actually quite rare.  C++ is fast.

Bear in mind I type like a zoned out monkey when it comes to code.

I guess I just assumed everyone is as occupied with real life as I am sometimes.  =P

Actually, combining both gives you the best of both worlds, fast insertion, with random access [snip]

it's more intended you add a load of items, access them at random, do some work, access it at random, then add more items, repeat.

I guess I'm just having a hard time seeing how this would be useful.  Your example at the end of your post didn't make a lot of sense to me.  Why would you need to access images randomly?