Re: int to intXX_t conversion

On 02/01/2013 12:06 PM, Kinkie wrote:

> BTW: c++11 defines intXX_t as part of the core language; I believe
> that to be an indication that the language will evolve in that
> direction.

I sure hope C++ does not evolve in the direction of uint64_t! :-)

Just because something very useful is added, does not mean it should be
used by default instead of something old (but also very useful).

>> - Saying "I did not think about the number of bits" is better than
>> implying "I did think about the number of bits" when, in fact, I did
>> not.

> In fact, blindly search & replacing and only thereafter think about
> the opportunity of up- or downsizing some variables is probably the
> most effective strategy.

If the goal is to replace "int" with "int32_t", then yes. If the goal is
to get something out of those changes, then I think such blind
search-and-replace would do a lot more harm than good, especially since
internally "int" is "int32_t" on all platforms we know about.

In other words, if the plan is:

  1. Blindly replace all int with int32_t.
  2. Think and replace int32_t with something better where needed.

Then I strongly recommend starting with step #2 and replacing "int" with
something better where needed and only where needed.

> One further pro I can think of, it provides further clues to automated
> code checking tools about what we expect the needed size of a variable
> to be,

To be more precise, it lies that we expect something specific. After
step #1, we do not magically start expecting something. We still "did
not think about it" but now we claim to others that we have.

>>> It is of course a matter of opinion in the end. It seems that I am
>>> being more aggressive than the average with legacy code, especially
>>> for "search and replace" things which don't require much brain power
>>> such as this one.
>>
>> Is "int" really a "legacy", outdated concept not recommended for new
>> code by C++ gurus? From my non-guru point of view, "int" is preferred
>> when we do not want to think about exact bit sizes (whether that "not to
>> think" decision is correct or not is a separate question, but the type
>> accurately reflects that decision).
>
> legacy and outdated, that's a bit of an extreme statement.
> But (according to http://en.cppreference.com/w/cpp/types/integer )
> c++11 defines 24 new integer types of various widths.

I think we all agree that new int types are useful. I do not yet agree
that all "int" uses should be replaced with one of the new types.

>>> Besides StringNG, I'm trying to apply myself to side things such as
>>> cleanup, c++-ification, STL-ification (in place of the plethora of
>>> linked list implementations we have in place now), etc.
>>
>> Nothing wrong with that, of course, but I hope I can convince you to add
>> bug fixing to the above list :-). I believe Amos mentioned 60+ v3.3 bugs
>> waiting for a volunteer...
>
> I'm still not good enough to produce meaningful results in these
> areas, unfortunately.

I think replacing many "int"s (with good results) is much harder than
fixing an isolated bug. I am sure you are capable of both though!

Thank you,

Alex.
Received on Fri Feb 01 2013 - 19:27:40 MST