A very good rule of thumb is to never use int when defining stuff. Use int32_t or int64_t or a project equivalent. If you don't no which, you shouldn't be defining anything. Use of int is fine when iterating over something that is absolutely never going to overflow.
I agree that size_t has no place in interfaces, ever. You should know what precision is required and use that. Short should be reserved when you want Ann to laugh at you. Nobody should ever, ever make assumptions of the precision of int. Microsoft both flipped and flopped in their first and subsequent C++ compilers. There's never a valid reason to take the risk. > On Jul 22, 2014, at 1:41 PM, Nikolay Samofatov > <nikolay.samofa...@red-soft.biz> wrote: > > Alex, > >> On 07/22/2014 09:33 AM, Alex Peshkoff wrote: >>> On 07/22/14 17:23, Dimitry Sibiryakov wrote: >>> 22.07.2014 15:12, Alex Peshkoff wrote: >>>> OK, but if we want to take into an account systems with 64-bit int the >>>> only solution is artificial types? Like FB_SIZE_T? >>> Yes, but definitely not "like FB_SIZE_T". >>> I would say that if there is no standard type that describe the purpose >>> of the type >>> (like size_t for all size parameters), >> It was said many times - size_t is very good thing, but we often do not >> support such sizes internally. Please do not suggest to add such support >> right now - or we will delay fb3 release more and more. > > I would say that adding such support properly is bordering to impossible, and > is unreasonable for > the time being. > > I can give you some examples where using size_t is not supported: > - Win32 API (DWORD for sizes) > - standard C library - e.g. "printf" - (int for sizes) > - ICU library (int32_t type from C/C++ standard for sizes) > - libtommath (int for sizes) > - Firebird's own new API (unsigned int for sizes) :-) > > Shall I continue? > > In short, smart people who understand integers use signed 32-bit integer in > their interfaces. Not so > smart people use unsigned 32-bit integers. > > IMO, Size_t is evil data type for interfaces. Somebody, who tried to import > such interface into > platform neutral language will understand me. I don't know if any of you here > have experience with > JNA, but we have quite a bit of it. And this is just an example, there are > languages besides Java. > Non-pointer types that change size from one implementation to another are > very difficult to work with. > > I think that we may disregard platforms where "int" is not 32-bit entity for > now. Such platforms are > uncommon and will likely fade away over time. > > And if facing need to port to such platform, change interfaces to use int32_t > or uint32_t types from > C/C++ standard. > > Re warnings: I absolutely cannot work with an unclean build. I am doing > serious surgery on the > Firebird code to implement "holy grail" of GC. :-) > And I need every help from the compiler I can get, as warnings often point to > real problems in the code. > > Thanks, > Nikolay > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
