[dmd-internals] type inconsistency in the source code

Leandro Lucarella luca at llucax.com.ar
Thu Jan 26 21:46:00 PST 2012


mrmocool at gmx.de, el 27 de enero a las 01:15 me escribiste:
> I've done a little bit of code cleanup, using bool where
> apprioriate, reducing the memory footprint a bit, properly using
> enums/bitfields for flags etc.
> 
> Unfortunately there is no consistency in the types used in the code.
> It even defines some types like d_uns32 but they are very sparsely used.
> 
> Even worse there's
> // Be careful not to care about sign when using dinteger_t  <---
> typedef uint64_t dinteger_t;
> typedef int64_t sinteger_t;
> typedef uint64_t uinteger_t;
> 
>     virtual dinteger_t toInteger(); <---
>     virtual uinteger_t toUInteger();
> 
> So there's practically no difference between those functions? What's
> the deal?
> Why the inexpressive aliases?
> 
> I would personally love to have a set of types that look natural and
> clear like in D, i.e. without some crappy prefix d_ or suffix _t
> like int32,uint32,...

They are already there:
#include <stdint.h>
int32_t, uint32_t, etc. Sorry but C (and C++ in this case inherits
C stdlib) uses the _t suffix for typedefs.

Other than that, I think is a good idea, even if every pull request is
broken. But then, who cares about what I think? :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Bald men with no jobs and no money who live with their parents don't
approach strange women.
	-- George Constanza


More information about the dmd-internals mailing list