Daniel Kr=C3=BCgler ha scritto:
> On May 25, 6:21 pm, AlbertoBarb...@libero.it (Alberto Ganesh Barbati)
> wrote:
>> Daniel Kr=C3=BCgler ha scritto:
> [..]
>>> with a possible additional constraint along the line of:
>>> "The members sec and nsec are both implementation-defined,
>>> signed integral types and their corresponding member digit of
>>> their numeric_limits specialization shall be at least 31 bit."
>> std::int_least32_t, perhaps?
>=20
> I considered a similar specification, Ganesh, but decided against
> it, because I could not find convincing arguments that
> std::int_least32_t is more reasonable than e.g. std::int_fast32_t.

[note - I've read Pete Becker's post, but I think this discussion is
still not completely pointless. Even if N2285 won't use this declaration
of xtime, there may be other present and future library additions that
may face the same kind of issue, that is: how to impose some minimum
size requirements on the integer types of its interface]

If you use an unspecified implementation-defined type, then you will
eventually need to introduce an additional typedef for that type. Yes,
we are going to have declspec in C++0x, but using declspec(xtime::sec)
all over the place is quite ugly, isn't it? Moreover, you didn't specify
if sec and nsec must be of the same type. If they're not, then you may
need another typedef. Using a type from <cstdint> is clearer, more
concise and makes life easier for everyone, IMHO.

> But if one of the <cstdint> types is preferred compared to
> an explicit description (as above), then std::int_fast32_t seems
> more appropriate than std::int_least32_t, don't you think so?

Good point. If I have to write the pros of int_least32_t over
int_fast32_t, I would say that:

1) it might make the size of xtime smaller (it won't certainly make it
larger), and that may be good if the user stores a lot of instances

2) if you want to perform "fast" operations, you can safely convert the
value implicitly:

  void foo(const xtime& x)
  {
    int_fast32_t sec =3D x.sec;
    // do something "fast" on sec
  }

The only pro of int_fast32_t I can think of is that in-place operations
such that

  void foo(xtime& x)
  {
     x.sec +=3D 1;
  }

may be "faster".

I agree that none of these arguments are very strong. My preference
still goes to int_least32_t because of point 1) above. If, instead of
struct members, the values had to be passed as function arguments, for
example:

  void sleep(??? sec, ??? nsec);

then I would have not doubt preferring int_fast32_t.

Regards,

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]