[M3devel] size_t?

[Jay]

I did later notice size_t was there.
I think what I earlier noticed was ptrdiff_t nowhere.
 
> size_t = INTEGER.
But unsigned presumably?
 
What I had was correct, right?
In C++ no header is needed for size_t, it is just so basic and widespread.
Not sure about ptrdiff_t.
 
Either way, they both do live in that middle ground between compiler and library -- a very low level --
as size_t is defined as the type of sizeof() expressions and ptrdiff_t is defined as the type you get when you subtract pointers. And you don't need nay header to use sizeof() or subtract pointers.
 
If it were really up to me, I'd have the Modula-3 language predefine all of int8, uint8, int16, uint16, int32, uint32, int64, uint64, size_t, ptrdiff_t, and maybe char and wchar_t and INTEGER.
There is a corralary dilemna here that I haven't figured out, and have seen code address that I haven't adjusted to yet. That is, the code uses uint32 "everywhere", instead of something "more abstract/vague". When it comes down to it, I suspect this is the right thing. The abstraction only seems to buy problems. UNLESS you have a processor with a larger natural integer that performs poorly on smaller integers, or a processor that perfs badly with 32 bit integers.
 
Perhaps Modula-3 has solved it ok, in that INTEGER == ptrdiff_t.
In many and growing systems, "int", besides its signedness, is too small for many occurences.
That is the problem I think in C. If Modula-3 has essentially defined INTEGER to be the size of a pointer, then ok.
 
 - Jay



> CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] size_t?> Date: Mon, 11 Feb 2008 17:04:10 -0500> To: jayk123 at hotmail.com> > Sorry.> > They belong in Cstddef.i3. size_t is already there. Let's try to > stick to the C ".h" structure.> > size_t = INTEGER.> > On Feb 11, 2008, at 4:51 PM, Jay wrote:> > > > These are OS-dependent! They should not be in BasicCtypes.> >> > 1) There is no Utypes on Windows.> > These are very basic types that belong at a very low level.> > In C++ for example, size_t is provided "automatically" by the > > compiler, no header is needed.> >> > 2) Are they really OS dependent? What OS makes my definitions wrong?> > On what 32 bit architecture is size_t not an unsigned 32 bit > > integer and ptrdiff_t not a signed 32 bit integer?> > Ditto for 64 bit.> > These should always be the same size as a pointer and with the > > proper signedness.> > Even if some of the *.i3 files make size_t = int, is that really > > correct?> > And, I assume int vs. long issue is not an issue here.> > Though they may be different types in C and C++, they need not be > > in Modula-3 (when they are the same size, of course)> >> > - Jay> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] size_t?> > > Date: Mon, 11 Feb 2008 11:38:48 -0500> > > To: jayk123 at hotmail.com> > >> > >> > > On Feb 11, 2008, at 6:23 AM, Jay wrote:> > >> > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): size_t => > > > INTEGER;> > > >> > > > really? it is signed?> > > > and we are sure this is going to be 64 bits on 64 bit targets?> > > >> > > > size_t and ptrdiff_t ought to be in BasicCtypes, right?> > > > That has a 32 bit and 64 bit version, at least.> > >> > > These are OS-dependent! They should not be in BasicCtypes.> > >> > > >> > > >> > > > Does INTEGER effectively equal int or ptrdiff_t?> > > >> > > > - Jay> >> > Need to know the score, the latest news, or you need your Hotmail®- > > get your "fix". Check it out.> 
_________________________________________________________________
Climb to the top of the charts! Play the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080211/145dc5e9/attachment-0002.html>