On 26 February 2012 10:31, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Lex Trotman wrote:
I have thought about which types should be "automagically" present in Geany without a tags file, and I do not think the intN_t types qualify. They are not fundamental,
In C99 they are.
they require header <cstdint> to
Thats C++. I'm pretty sure all the C99 intN_t types were added to the latest C++ standard as well.
The changes we are talking about are to filetypes.cpp which is c++
The intN_t types are in <cstdint> header, they are not fundamental and as I said they are not required.
Also it is bad practice to be using fixed size types, especially as they are not actually guaranteed to exist.
All compliant C99 implementations *must* provide the standard intN_t types.
No, they are optional in C as well, an implementation on an embedded processor does *not* have to supply a fixed width twos complement 64 bit type unless it happens to have one. A processor does not have to address 8 bits, it could address 16 bits in which case int8_t won't exist.
If they are used they should be typedefed to a more user friendly name.
I am sure I am not the only one who considers
typedef int32_t my_project_int16_t ;
to be bad practice.
Indeed, but it is good practice to typedef uint8_t to octet to represent utf8 octets instead of splattering uint8_ts everywhere, thats what I mean.
So I suggest that only the fundamental types and <cstddef> types size_t, nullptr_t ptrdiff_t and max_align_t should be available by adding them to the secondary keyword list for C++.
Please do not conflate C++ with C.
As I said the changes were to filetypes.cpp which is the C++ filetype file. I mentioned in a previous post that something similar should be done to the C types, but that isn't the current point.
Cheers Lex