[Geany-devel] [geany/geany] 795ee4: Merge pull request #28 from RetroX/patch-1
elextr at xxxxx
Sat Feb 25 23:57:18 UTC 2012
On 26 February 2012 10:31, Erik de Castro Lopo <mle+tools at 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
>> 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.
More information about the Devel