Message-ID: <3923CEAD.CCF814CF@mtu-net.ru>
Date: Thu, 18 May 2000 15:06:21 +0400
From: "Alexei A. Frounze" <alex DOT fru AT mtu-net DOT ru>
X-Mailer: Mozilla 4.72 [en] (Win95; I)
X-Accept-Language: ru,en
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp AT delorie DOT com
Subject: Re: C++, complex, etc
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000518141411 DOT 13603C-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Recipient: eliz AT is DOT elta DOT co DOT il
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii wrote:
> 
> On Thu, 18 May 2000, Alexei A. Frounze wrote:
> 
> > Eli Zaretskii wrote:
> > >
> > > On Thu, 18 May 2000, Alexei A. Frounze wrote:
> > >
> > > > I don't use size_t in my sources.
> > >
> > > You cannot do that if those sources call standard functions which accept
> > > or return size_t values, such as strlen, memcpy, malloc, etc.  If you use
> > > int instead of size_t in these cases, your code becomes non-portable.
> >
> > Really? How about type casting? It doesn't work at all for int<->size_t?
> 
> Casting doesn't solve such problems, it only prevents the compiler from
> complaining.  For example, if size_t is unsigned int, then casting it to
> int will not avoid problems from comparing signed and unsigned values.
> 
> > If it's a standard type, what is it needed for then? Isn't int enough?
> 
> No, it isn't enough.  If it were enough, the ANSI comittee would not have
> invented it.

Like fpos_t which depends on file system?

bye.
Alexei A. Frounze
-----------------------------------------
Homepage: http://alexfru.chat.ru
Mirror:   http://members.xoom.com/alexfru