www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/02/04/02:49:23

Message-ID: <20010204073927.4381.qmail@lauras.lt>
From: "Laurynas Biveinis" <lauras AT softhome DOT net>
Date: Sun, 4 Feb 2001 09:39:27 +0200
To: djgpp-workers AT delorie DOT com
Subject: Re: stdint.h
Mail-Followup-To: djgpp-workers AT delorie DOT com
References: <3791-Sat03Feb2001142127+0200-eliz AT is DOT elta DOT co DOT il>
Mime-Version: 1.0
User-Agent: Mutt/1.3.12i
In-Reply-To: <3791-Sat03Feb2001142127+0200-eliz@is.elta.co.il>; from eliz@is.elta.co.il on Sat, Feb 03, 2001 at 02:21:28PM +0200
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Sat, Feb 03, 2001 at 02:21:28PM +0200, Eli Zaretskii wrote:
> 
> Comments?

> +typedef signed char int_fast8_t;
> +typedef unsigned char uint_fast8_t;

Unless I am severely mistaken:

If fast_t types are supposed to be the fastest ones
for a given size, maybe it's better to use int?
typedef signed int int_fast8_t
We don't waste a lot of memory (alignment wastes it anyway), 
and operations with 32-bits ints are faster than with 8-bits ints.

> +typedef signed int int_fast16_t;
> +typedef unsigned int uint_fast16_t;

Likewise there. The performance loss for using 16-bit integers
in 32-bit code is even bigger.

Laurynas

- Raw text -


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