std::min and 32/64 bits.

Discussion in 'C++' started by Andrea Venturoli, Jan 22, 2013.

  1. Hello.

    I've got a style question...
    Suppose I have the following code:

    std::vector<X> V;
    std::min(V.size(),1000u);

    Now this will compile on 32b gcc, but not on 64b gcc.
    So I can write:

    std::vector<X> V;
    std::min(V.size(),1000ul);

    This will compile on 64b, but not on 32b.



    Of course I can write:

    std::vector<X> V;
    std::min(V.size(),std::vector<X>::size_type(1000));

    This will work on both platform.

    However, not only I find this utterly ugly, but I feel it might make the
    code harder to understand for the newcomer.


    Is there any better way to achieve the above?


    bye & Thanks
    av.
     
    Andrea Venturoli, Jan 22, 2013
    #1
    1. Advertising

  2. On 1/22/2013 8:09 AM, Andrea Venturoli wrote:
    > Hello.
    >
    > I've got a style question...
    > Suppose I have the following code:
    >
    > std::vector<X> V;
    > std::min(V.size(),1000u);
    >
    > Now this will compile on 32b gcc, but not on 64b gcc.


    Same with VC++ 2012 Express.

    > So I can write:
    >
    > std::vector<X> V;
    > std::min(V.size(),1000ul);
    >
    > This will compile on 64b, but not on 32b.
    >
    >
    >
    > Of course I can write:
    >
    > std::vector<X> V;
    > std::min(V.size(),std::vector<X>::size_type(1000));
    >
    > This will work on both platform.
    >
    > However, not only I find this utterly ugly, but I feel it might make the
    > code harder to understand for the newcomer.
    >
    >
    > Is there any better way to achieve the above?


    Perhaps you could cast the return value of 'size' to what you need:

    std::min(int(V.size()), 1000);

    Unless, of course, you expect the size to be bigger than 2^31-1, then
    cast to 'long long' or some such.

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Jan 22, 2013
    #2
    1. Advertising

  3. Andrea Venturoli

    Jeff Flinn Guest

    On 1/22/2013 8:09 AM, Andrea Venturoli wrote:
    > Hello.
    >
    > I've got a style question...
    > Suppose I have the following code:
    >
    > std::vector<X> V;
    > std::min(V.size(),1000u);
    >
    > Now this will compile on 32b gcc, but not on 64b gcc.
    > So I can write:
    >
    > std::vector<X> V;
    > std::min(V.size(),1000ul);
    >
    > This will compile on 64b, but not on 32b.
    >
    >
    >
    > Of course I can write:
    >
    > std::vector<X> V;
    > std::min(V.size(),std::vector<X>::size_type(1000));
    >
    > This will work on both platform.
    >
    > However, not only I find this utterly ugly, but I feel it might make the
    > code harder to understand for the newcomer.


    std::min(V.size(),std::size_t(1000)); may be not as ugly?

    Jeff
     
    Jeff Flinn, Jan 22, 2013
    #3
  4. "Andrea Venturoli" wrote in message news:kdm327$d4r$...
    >
    >Hello.
    >
    >I've got a style question...
    >Suppose I have the following code:
    >
    >std::vector<X> V;
    >std::min(V.size(),1000u);
    >
    >Now this will compile on 32b gcc, but not on 64b gcc.
    >So I can write:
    >
    >std::vector<X> V;
    >std::min(V.size(),1000ul);
    >
    >This will compile on 64b, but not on 32b.
    >
    >
    >
    >Of course I can write:
    >
    >std::vector<X> V;
    >std::min(V.size(),std::vector<X>::size_type(1000));
    >
    >This will work on both platform.
    >
    >However, not only I find this utterly ugly, but I feel it might make the
    >code harder to understand for the newcomer.
    >
    >
    >Is there any better way to achieve the above?
    >
    >
    > bye & Thanks
    >av.


    What about std::min<size_t>(V.size(),1000);

    Is that still ugly?
     
    Fred Zwarts \(KVI\), Jan 22, 2013
    #4
  5. On 01/22/13 16:54, Fred Zwarts (KVI) wrote:

    > What about std::min<size_t>(V.size(),1000);
    >
    > Is that still ugly?



    Thanks to everyone; I'll answer all in one message.

    Jeff: using size_t instead of std::vector<X>::size_type is surely
    shorter; however I don't think there is any guarantee they are the same
    type.

    Same goes for int, Victor.

    I like Fred's solution: I hadn't thought about explicitly specifiying
    std::min instance.

    I'll try std::min<std::vector<X>::size_type>.

    bye & Thanks
    av.
     
    Andrea Venturoli, Jan 24, 2013
    #5
  6. On 1/24/2013 4:27 AM, Andrea Venturoli wrote:
    > On 01/22/13 16:54, Fred Zwarts (KVI) wrote:
    >
    >> What about std::min<size_t>(V.size(),1000);
    >>
    >> Is that still ugly?

    >
    >
    > Thanks to everyone; I'll answer all in one message.
    >
    > Jeff: using size_t instead of std::vector<X>::size_type is surely
    > shorter; however I don't think there is any guarantee they are the same
    > type.
    >
    > Same goes for int, Victor.


    My suggestion of casting to 'int' is based on the fact that '1000' has
    that type.

    > I like Fred's solution: I hadn't thought about explicitly specifiying
    > std::min instance.
    >
    > I'll try std::min<std::vector<X>::size_type>.


    Definitely clearer and easier on the eye! ;-)

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Jan 24, 2013
    #6
  7. On 01/24/13 14:54, Victor Bazarov wrote:

    > My suggestion of casting to 'int' is based on the fact that '1000' has
    > that type.


    Right, but 1000 being an int was not my intention, really.



    >> I like Fred's solution: I hadn't thought about explicitly specifiying
    >> std::min instance.
    >>
    >> I'll try std::min<std::vector<X>::size_type>.

    >
    > Definitely clearer and easier on the eye! ;-)


    Not really, but less worse, perhaps.



    bye & Thanks
    av.
     
    Andrea Venturoli, Jan 24, 2013
    #7
  8. Luca Risoliaæ–¼ 2013å¹´1月25日星期五UTC+8上åˆ2時20分34秒寫é“:
    > On 24/01/2013 10:27, Andrea Venturoli wrote:
    >
    > > Jeff: using size_t instead of std::vector<X>::size_type is surely

    >
    > > shorter; however I don't think there is any guarantee they are the same

    >
    > > type.

    >
    >
    >
    > If I remember well, with regard to standard containers using standard
    >
    > allocators, size_type ends up being a typedef of size_t, so you have
    >
    > this guarantee in your case.
    >
    >
    >
    > Anyway, I would use "std::min<decltype(V.size())>", which is good in the
    >
    > general case.
    >
    >
    >
    >


    As far as I know the vector in C++ is an indexed
    homogeneous type of objects.

    It is not a list of arbitrary types allowed
    of objects with a GC built in.

    >
    > --- news://freenews.netfront.net/ - complaints: ---
     
    88888 Dihedral, Jan 24, 2013
    #8
  9. Luca Risoliaæ–¼ 2013å¹´1月25日星期五UTC+8上åˆ6時16分15秒寫é“:
    > On 24/01/2013 23:06, 88888 Dihedral wrote:
    >
    > > Luca Risoliaæ–¼ 2013å¹´1月25日星期五UTC+8上åˆ2時20分34秒寫é“:

    >
    > > As far as I know the vector in C++ is an indexed

    >
    > > homogeneous type of objects.

    >
    > >

    >
    > > It is not a list of arbitrary types allowed

    >
    > > of objects with a GC built in.

    >
    >
    >
    > Sorry, but I don't quite understand what you are talking about. My
    >
    > answer was about size_t and size_type being the same type in a
    >
    > particular case, which has nothing to do with the type of objects stored
    >
    > in a vector or list or with a GC...
    >
    >
    >
    >
    >
    >
    >
    > --- news://freenews.netfront.net/ - complaints: ---



    A vector of pointers of type void * is allowed in C++.

    But it is very inconvenient to set up all different
    items of objects in this way in C++.
     
    88888 Dihedral, Jan 25, 2013
    #9
  10. Andrea Venturoli

    Balog Pal Guest

    On 1/24/2013 10:27 AM, Andrea Venturoli wrote:
    > I'll try std::min<std::vector<X>::size_type>.


    Sure, why use a single word of 6 letters when you can make it into 8
    tokens with 25 overall length. O,O

    Guess it's time to start the new school of 'Noise-oriented programming'.
     
    Balog Pal, Jan 25, 2013
    #10
  11. On 01/25/13 01:49, Balog Pal wrote:
    > On 1/24/2013 10:27 AM, Andrea Venturoli wrote:
    >> I'll try std::min<std::vector<X>::size_type>.

    >
    > Sure, why use a single word of 6 letters when you can make it into 8
    > tokens with 25 overall length. O,O


    Because I never found a "guarantee" that std::vector<X>::size_type=size_t.

    The fact that this usually is true is not enough in my case.

    I'd be glad to change *if* I could be sure of the above.

    bye & Thanks
    av.
     
    Andrea Venturoli, Jan 25, 2013
    #11
  12. Andrea Venturoli

    Marc Guest

    Juha Nieminen wrote:

    > Btw, shouldn't C++11 allow for creating a min() function that supports
    > different (but compatible) parameters?


    http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2199.html

    and a couple other papers proposed enhanced min/max, but none was
    accepted (usually they were thought too complicated I think).
     
    Marc, Jan 25, 2013
    #12
  13. Andrea Venturoli

    Balog Pal Guest

    On 1/25/2013 10:09 AM, Andrea Venturoli wrote:
    > On 01/25/13 01:49, Balog Pal wrote:
    >> On 1/24/2013 10:27 AM, Andrea Venturoli wrote:
    >>> I'll try std::min<std::vector<X>::size_type>.

    >>
    >> Sure, why use a single word of 6 letters when you can make it into 8
    >> tokens with 25 overall length. O,O

    >
    > Because I never found a "guarantee" that std::vector<X>::size_type=size_t.
    >
    > The fact that this usually is true is not enough in my case.


    Could you explain your case please? size_t has a well defined idea
    behind it. For the cases discussed this far it shall cover the purpose,
    even if some particularly evil implementation have chosen a different type.

    > I'd be glad to change *if* I could be sure of the above.


    I'm not sure you want to be sure of the right thing.
     
    Balog Pal, Jan 26, 2013
    #13
  14. On 01/26/13 12:29, Balog Pal wrote:

    > Could you explain your case please?


    Sure.
    Both VC and GCC will warn about conversions (e.g. from long to int);
    *hundreds* of warning in a compilation could lead to miss the important
    ones.
    So I've been asked to remove as much warnings as I can: I ofter turn the
    relevant options off (e.g. -Wconversions in GCC), since most of these
    are harmless, but I've been asked not to do this.



    > size_t has a well defined idea behind it.


    Sure.
    From what I found: "size_t corresponds to the integral data type
    returned by the language operator sizeof".

    I'd be glad to be proven wrong, but this has in principle nothing to do
    with vectors (altough most implementation will use this type).
    So the use of size_t *could* lead to a conversion warning (which is my
    given goal to avoid).



    > For the cases discussed this far it shall cover the purpose,
    > even if some particularly evil implementation have chosen a different type.


    In most cases, int will cover the purpose of letting the program run
    flawlessly: when our vectors will be larger than 4G elements, we'll have
    much more severe problems than some compiler warning.
    However, as I said before, one of my tasks is to avoid them anyway.



    >> I'd be glad to change *if* I could be sure of the above.

    >
    > I'm not sure you want to be sure of the right thing.


    I don't follow... what do you mean?


    bye & Thanks
    av.
     
    Andrea Venturoli, Jan 27, 2013
    #14
  15. Re: :min and 32/64 bits.

    Andrea Venturoli <> wrote:
    >> size_t has a well defined idea behind it.

    >
    > Sure.
    > From what I found: "size_t corresponds to the integral data type returned
    > by the language operator sizeof".
    >
    > I'd be glad to be proven wrong, but this has in principle nothing to do
    > with vectors (altough most implementation will use this type).


    It is the natural type for the size of a contiguous memory region. A vector
    is exactly that.
    However, sizeof is always the size in bytes. For packed representations
    such as std::vector<bool> you might need a bigger size_type. I don't know
    if that is done in practice.

    > So the use of size_t *could* lead to a conversion warning (which is my
    > given goal to avoid).


    Warnings are exactly for this. You make an assumption and if it proves
    wrong you will be warned and you can fix it. But as long as you don't get
    warnings on any of your supported platforms you're on the safe side.
    Why do you want to get rid of warnings that don't occur anyway?

    Tobi
     
    Tobias Müller, Jan 27, 2013
    #15
  16. Re: :min and 32/64 bits.

    On 01/27/13 12:40, Tobias Müller wrote:

    > Warnings are exactly for this. You make an assumption and if it proves
    > wrong you will be warned and you can fix it. But as long as you don't get
    > warnings on any of your supported platforms you're on the safe side.
    > Why do you want to get rid of warnings that don't occur anyway?


    As I said before, because I've been asked to do so (by the persons who
    pay me for my work).

    bye & Thanks
    av.
     
    Andrea Venturoli, Jan 27, 2013
    #16
  17. Andrea Venturoli

    Balog Pal Guest

    On 1/27/2013 12:05 PM, Andrea Venturoli wrote:
    > On 01/26/13 12:29, Balog Pal wrote:
    >
    >> Could you explain your case please?

    >
    > Sure.
    > Both VC and GCC will warn about conversions (e.g. from long to int);
    > *hundreds* of warning in a compilation could lead to miss the important
    > ones.
    > So I've been asked to remove as much warnings as I can: I ofter turn the
    > relevant options off (e.g. -Wconversions in GCC), since most of these
    > are harmless, but I've been asked not to do this.


    Well, that implies you work with a concrete set of compilers as the
    environment. Not just shoot in the dark (like aim to release a general
    library component claimed to be portable to the extremes).

    For that case I see not enough reason to go paranoid and mess up the
    code with excess noise. As you are pretty much able to verify that
    size_t is good for your purposes. And have a plenty of ways to ensure it
    too in form of a test, a static_assert, whatever.

    >> size_t has a well defined idea behind it.

    >
    > Sure.
    > From what I found: "size_t corresponds to the integral data type
    > returned by the language operator sizeof".


    It's also required to be unsigned in the C standard (7.17p2). And to
    serve for sizeof it must be big enough to count bytes in the system. So
    it must be good to count elements in a vector, maybe except for
    vector<bool> that is a known troublemaker and better be avoided.

    As size_type of std collections is also an unsigned integral, that is to
    count the elements, I really don't see the problem place, and if one
    actually shows up, I'd welcome the warning.

    > I'd be glad to be proven wrong, but this has in principle nothing to do
    > with vectors (altough most implementation will use this type).


    I'd be very interested in a counter-example from the general world.

    > So the use of size_t *could* lead to a conversion warning (which is my
    > given goal to avoid).


    I'd classify that is a mistaken goal -- the point is write good code,
    that is easy to make right, and also easy to read and review. That is
    obvious rather than cryptic.

    Warinigs are our friend, that help the work. We make them go away by
    writing *better* code. And in the few corner cases we encounter an
    overzealous one, it's better be suppressed on the spot.

    >> For the cases discussed this far it shall cover the purpose,
    >> even if some particularly evil implementation have chosen a different
    >> type.

    >
    > In most cases, int will cover the purpose of letting the program run
    > flawlessly:


    int is not fit for purposes of size_t, and hardly fits this discussion.

    > when our vectors will be larger than 4G elements, we'll have
    > much more severe problems than some compiler warning.
    > However, as I said before, one of my tasks is to avoid them anyway.


    And you stand with claim, that using the fixed size_t left you with
    warnings?

    >>> I'd be glad to change *if* I could be sure of the above.

    >>
    >> I'm not sure you want to be sure of the right thing.

    >
    > I don't follow... what do you mean?


    The wise saying goes "watch the baton not the runners". You look like
    being after the wrong goal.
     
    Balog Pal, Jan 27, 2013
    #17
  18. Re: :min and 32/64 bits.

    Andrea Venturoli <> wrote:
    > On 01/27/13 12:40, Tobias Müller wrote:
    >> Why do you want to get rid of warnings that don't occur anyway?

    >
    > As I said before, because I've been asked to do so (by the persons who pay me for my work).


    I seriously doubt that. It's usual that one tries to avoid warnings,
    because they are noise that distracts from real bugs. But you gain nothing
    by avoiding warnings never occur. The effect of this is just zero. You
    can't see the difference because you don't have a setup where it actually
    matters.

    Tobi
     
    Tobias Müller, Jan 27, 2013
    #18
  19. Andrea Venturoli

    Öö Tiib Guest

    On Tuesday, 22 January 2013 15:09:30 UTC+2, Andrea Venturoli wrote:
    > Hello.
    >
    > I've got a style question...


    Style questions have usually more than one good answers. It is mostly matter
    of taste with only minor amount of reasoning attached. I have seen rather nice
    explanations to awfully cryptic (for my taste) styles like Hungarian Notation.

    > Suppose I have the following code:
    >
    > std::vector<X> V;
    > std::min(V.size(),1000u);
    >
    > Now this will compile on 32b gcc, but not on 64b gcc.
    >
    > So I can write:
    >
    > std::vector<X> V;
    > std::min(V.size(),1000ul);
    >
    > This will compile on 64b, but not on 32b.
    >
    > Of course I can write:
    >
    > std::vector<X> V;
    > std::min(V.size(),std::vector<X>::size_type(1000));
    >
    > This will work on both platform.
    >
    > However, not only I find this utterly ugly, but I feel it might make the
    > code harder to understand for the newcomer.
    >
    >
    > Is there any better way to achieve the above?


    This problem does not exist with my style. There may be others but this
    is luckily gone:

    1) I use style that requires template class instantiations to be typedefed. So:

    typedef std::vector<X> Xes;
    Xes V;

    Reasoning: Most templates that can be used as alternatives in same place have
    similar interface. Typedefing makes it easy to replace one type with other.
    In given example to replace std::vector with std::deque only typedef has to be
    edited. A good name clarifies the meaning of the type in context and it is often
    shorter than template instantiation. typedef is also good spot where to document
    the choice of particular template (why vector?) further if needed.

    2) I use style that requires numeric constants to be named. Only 0 and 1 may
    be used unnamed if it makes more sense than using names. Those two have
    myriad of language-defined names already (like NULL, false, nullptr,
    EXIT_SUCCESS etc.). So:

    Xes::size_type const VLimit = 1000;

    Reasoning: Name explains the meaning of constant, definition creates good spot
    where to further document it. Also it is possible to modify it from one place
    if the constant happens to change. Note that thanks to typedef it is clear to
    understand what it is meant for.

    As result your problem is removed, the code works everywhere:

    std::min( V.size(), VLimit );
     
    Öö Tiib, Jan 29, 2013
    #19
  20. Re: :min and 32/64 bits.

    On 2013-01-27 04:56, Tobias Müller wrote:
    > Andrea Venturoli <> wrote:
    >> On 01/27/13 12:40, Tobias Müller wrote:
    >>> Why do you want to get rid of warnings that don't occur anyway?

    >>
    >> As I said before, because I've been asked to do so (by the persons who pay me for my work).

    >
    > I seriously doubt that. It's usual that one tries to avoid warnings,
    > because they are noise that distracts from real bugs. But you gain nothing
    > by avoiding warnings never occur. The effect of this is just zero. You
    > can't see the difference because you don't have a setup where it actually
    > matters.


    I'm not speaking for the OP's case, but in a very general sense, you
    may not know the exact set of possible target platforms in advance.
    If you're committing the code to a public repository, you never know
    who will use it on which platforms. Even you could upgrade the system
    and see new warnings occur.

    --
    Seungbeom Kim
     
    Seungbeom Kim, Jan 30, 2013
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Lois
    Replies:
    1
    Views:
    3,355
    Ryan Stewart
    Dec 27, 2004
  2. sarmin kho
    Replies:
    2
    Views:
    845
    A. Lloyd Flanagan
    Jun 15, 2004
  3. juergen
    Replies:
    3
    Views:
    576
    opalinski from opalpaweb
    Sep 20, 2006
  4. Albert Hopkins

    When is min(a, b) != min(b, a)?

    Albert Hopkins, Jan 21, 2008, in forum: Python
    Replies:
    31
    Views:
    854
    Albert van der Horst
    Feb 4, 2008
  5. carmen

    Converting hrs and min to just min

    carmen, Aug 10, 2004, in forum: ASP General
    Replies:
    4
    Views:
    142
    carmen
    Aug 10, 2004
Loading...

Share This Page