|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> C data types can be real fun once you're leaving the safety of
> mainstream PC architecture :-P
Indeed. Considering that C is supposedly *the* language for writing
low-level code, I find it quite surprising that it provides absolutely
no way to select a binary number of a specific size. It doesn't even
seem to provide a vague suggestion of what size you're going to get;
it's just random pot luck with each compiler you try...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible schrieb:
> Indeed. Considering that C is supposedly *the* language for writing
> low-level code, I find it quite surprising that it provides absolutely
> no way to select a binary number of a specific size.
That's actually its strength... until it comes to interfacing with the
outside world, which is where things tend to get ugly.
Not commonly known, C99 also specifies that <stdint.h> shall contain
typedefs for various integers to be used in case a particular size is
desired:
- intN_t / uintN_t (e.g. int8_t) for exact size:
These are optional, unfortunately, but it makes sense considering that
some architecture may have a bigger smallest-addressable-word size.
- int_leastN_t / uint_leastN_t for a certain minimum size:
These are mandatory at least for 8, 16, 32 and 64 bit.
- int_fastN_t / uint_fastN_t for fastest type of mininum size:
These are mandatory at least for 8, 16, 32 and 64 bit.
> It doesn't even
> seem to provide a vague suggestion of what size you're going to get;
> it's just random pot luck with each compiler you try...
Oh yes, it does: <types.h> gives you all you need to know about your
int, short, long etc.
Well, /almost/ all: For some weird reason nobody seemes to have bothered
mandating a standard #define to figure whether you're on a big-endian or
little-endian machine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Indeed. Considering that C is supposedly *the* language for writing
>> low-level code, I find it quite surprising that it provides absolutely
>> no way to select a binary number of a specific size.
>
> That's actually its strength... until it comes to interfacing with the
> outside world, which is where things tend to get ugly.
And given that currently the number one use for C is to interface with
the outside world... strange choice, that.
> Not commonly known, C99 also specifies that <stdint.h> shall contain
> typedefs for various integers to be used in case a particular size is
> desired:
>
> - intN_t / uintN_t (e.g. int8_t) for exact size:
>
> These are optional, unfortunately, but it makes sense considering that
> some architecture may have a bigger smallest-addressable-word size.
>
> - int_leastN_t / uint_leastN_t for a certain minimum size:
>
> These are mandatory at least for 8, 16, 32 and 64 bit.
>
> - int_fastN_t / uint_fastN_t for fastest type of mininum size:
>
> These are mandatory at least for 8, 16, 32 and 64 bit.
Mmm, interesting. (But, presumably, unused?)
>> It doesn't even seem to provide a vague suggestion of what size you're
>> going to get; it's just random pot luck with each compiler you try...
>
> Oh yes, it does: <types.h> gives you all you need to know about your
> int, short, long etc.
>
> Well, /almost/ all: For some weird reason nobody seemes to have bothered
> mandating a standard #define to figure whether you're on a big-endian or
> little-endian machine.
I don't see anything useful listed - unless I'm looking at the wrong file...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible schrieb:
>> That's actually its strength... until it comes to interfacing with the
>> outside world, which is where things tend to get ugly.
>
> And given that currently the number one use for C is to interface with
> the outside world... strange choice, that.
I'd say its number one use is for embedded systems, which typically have
a very limited interface to the outside world.
> I don't see anything useful listed - unless I'm looking at the wrong
> file...
Oops - you're looking at the wrong file indeed, but that's my fault: Try
<limits.h> instead of <types.h> - sorry :-)
<float.h> does the same for floating-point types, by the way.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 03 Sep 2009 23:00:00 -0700, Chambers wrote:
> Jim Henderson wrote:
>> On Thu, 03 Sep 2009 20:05:56 -0700, Chambers wrote:
>>> You're assuming that you have to understand something to enjoy it. As
>>> exhibit A that this is not the case, may I present "2001"? :)
>>
>> I actually understood that movie, mostly. :-)
>
> Sure, and I did, too... at least, *I* think I did :)
>
> I have a hunch that if you ask five fans what the movie was about,
> you'll get five different answer...
Possibly, but then works of literature often speak differently to
different people....
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 04 Sep 2009 09:35:38 +0100, Stephen wrote:
> On 3 Sep 2009 20:56:26 -0400, Jim Henderson <nos### [at] nospamcom> wrote:
>
>>One of the things that made it interesting was that each table had two
>>printers on it that shared a print queue. The way HG would print, you
>>could end up with half the graphic on one printer, and half on the
>>other. :-)
>
> Oops! :)
Yeah, that was a fun one, but turned out to be a simple solution. Just
had to increase the timeout on the CAPTURE command (this was a NetWare
2.15 system). The systems were slow enough that they'd generate part of
the print out, send it, and then generate the next part. Each part
generally took about 20 seconds to generate, and the default timeout IIRC
was 5 or 10 seconds.
Ah, the good old days. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 04 Sep 2009 09:56:16 +0100, Stephen wrote:
>>Interesting, I hadn't noticed that - but I hadn't really thought to
>>look. :-)
>>
> Do so and report back ;)
Just need one thing - a plane ticket. :-)
> Not necessarily, remember power transmission is 3 phase and the path
> could be between phases.
Hmmm, I hadn't thought about that.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> Bill Pragnell wrote:
>
>> The initial oxide layer. It slows further oxygen access to the bulk
>> beneath.
>> Aluminium oxide is particularly effective at this - many high-temperature
>> alloys are designed with this phenomenon in mind.
>
> The oxide layer also doesn't flake off like, say, iron oxide. So no
> fresh metal is exposed.
>
Unless you expose it to mercury, then it flakes off as fast as it forms.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> The oxide layer also doesn't flake off like, say, iron oxide. So no
>> fresh metal is exposed.
>
> Unless you expose it to mercury, then it flakes off as fast as it forms.
Let us hope the rain doesn't contain any mercury...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Another film thoroughly worth missing - although at least parts of it
> made sense.
What you have to realize is this was a special effects movie. It was the
first time they had realistic zero-G effects. The first use of matte
paintings (where you could see in through the windows of a spaceship that's
actually just a model, for example), and so on.
Watch it again with that in mind, and you realize why they spend 20 or 30
seconds of screen time just filming a floating pen.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |