To STL or not to STL, that is the question... - Page 9
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 9 of 19 FirstFirst ... 6789101112 ... LastLast
Results 121 to 135 of 280

Thread: To STL or not to STL, that is the question...

  1. #121
    Join Date
    Jul 2002
    Posts
    107
    for galathaea:
    The only thing that warrants an apology was the "big-boy" comment. While that expresses my opinion of this as childish, it doesn't belong in adult conversation. The rest were responses to what Paul had said. And I feel he has been far more demeaning to every response against STL in this thread, long before I responded. That's why I use the quotes surprisingly.

    for mclark:
    Brief response, I agree with 90% of what your saying.

    The standard says nothing at all about virtual tables
    Yes and no. Check the limitations in the standard.

    The C++ Standard is not about how you code things
    Again, Yes and no. ANSI is simply a request to make life easier for other programmers. While it doesn't tell you how to code, it does ask you to code your compiler to be nice to others.

    I don't know if Stroustrup would agree that the purpose of C++ is simply OO programming
    I'm sure he would say, the C++ is an OO approach to C. I suppose I can only guess at that, but the main construct of a C++ compiler is to turn C in to an encapsulated system. But honestly, it's about turnning programming back into a profession.

    I freely admit that I've never been a junior college professor
    Nothing wrong with that. Its a great place to do part time teaching while you work on other projects. Most students are adults looking for a trade which made it better then teaching kids.
    But I've done C and C++ and AC++ for fun while taking a project break.

    It would seem that these limitations are with the implementations you've used and are not inherent to STL as a definition
    This I disagree with. I have actually expanded template parsing to weed out some of the limitations. STL on the other hand, is nothing but limitation. I think the fact that an object requires external functions to operate on itself is a horrible concept and very poor design.

    And there you have it. Once again engineering digresses into religion.
    sad, but I think its getting that way.

    As for STL. Use it if you want. Again, you will find with experience that its use will open a door for very poor design. We see poor design every day in a multitude of programs hitting shelves. Programs that only run on developer machines and no where else, to name one. These things will only be learned through experience in language and programming industries.
    And since I can't argue your future experience, I'm not going to try.

  2. #122
    Join Date
    Sep 2002
    Location
    14° 39'19.65"N / 121° 1'44.34"E
    Posts
    9,815
    Originally posted by mclark
    OO (at least as preached by OMG and UML) contains both harmoniously. Parameter Polymorhism and Subtype polymorphism are both equal sibling refinments of the relationship between classes. OO embraces both. In C++ different language mechanics, styles and support communities have made these two less related than they should be. But from a design perspective they are unified.
    Now you are dragging the discussion to a more philosophical level, on the which you are right, of course. But the initial discussion suffered from the lack of understanding that there are two (or more) somewhat linearily independent concepts for implementing polymorphism in the actual C++ standard, and that's a reality we have to live with. I just wanted to point out that this was a source of common misunderstandings.

  3. #123
    Join Date
    Nov 2003
    Location
    Pasadena, CA
    Posts
    48

    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.

    So...

    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).
    The views expressed are those of the author and do not reflect any position taken by the Goverment of the United States of America, National Aeronautics and Space Administration (NASA), Jet Propulsion Laboratory (JPL), or California Institute of Technology (CalTech)

  4. #124
    Join Date
    Jul 2002
    Posts
    107
    SDK short for Software Development Kit. Is this the answer you're looking for? You never answered the question -- is the C-library an SDK? If not, why not? Are fopen(), fclose(), malloc(), free(), etc. SDK functions?
    Yes Paul, anything that doesn't exist inside the construct of a compiler is a external SDK. Again, pick up a book on compiler design then come and argue the semantics about it.

    And you have knowledge that I and others don't write "real programs"?
    not others, no, just you. Most of the posts in this thread have be quite intelligent.
    But I've worked with, taught, have working for me, people who act and talk, just like you. They're don't write real programs either. They do what task I give them.
    And while I'm sure you're offended, everything you have thrown in this thread is nothing more advanced or knowledgeable then a fresh college undergrad. You have an opinion on everything, yet have clearly shown me that you lack the experience necessary to form the opinion, so what do you do? You quote others work.
    You quote books people have written and standards. Why? Because you can't formulate the opinion on your own, because you don't have the experience. Plain and simple.
    You tell other people that they are wrong because they aren't following the rules in your books and standards. This proves to me that you are not a professional programmer. Solutions to complex problems require you bend the rules. C++ itself was required to bend the rules of C. STL was designed to bend the rules of C++. Yet you don't understand that. So I hold my statement to be true.
    This is my reason for my attitude with you…unlike the new programmers here, I have the experience to see through it, so yes, I will correct your clearly inexperienced comments, and if you come back and tell me or others they are wrong with conviction, when you clearly don't have the faintest clue, then expect a response from me or from another experienced programmer who will see you are wrong, which is probably why you are in these debates often.
    The object of these forums is to teach those who do not know. Consider yourself taught.

    PS.
    "we don't write real programs" and "when you step out with the big boys".
    That we, should be an 'I', I said at the top of the post that it was for you.

    And I've already apologized for the "big-boy" comment. That was incorrect of me.

    I've actually been a member here for a long time, longer then the year and a half, but I was gone a while and forgot my original name and password, not like a year and a half makes anybody a newbie to the forum as you suggest though.

    And again, nothing in this post is meant to be "mean", just explanatory. Please don't take any heart felt offense to anything I say or am implying as its not intended....sad...

  5. #125
    Join Date
    Apr 1999
    Posts
    27,422
    Originally posted by oktronic
    not others, no, just you. Most of the posts in this thread have be quite intelligent.
    I guess you didn't see souldog's post to your first post. But let him defend himself.
    But I've worked with, taught, have working for me, people who act and talk, just like you. They're don't write real programs either. They do what task I give them.
    Hmmm. Again assuming. Please refrain from assuming, because you know what assume does...
    And while I'm sure you're offended, everything you have thrown in this thread is nothing more advanced or knowledgeable then a fresh college undergrad. You have an opinion on everything, yet have clearly shown me that you lack the experience necessary to form the opinion, so what do you do? You quote others work.
    I only quoted the standard. That's it. Do you have a problem with that? That's the way I work.
    You quote books people have written and standards. Why? Because you can't formulate the opinion on your own,
    No, because the standard is where the rules are.
    because you don't have the experience. Plain and simple.
    Someone was banned here a few months ago -- most people that have been on this board some time know who I'm talking about. He was banned because he demeaned others on this board. If you want to take this attack to this level, calling me (and no doubt, will call others) "inexperienced" or "not real programmers", then this thread should be reported by the moderator.
    You tell other people that they are wrong because they aren't following the rules in your books and standards.
    Yes, I do, so what? Many others in the non-Visual C++ forum do the same thing. I dare you to go over there and say "they are not professional programmers".
    Solutions to complex problems require you bend the rules. C++ itself was required to bend the rules of C. STL was designed to bend the rules of C++. Yet you don't understand that. So I hold my statement to be true.
    I don't agree. You can solve complex problems, but stay completely within the rules. Template metaprogramming is complex, but it stays within the rules.
    This is my reason for my attitude with you…unlike the new programmers here, I have the experience to see through it, so yes, I will correct your clearly inexperienced comments, and if you come back and tell me or others they are wrong with conviction, when you clearly don't have the faintest clue
    Just reading the ANSI standard to someone, and you go postal. It looks like you didn't like that I disagreed with your comments on STL and MFC, so you took it as a personal attack. Why, I don't know. Is it because I took my time to answer you, and you didn't expect it?
    then expect a response from me or from another experienced programmer who will see you are wrong, which is probably why you are in these debates often.
    Projecting that others will give the same response as you have. Why do you keep doing this, this "projection" thing?
    99% of my posts here answer questions, not debate. Out of over 6,000 posts here, how many are "debates"?
    The object of these forums is to teach those who do not know. Consider yourself taught.
    You haven't taught anything, only preached.

    I will continue, if asked if "doing X is safe" or "is this valid" by either not saying anything if the subject is something I'm not familiar with, or respond by, yes, quoting standards, papers, giving small example programs, and possibly mentioning anecdotal experiences that I have had with the problem.

    Regards,

    Paul McKenzie
    Last edited by Paul McKenzie; November 21st, 2003 at 07:55 PM.

  6. #126
    Join Date
    Nov 2003
    Location
    Pasadena, CA
    Posts
    48

    Angry Oktronic, Paul: Please take the flame war elsewhere!

    (being polite)
    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.

    (being blunt)
    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.
    The views expressed are those of the author and do not reflect any position taken by the Goverment of the United States of America, National Aeronautics and Space Administration (NASA), Jet Propulsion Laboratory (JPL), or California Institute of Technology (CalTech)

  7. #127
    Join Date
    Apr 1999
    Posts
    27,422

    Re: Oktronic, Paul: Please take the flame war elsewhere!

    Originally posted by mclark
    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 .

    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.

    Regards,

    Paul McKenzie

  8. #128
    Join Date
    Jul 2002
    Posts
    107
    [QUOTE]Re: To STL or not to STL, that is the question...

    quote:
    --------------------------------------------------------------------------------
    Originally posted by darwen
    I hate the fact you can't use DEBUG_NEW with it to track down memory leaks.

    --------------------------------------------------------------------------------

    There's a whole lot of code that is not STL where DEBUG_NEW cannot be used. So that's strike one.

    quote:
    --------------------------------------------------------------------------------

    I hate all the std::blah blah stuff when there's classes in MFC which do virtually the same job but much, much nicer.

    --------------------------------------------------------------------------------

    OK. Go sort a CList. Also, std:: is called a namespace. Again, nothing to do with STL, but just basic C++. Strike 2.

    quote:
    --------------------------------------------------------------------------------

    I don't even like CArray.
    --------------------------------------------------------------------------------

    Why? It's MFC, isn't it?

    quote:
    --------------------------------------------------------------------------------

    However CPtrArray, CObArray and CStringArray are very, very, very useful.
    --------------------------------------------------------------------------------

    If you want all that overhead of CObject added to your classes, go right ahead. Most C++ programmers do not want their classes hamstrung being derived from CObject.

    quote:
    --------------------------------------------------------------------------------
    You can't inherit from any of the STL classes because they don't have virtual destructors so you can't for instance do nice things that you can in MFC like :


    code:--------------------------------------------------------------------------------
    class CServerNames : public CStringArray
    {
    public:
    CServerNames();
    virtual ~CServerNames();
    } ;
    --------------------------------------------------------------------------------

    where this class would load in all server names from wherever.

    In one line.

    Wherever you wanted to put it in the code.

    --------------------------------------------------------------------------------

    Let's see the code that loads everything in "one line". Just posting a class without any code is not very convincing.

    code:--------------------------------------------------------------------------------
    class CServerNames
    {
    public:
    CServerNames() { LoadNames(); }
    std::vector<std::string> AllMyNames;
    void LoadNames()
    {
    // Code to load server names into AllMyNames
    }
    };

    void foo()
    {
    CServerNames S; // I've just loaded all the names
    }
    --------------------------------------------------------------------------------

    I guess that's strike 3, but I'll keep going...

    quote:
    --------------------------------------------------------------------------------

    In an MFC environment I don't see any reason to use it. Ever !

    --------------------------------------------------------------------------------

    Go sort a CPtrArray, or CStringArray, or CList. You can't unless you write your own code. I can do it in one line of STL code using std::sort. Oh, you must have forgot, STL isn't just about containers, there are a whole lot of algorithm functions (such as std::sort) that work on MFC Array classes. Maybe when you need to sort your CStringArray or call a function that acts on each element of your CPtrArray, you will see for_each() and not know what it does.

    quote:
    --------------------------------------------------------------------------------

    I know my comments are very forward, but I'm invoking discussion.
    --------------------------------------------------------------------------------

    Looks like your trolling.

    Regards,

    Paul McKenzie
    This is his first post in this thread. Long before I got envolved. This is no less demeaning then anything I've said.
    Please feel free to read his post here and elsewhere. He constantly preaches and demeans people who ask for help.
    His usual response to a question is, "why aren't you using STL?. Most programmers use STL"

    This and others for expressing an opinion about STL?
    When you report my post to a moderator, make sure to include his, atleast I include examples of his ignorance so nothing I've said wasn't backed up.

    And feel free to read my first post here. It was just my opinion, then look at how he responded with stupid comments like

    I guess you are a 'C' programmer who learned C++ later, right?
    So yes, I'm going to correct his attitude. He doesn't have the right, or the experience, to overrule anybody's opinion, nor attempt to insult them. Or try to claim he has 20 years experience so people should listen to him, when comments like above clearly prove the contrary.
    So please, before you jump on me, read his post to other people and you can see why this thread ended up this way.
    Last edited by oktronic; November 21st, 2003 at 09:40 PM.

  9. #129
    Join Date
    Nov 2003
    Location
    Pasadena, CA
    Posts
    48
    Since we're all to busy flaming each other to actually talk about C++, I've off and answered by own challenge
    cross-checked it against the standard
    optimized the lower and upper vector bounds as a template
    wrapped them in a base class
    called it a day.


    If anyone was ever intrested I'm willing to post the code.

    For those who just want the executive summary: There was nothing to fear. You cannot get a container-mutating iterator (inserting iterator) without explicitly referencing the container. Since the true vector was encapsulated as a private member (with public forwarding functions) the user will be forced to reference the wrapper class. This in turn ensures that insertion calls will go to the wrapper class (whose whole purpose is to intercept calls that can change the number of elements in the vector). And so, we can freely export the vector's iterators as if they were the wrapper class's without fear that the user will somehow be able to modify the number of elements within the container bypassing the constraint checking of the wrapper.

    As for making the upper and lower bounds non-type template members:
    +I know the ranges at compile-time
    +Increases the speed checking the bounds during insertion & deletion

    As for declaring a base class:
    -Adds virtual function call overhead to size changing functions
    +(0 <= x <= INF) can be represented as a different derived class that is a pure wrapper around the private vector and so the compiler will optimize well.
    +I have to anyways cuz of details unrelated to the vector stuff
    The views expressed are those of the author and do not reflect any position taken by the Goverment of the United States of America, National Aeronautics and Space Administration (NASA), Jet Propulsion Laboratory (JPL), or California Institute of Technology (CalTech)

  10. #130
    Join Date
    Nov 2003
    Location
    Pasadena, CA
    Posts
    48
    Originally posted by oktronic
    So please, before you jump on me, read his post to other people and you can see why this thread ended up this way.
    Oktronic,

    Look, I'm not passing judgment on anyone. Paul's posts weren't always very nice - but at least they were still in the gray area. Your's crossed the line. You know it, I know it. But so what, feathers get ruffled. Lets just move on. I've already got plenty of enemies and tons of people to fight with without leaving my office. I don't want to do that here.

    Please, please can we just get back on topic - any topic.

    I think you and Paul should kiss and make up. If you don't - then stay away from each other. If you're going to fight it out - take it to some AOL teenie-bopper chat room. Just don't fight it out here. It's hard enough finding real content and thought out discussions on the morass that is the WWW.

    as an aside: I my experience years-of-experience means exactly crap. I know developers with +10, +15, +20 who suck (that's why their still developers). I know guys with +3 who rock all day long (and who will only be developers until someone gives them the chance to design their own show). Years of experience is much better measure of how long you've been breathing than it is of how good you are at your job. But that's just been my experience I'm sure others' have differed.
    Last edited by mclark; November 21st, 2003 at 10:14 PM.
    The views expressed are those of the author and do not reflect any position taken by the Goverment of the United States of America, National Aeronautics and Space Administration (NASA), Jet Propulsion Laboratory (JPL), or California Institute of Technology (CalTech)

  11. #131
    Join Date
    Apr 1999
    Posts
    27,422
    Originally posted by mclark
    For those who just want the executive summary: There was nothing to fear. You cannot get a container-mutating iterator (inserting iterator) without explicitly referencing the container. Since the true vector was encapsulated as a private member (with public forwarding functions) the user will be forced to reference the wrapper class. This in turn ensures that insertion calls will go to the wrapper class (whose whole purpose is to intercept calls that can change the number of elements in the vector). And so, we can freely export the vector's iterators as if they were the wrapper class's without fear that the user will somehow be able to modify the number of elements within the container bypassing the constraint checking of the wrapper.

    As for making the upper and lower bounds non-type template members:
    +I know the ranges at compile-time
    +Increases the speed checking the bounds during insertion & deletion
    Nothing wrong with the design that I see here. There are no mutating algorithms that I can think of that can be used to remove or delete elements, so you're safe if you expose the iterators and the not the vector object itself.
    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
    I'm assuming you mean different internal types, for example a MyVector<int, 1, 10> and MyVector<int, 1, 20>, where "int" is the internal type, and not different class types.

    When you create a template, you are creating a different type if the size is a template argument, so a MyVector<int, 1, 10> is a different class type than MyVector<int, 1, 20>.

    Regards,

    Paul McKenzie

  12. #132
    Join Date
    Nov 2003
    Location
    Pasadena, CA
    Posts
    48
    Originally posted by Paul McKenzie
    When you create a template, you are creating a different type if the size is a template argument, so a MyVector<int, 1, 10> is a different class type than MyVector<int, 1, 20>.
    template <typename T, int N, int M>
    class BoundVector : public MyVector<T> {...}

    Yeah, yeah. And the base class generalizes the consts away and is only templated for the type (actually I'm only going to use it with one type and the base is there to generalize away a payload that is also contained in the wrapper container but not the member vector - ah, I've digressed into unneeded detail).

    the base MyVector is the pure wrapper...

    now user functions can manipulate MyVector * without having to be templated for bound and unbound vectors. This could have been accomplished using constructor args for N & M instead of template parameters (with 0 and vector::max_size as defaults) thus eliminating the need for an ABC. But, for the application I need an ABC anyways. The virtual call overhead is only associated with length modifiying members which again for the application are not part of the critical path.

    My inital fear came from the container mutating iterators. They inherently embed a pointer to the container object (so they can call insertion and deletion fuctions). If the user could have somehow gotten one of these as the return of a vector::fun call then I'd be dead.

    See, then the mutating iterator would call the member vector insert and not the wrapper. Even more hiddious, nothing keeps the mutating iterator from being a friend of the vector and bypassing the front-door public interface all together in loo of some wonderous private method or internals dittling.

    I know that sounds unlikely but just imagine a clever STL implementer who thought that beyond the normal generic insertion iterator adaptor, that they'd do a specialization for vector that used wonderous back-doors (since after all they wrote vector also and want the combination to work efficently).

    One of the real devils of STL was just how much is implementation specific. Containers are required to have certain interfaces, and adaptors must work with generic types. But nothing stops vendors from specialzing the adaptors to tuned vendor-specific interfaces and nothing forces them to implement in terms of public interfaces.

    If anyone can still think up a hole in the design - I'd love to hear it (so I can close it)
    Last edited by mclark; November 21st, 2003 at 11:37 PM.
    The views expressed are those of the author and do not reflect any position taken by the Goverment of the United States of America, National Aeronautics and Space Administration (NASA), Jet Propulsion Laboratory (JPL), or California Institute of Technology (CalTech)

  13. #133
    Join Date
    Nov 2002
    Location
    Los Angeles, California
    Posts
    3,863
    Well this is not going to violate your size contraints, but
    you can call Remove(...) with just the iterators. So a
    user could "remove" enough elements to violate the lower limit on your object, but if he/she then tried to erase them, they would have to go through your wrapper and the problem would be caught. If they did not call erase then it would leave the
    vector in a kind of funny state. Just thought I would through it
    out there.
    Wakeup in the morning and kick the day in the teeth!! Or something like that.

    "i don't want to write leak free code or most efficient code, like others traditional (so called expert) coders do."

  14. #134
    Join Date
    Nov 2003
    Location
    Pasadena, CA
    Posts
    48
    Originally posted by souldog
    Well this is not going to violate your size contraints, but
    you can call Remove(...) with just the iterators. So a
    user could "remove" enough elements to violate the lower limit on your object, but if he/she then tried to erase them, they would have to go through your wrapper and the problem would be caught. If they did not call erase then it would leave the
    vector in a kind of funny state. Just thought I would through it
    out there.
    Good catch. I was assuming that remove was a member but of course its just a normal function. Since you caught it - how do you suggest fixing the hole (and yes, remove would violate the lower bounds constraint because I really care about bounding the number of valid elements - not total capacity except that total cap. should never be greater than bounded max of course).

    Off the top of my head, it would seem that we'd have to do a full specialization. Does this work? Will this clash with Remove for the underlying vector if unbounded (I think it will since part of this whole exercise was bound and unbound have same type for iterators)?

    My second approach would be to try and control the value remove sets the "unused" element to so that it is still a valid (albeit default) value. If possible, this solution works well within the target design. The bounded vectors contain references to nodes in a graph and there is a graph-termination node that works well for a default for remove.

    Are we left with just the code comment that says DO NOT DO?

    If we fix remove, are all other similar cases (remove_if) automatically fixed (ie implemented in terms of remove)?

    I don't know - It takes time to look stuff up and find out, that's why I'm here.

    Again, souldog - very good catch.
    The views expressed are those of the author and do not reflect any position taken by the Goverment of the United States of America, National Aeronautics and Space Administration (NASA), Jet Propulsion Laboratory (JPL), or California Institute of Technology (CalTech)

  15. #135
    Join Date
    Nov 2003
    Location
    Pasadena, CA
    Posts
    48

    the souldog remove hole

    Ok, I spent my 5 minute walk to the coffee vending machine thinking about the remove hole (yes, where I work for 35 cents you can get a large shot glass of coffee at any hour of the day or night).

    My function template full specialization solution will work - if its legal!

    (for the language-standard monkies)
    Can I fully specialize a function template that's in the std namespace. I know I can't overload it because injecting names into namespace std is illegal (and almost all compilers enforce this).


    If it is, then I can fully specialize remove for my iterator of a vector of myT. Note that since my design makes iterators to bound vectors of myT the same type as normal vectors of myT, the full specialization (will my personally chosen default value for remove to use) will apply to both. This is not a problem, since remove makes no claim as to what the value will be. So even if a user has a normal vector of myT that's unrelated to the container I'm building - the semantics of remove are still valid. Now if there were two such concepts as what I'm building that each used myT but needed different defaults for remove then we're hosed. But since the valid default value is of type myT and directly related to myT (think 0 or NULL smart-pointer if you need the example) then hopefully the default value is the only one that ever makes sense for myT.

    Now, besides the remove family of functions - are there any others like this lurking out there to frustrate me?
    The views expressed are those of the author and do not reflect any position taken by the Goverment of the United States of America, National Aeronautics and Space Administration (NASA), Jet Propulsion Laboratory (JPL), or California Institute of Technology (CalTech)

Page 9 of 19 FirstFirst ... 6789101112 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Azure Activities Information Page

Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center