STL overkill


  • BINNED

    Just found this a few days ago. It's not an earth shattering WTF but the sidebar is full of this stuff, so I thought I'd post it anyway:

    map<bool, Foo*> fooMap;

    I think either of

    Foo* foo, bar;
    Foo* foos[2];
    pair<Foo*, Foo*> foos;

    should have sufficed.



  • @topspin said:

    I think either any of
    Foo* foo, bar;
    Foo* foos[2];
    pair<Foo*, Foo*> foos;

    should have sufficed.

    Not if you want to protect against future systems that include the FileNotFound state.


  • @topspin said:

    Just found this a few days ago. It's not an earth shattering WTF but the sidebar is full of this stuff, so I thought I'd post it anyway:

    map<bool, Foo*> fooMap;

    I think either of

    Foo* foo, bar;
    Foo* foos[2];
    pair<Foo*, Foo*> foos;

    should have sufficed.



    Well, not necessarily.  Say this is a class member, and you want to use it in some member function.  You're passed in a bool.

    You could do this:

    if(bCondition) foo->DoWhatever();
    else bar->DoWhatever();

    Or this:

    /* Probably shouldn't cast bool to int as an array index... it's ugly */
    if(bCondition) foos[0]->DoWhatever();
    else foos[1]->DoWhatever();

    Or this:

    if(bCondition) fooPair->first->DoWhatever();
    else fooPair->second->DoWhatever();

    Or you could do this:

    fooMap[bCondition]->DoWhatever();

    Yes, the final compiler-generated code is slightly more complex, but it's (arguably) more readable, and if later you need to change it from a bool to an enum or something (to support FileNotFound, of course), you only have to change the variable, rather than having to add in an else-if clause.



  • Maybe it's because a map provides the additional state? Foo * could be a NULL pointer, an object instance or "value not assigned in map.



  • Meh, it's not that odd. Say you expect that in a future version that bool will change to a different type. For instance, you currently have a flag that tells you whether you're in standard mode (when false) or Special Calculation Mode (when true). In some future version there could be more modes. When that specification comes down the pike you just change the variable and the template argument from a bool to an enum, or a string, or whatever other type you like, and the lookup code still works.

    That's one of the main advantages of template arguments in the first place; they let you change subtypes without rewriting lots of code.



  • @topspin said:

    Foo* foo, bar;

    should have sufficed.

    I think he wanted two foo pointers, not to locally allocate one of them:



  • @AuraSeer said:

    Meh, it's not that odd. Say you expect that in a future version that bool will change to a different type. For instance, you currently have a flag that tells you whether you're in standard mode (when false) or Special Calculation Mode (when true).

    Then you should already be using a two-value enum with meaningful names like STANDARD_MODE and SPECIAL_MODE, not mysterious magic booleans.

    Or you might consider actually using OOP.



  • I agree it's overkill (and as much as I dislike the STL, it would also be overkill in e.g. Boost), but it might have been written with future expansion in mind. If you ever want to use fooMap for some other generic function, it will need to have a similar type as your other maps. So, if you want to print, or insert, or whatever over maps of type map<key_t, value_t>, then you'll need to store even the lowest boolean like this.

    A slightly odd effect of this construction is that if you insert a value that evaluates to true, but isn't equal to true (e.g. 23), then it will store it as a different key in this map, whereas your solutions would store it under the key true.


  • BINNED

    @Whoa314 said:

    I think he wanted two foo pointers, not to locally allocate one of them:
     

    It's obviously a typo on my part and not what I meant, but luckily the compiler would have caught that.

    That's what you get for writing "Foo* foo" instead of "Foo *foo" in the first place.

     



  • @Heron said:

    Or this:

    /* Probably shouldn't cast bool to int as an array index... it's ugly */
    if(bCondition) foos[0]->DoWhatever();
    else foos[1]->DoWhatever();

    I dunno about your sense of aesthetics, but the standard defines the conversion from bool to integer (true -> 1, false -> 0), so it's perfectly acceptable to use a bool to index the two-element array.



  • @tdb said:

    I dunno about your sense of aesthetics, but the standard defines the conversion from bool to integer (true -> 1, false -> 0), so it's perfectly acceptable to use a bool to index the two-element array.

    Aesthetics is the only reason I'd have for complaining about casting a bool to act as an index... that's why I said "it's ugly".



  • @Heron said:

    @tdb said:

    I dunno about your sense of aesthetics, but the standard defines the conversion from bool to integer (true -> 1, false -> 0), so it's perfectly acceptable to use a bool to index the two-element array.

    Aesthetics is the only reason I'd have for complaining about casting a bool to act as an index... that's why I said "it's ugly".

    If the ugliness comes from the implicit conversion, how about foos[flag ? 1 : 0]->do_something()?



  • @tdb said:

    If the ugliness comes from the implicit conversion, how about foos[flag ? 1 : 0]->do_something()?

    Nah, I'd still prefer using a map of bool to function pointers (or better, a map of some enum to function pointers).



  • @tdb said:

    [

    I dunno about your sense of aesthetics, but the standard defines the conversion from bool to integer (true -> 1, false -> 0), so it's perfectly acceptable to use a bool to index the two-element array.

    true is -1 in VB



  • @Daid said:

    @tdb said:
    [

    I dunno about your sense of aesthetics, but the standard defines the conversion from bool to integer (true -> 1, false -> 0), so it's perfectly acceptable to use a bool to index the two-element array.

    true is -1 in VB

    Yeah, but in VB ignorance is strength and freedom is slavery.



  • @Daid said:

    @tdb said:
    [

    I dunno about your sense of aesthetics, but the standard defines the conversion from bool to integer (true -> 1, false -> 0), so it's perfectly acceptable to use a bool to index the two-element array.

    true is -1 in VB

    Yes, because VB is braindead enough to not have proper boolean logic operators. However, the topic of this thread is C++, so VB's workings are insignificant.



  • @tdb said:

    However, the topic of this thread is C++, so VB's workings are insignificant.

    I think "irrelevant" is the word you're looking for ;)



  • @Heron said:

    @tdb said:

    However, the topic of this thread is C++, so VB's workings are insignificant.

    I think "irrelevant" is the word you're looking for ;)

    Right, thanks for the correction.


Log in to reply