Dynamic arrays, basic type names, auto

[Markus Koskimies]

On Thu, 10 Jul 2008 14:57:54 -0400, Jarrett Billingsley wrote:

>> Aliases allow you to use different names, but I think it can't be used
>> to justify the choice/presence of (potentially) worse default names.
> 
> I agree with you 100%.  Just convince Walter and everything'll be great!
> 
> (My argument -- current integer names are qualitative, not quantitative,
> and it doesn't make sense to assign quantitative values to qualitative
> names. "long" is no longer "long" when it's the native word size.)

I'll give my vote to;

- i8, i16, i32, i64, ..., u8, u16, u32, ... or intXX / uintXX variants, 
since if you need to know the width of the number, you think it in bits. 
No use to use bytes, it's just confusing.

- int and uint for default integer size; compiler can decide what to use.

- byte, word, dword; these are well defined due to historical reasons. 
Change them and you confuse lots of people.

- short, long; these are also well known types from C, and I think that 
there is no use to redefine them and confuse people.

- ushort, ulong; since short&long are well-defined, why not to have an 
unsigned variant?

---

Hmmh... I would suggest, that there would not be such an element as 
"uint" (default unsigned integer). Why?

- Programmers tend to heavily use "int" in their code

- Unsigned variants are mostly used by system software, i.e. they are 
returned from memXXX, file system calls and such.

- When unsigned are used, the programmer knows the width (it is specified 
by the system). Why not to use byte/dword/ulong/u64 as a type?

As the compiler could decide what size to use, it could determine an 
assignment of unsigned to "int". Let's assume (32-bit systems):

	u32 getFileSize();

	int a = getFileSize();

	==> compiler selects 64-bit integer for circumventing problems in 
conversion.

:)

[Yes I know, it would be hard when passing ints to other functions, since 
the function may be compiled for 32-bit ints only] ;)