An actual STL design question!
Since this seems to be the most active thread for STL issues (though my question has nothing to do with MFC) I'll post this here.
Also, it is very similar in challenge to Toxick's string class that led us down the current thread path.
I need a vector with that can never violate the property that it contains only N <= x <= M (0 <= N, M <= INF) elements and vectors with differing N and M's are still of the same type.
1. I thought about using Allocators, but...
* Allocators can't/shoudn't have non-static members (N & M)
* Vector controls the number of elements requested, all the allocator could do is throw() - it's impossible to make N=x=M for some arbitrary x because vector is going to ask for whatever its growth strategy determines
* Avoiding the first bullet with static data makes vectors with different N&M's need to be of differing types (because they'll have to use different allocators)
2. We've been down the inherit from vector road already
3. So, its encapsulation. We wrapper up vector and provide an identical public interface of typedefs and forwarding functions accept for the ones that mutate vector. With these we have to check the constraints and throw or forward as necessary.
Note that the new class will not be STL compilant because now swap() can throw and the standard does not allow this.
My question now is about the iterators. If the wrapper simply provides the member vector's iterator - can a client mutate the vector?
It would seem to be no - because often vector's iterator type is T* but it doesn't have to be. And nowhere in the standard does it say that a mutating iterator has to use a class's public interface.
I'm a bit rusty on iterators so if I'm wrong on this please correct me (that's why I'm posting).
My fear is that it is possible that I make the member vector's iterators accessable - these are converted to a mutating iterator (insert_iterator, etc) which directly mutate the member vector (via private reference in the iterator) thus bypassing my wrapper.
So, is any of this possible? Can fix it by providing my own iterator that embeds an member vector iterator?
Last option of course is to roll-my-own (which I'd like to avoid).
Oktronic, Paul: Please take the flame war elsewhere!
No one is an expert on everything. Everyone here is on their own path. Some are farther ahead than others and should help those who want to catch up. The only people who are lost are the ones who think they know where they're going.
I'm not Paul's buddy, I'm not your dad, and I'm certainly not the moderator. I'm a newbe to this forum - and right now I'm trying to figure out if I wasted two days participating here.
You don't like Paul - fine. Ya wanna bash his experience? - fine. Just don't do it here. Stop wasting my time.
Paul's posts were well thought out and presented professionally. He did not denigrate anyone. His only mistake was being wrong (who isn't every now and again). I didn't have a problem with any of his posts. Everyone here is entitled to have and express their own opinion.
If you really have people like Paul working for you, I hope you have more courtesy and professionalism with them than to chastise them in a public forurm. If not, then I certainly would not want to work for you. My people are my most valuable resource. I treat each one with care and respect.
If you're really bent on making it a pissing contest then don't hold back. Whip it out there! Me? My code has toured the inner solar system. My code has driven across the surface of Mars (and come January I'll be there again).
Think I'm experieced? Guess what? I don't. The more I do the more I discover that there are so many things I don't know. Whether standard, book, article or forum - everyone can teach - everyone needs to learn. I expect to learn something new from each person here in every thread I read. If I don't, I'm just wasting my time.
I'm not trying to impress you and I don't need your friendship. Those things don't put gas in my car or code in my repository.
Now, I've posted a serious STL-related design challenge. If you or Paul want to *demonstrate* your technical skills instead of debate them - then post a reply. Otherwise, I'd rather not waste my time being here.
Re: Oktronic, Paul: Please take the flame war elsewhere!
Going back to your question. It is interesting, and I've been thinking about it. Haven't concluded what to do with it yet. I'll get to you what I come up with when I get some rest, work on my "non real-world" projects, and answer a few e-mails sent by customers of products that I have created (yes, customers -- who could have thunk it, knowing that I use STL ;).
Originally posted by mclark
When I'm wrong, I admit it (thanks to Mr. "'Tox" for setting me straight). Actually, it was an oversight on my part, knowing full well that deleting using the derived class as the base is perfectly legal. I must have had a brain-freeze or something.
But getting back to some points you made:
I don't know everything, no one does. There are some topics in C++ where I do not have that much experience in using. Topics such as template meta-programming (which galathaea seems to be an expert on), I don't comment on too much, because I've never used it to any great extent. (Is it just a rumor that the template meta-programming was first discovered by some daring C++ programmers who said "what the heck -- let's see what happens when we do this trick with the templates.....Whoa!!").
This is the same with many aspects of Windows (with the exception being the base Windows API). Active-X? Never had to create an Active-X control, so I can't (or shouldn't comment) on what I think of Active-X.
If you and others have read my posts, you know that the topics that I stick to are not broad -- C and C++ language issues, some Windows issues, the odd Linux/Unix question, and that's it. Again, mostly answering questions, not "debating". I don't like to do the "debating" stuff unless there is something clearly wrong or not stated correctly.
But don't worry -- if others don't answer your question here, maybe you should repost in the non-Visual C++ forum. Others, such as Graham, and the crew here will come up with some suggestions.