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. 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. - 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? - 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). > 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... Thank you, Alex.
