delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/05/22/02:31:51

Date: Mon, 22 May 2000 09:31:24 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: "Alexei A. Frounze" <alex DOT fru AT mtu-net DOT ru>
cc: djgpp AT delorie DOT com
Subject: Re: C++, complex, etc
In-Reply-To: <3927FB98.4EB4F413@mtu-net.ru>
Message-ID: <Pine.SUN.3.91.1000522093103.22890F-100000@is>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Sun, 21 May 2000, Alexei A. Frounze wrote:

> You said "there should be no need to mix them", right? Is somewhere
> stated that I can't use strlen()s, sizeof()s, etc for making file offsets,
> array indexes, etc? If nowhere this stated that implies I *can*. It's a very
> logical thing: add sizes/lengths of objects and you'll find offset/index.
> Right? And this idea is compiler independant.
> If this is correct, why I can't mix those types (size_t, fpos_t, etc)? 

Please re-read one of my previous messages.  I think I replied to that
question already.  In a nutshell, you need to find out which of these
types tends to have a larger size.

That doesn't contradict the other part of my message where I said that
there should be no reason for mixing these types, in a
correctly-written program.  These types describe entities that has no
logical connection.  If the need to mix these types does not arise
frequently, the problems are correspondingly small.

That is not the case with int and size_t, for example.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019