Re: reasoning of ::std::cout (ostream) conversion w.r.t. plain, signed and unsigned chars...
On Jan 29, 12:18 pm, ?? Tiib <oot...@hot.ee> wrote:
limits on size_t variable: There are often very few real physical
limits that hold us from having multi megabyte objects in sw we write.
:-) Well, I think some of the embedded s/w developers would not
strongly agree (even those that do use C++ for embedded development),
but I think if we narrow the discussion context to the mostly non-
embedded scenarios then yes, one can deem physical limits as mostly
permissive of multi-megabyte objects... but this is a big 'narrowing'
of the context indeed :-)
The piles of static_cast<size_t>(variable) at places of its usage and
static_cast<uint16_t>(formula) at places its acquisition make the code
I am not sure why one would need to have all that many casts... esp.
for cases when coercion from something like uint8_t (on-wire) to
uint_fast8_t (in-ram) representations would suffice...
struct msg_onwire {
uint8_t some_field; // gets parsed and loaded at IO stage
};
struct obj_inram {
uint_fast8_t some_field; // gets used, if needed, in heavy CPU-bound
computations
};
msg_onwire wire;
obj_inram ram;
ram.some_field = wire.some_field;
then compute-away on "fast" type in RAM (i.e. use 'ram.some_field' in
some heavy cpu-bound processing et al -- if such computations are
needed in the first place of course).
May be I misunderstood your point though -- sorry.
Answers like "Since it did fit" and "I deemed it feasible" are not
overly reasonable. That maintainer may be is facing a situation where
he needs to enlarge the limits to 70 kilobytes, but that uint16_t is
sitting deep in legacy interfaces, file formats or protocols and
thousands of devices/applications on field communicate with each other
using these interfaces, protocols or file formats. ;-)
I am not sure that one would have to use explicit uint16_t if one
expects the possibility of change, e.g. consider typedef time_t cases
(for the lack of better examples). If maintainer needs to enlarge the
type due to evolution of design (e.g. evolution of protocol, app
needs, etc.) then one would simply change typedef in 1 place and let
it propagate (e.g. typedef int32_t, to typedef int64_t time_t, to
typedef xyz time_t, etc.).
As for file-formats and protocols -- one simply cannot escape the need
of redesigning things in a serious way when protocol changes anyway
(irrespective of uint8_t, uint16_t, uint32_t types) -- to this extent
I think this is why so many protocols take so long to design/implement
and last so long (e.g. IPv4) as any change in their definitions/
interfaces will invariably be time-consuming to propagate... but to be
any other way is simply to expect one to be forward-compatible and
this is mostly not possible.
Anyways -- I think we have somewhat diverged from the original subject
of this post and so, despite the fact that I have enjoyed this
conversation/thread, I'll finish my participation now :-)
Kind regards
Leon.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]