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.
