On Fri, Feb 1, 2013 at 7:30 PM, Alex Rousskov <[email protected]> wrote: > On 02/01/2013 10:20 AM, Kinkie wrote: >> On Fri, Feb 1, 2013 at 6:08 PM, Alex Rousskov wrote: >>> On 02/01/2013 04:01 AM, Kinkie wrote: >>>> Is there any objection for me to entertain myself doing "int" -> >>>> "intXX_t" and "unisgned int -> uintXX_t" conversions in the meanwhile? >>>> This seems to be in line with c++11 changes, and should have no >>>> adverse effects. > >>> What is the motivation behind this? Why intXX_t is better than int when >>> we do not really care about the exact variable size? > >> It adds clarity, and a predictable cross-platform, cross-os and >> cross-architecture memory layout. > > I am not sure int32_t adds "clarity" compared to "int" but it is > difficult to argue about such vague concepts, and I will not in this case.
It adds consistent information: int32_t = signed integer, 32-bits long. int = signed integer, currently somewhere between 16 and 64 bits in size. > Renaming "int" certainly has some pros. However, you have not listed any > "cons". Are there really none? I think I can come up with a few: > > - There is currently no criteria which explicit int size to use. I think > you have to develop and get them reviewed _before_ making these > widespread changes. And we all would have to obey the final rules in the > new code. This does add some overhead now and long-term. I'd approach this just in the same way as bool-ification: as progressively as possible. But yes: there would be conventions to follow. 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. > - 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. A typical "int i = func();" code is a good example: If I see > int32_t there, I would think that somebody carefully checked that func() > can never return something bigger than that. Of course, you can > carefully check every int in Squid, but that would take a lot of time > that is better spent elsewhere. > > - Is it possible that on some platforms, int is not int32_t and is > faster than int32_t? Now or in the foreseeable future? We know that on > some platforms int_fast32_t is not int so perhaps the "opposite" can > also be true? And if int is and will always be int32_t (e.g., for > backward compatibility reasons), then perhaps spelling it differently is > pointless? According to a little bit of research I did, on all current unix, unix-like and MS-Windows platforms, int == int32_t. In the past some Unix platforms implemented int==int64_t, but apparently reverted course. In fact, blindly search & replacing and only thereafter think about the opportunity of up- or downsizing some variables is probably the most effective strategy. 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, and to propagate this knowledge up the call chains, looking for places where it may get truncated. > - the visual distinction between signed and unsigned becomes less > pronounced when you use [u]intXX_t names. > - more ink for the more common "int" case > > >> 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. >> 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. -- /kinkie
