The problem with size_t

"Nick Keighley" <> wrote in message
news:97013c69-ef44-44f9-93f7-...
> On 17 Oct, 04:42, "Tech07" <tec...@nospam.hia> wrote:
>> jacob navia wrote:
>
>
>> > I am implementing the bitstring type in the container library, and
>> > obviously I store the number of bits in a size_t...
>>
>> > Problem is, in 64 bit versions, size_t grows to 8 bytes, what
>> > is an absolute overkill for a number that in most cases will
>> > fit in 16 bits, or, at most 32.
>>
>> Ummm, maybe don't use size_t?? ("If it hurts, don't do that!"). I think
>> your
>> design constraints (whether self-imposed or unknowing) are wasting your
>> time.
>>
>> > And this happens in all containers. I do not see most applications
>> > use containers with more than 4G elements... In a 64 bit system
>> > size_t is just too much waste.
>>
>> > Now I see the problems Malcom was pointing at when he ranted at
>> > size_t.
>> > What would be the alternatives?
>>
>> > uin32_t?
>>
>> > That one looks better. Any problem with that?
>>
>> The problem is that you only speak C and you "can't see the forrest for
>> the
>> trees". (I'm not picking on you, it's just that you look <something>
>> in
>> that silly "C Member's Only" jacket in 2009). Update your wardrobe!
>
> I'll proably regret this...
>
> You've made a few comments like this about Jacob's proposed library
> (and other things)

at least I am consistent.

>but you seem to be lacking in detail.

You want details, I want a million dollars.

> Jacob is
> trying to implement container classes for C.

I think he has already done so (?).

> Is he going about it the
> wrong way?

Isn't "container library in/for C" an oxymoron?

> What should he do?

He'll be/do just fine. What you "should do", I cannot (or decline to) help
you with.

> Is it a mistake to try and add
> containers to C?

She can get in those prissy pumps.... with a SHOEHORN! "we" used to make
"drawrings" of the teacher's feet trying to escape "her" shoes. "containers
in C" is like "bikini on a fat woman": Ewww!


> What should he do instead?

He can decide what to do and doesn't need you holding his hand. (Not that
there is anything wrong with that. I'm really tough and have been called
"abrasive" (amongst other things)).

> Is he unnecessarily
> constraining himself by only considering standard C types?

'Twas my opinion obviously if you've ever read me.

> What should
> he do instead?

I have no problem with him or what he is doing.

> Should he invent a special container_size_t type?

And wheel you around in your wheelchair giving up his life?!
>
>
>
>

Tech07

On 18 Oct, 09:03, "Tech07" <tec...@nospam.hia> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> wrote in message
> news:97013c69-ef44-44f9-93f7-...
> > On 17 Oct, 04:42, "Tech07" <tec...@nospam.hia> wrote:
> >> jacob navia wrote:

> > I'll probably regret this...

....and I did. I attempted on to engage Tech07 in a sensible discussion
about his opinions of Jacob's container library. As usual Tech07
prefers vague waffle to substantive discussion.


> > You've made a few comments like this about Jacob's proposed library
> > (and other things)
>
> at least I am consistent.
>
> >but you seem to be lacking in detail.
>
> You want details, I want a million dollars.

and it continues in a similar vein

<snip>

Nick Keighley

Joe Wright wrote:
> bartc wrote:
>> "Joe Wright" <> wrote in message
>> news: ...
>>> By what magic do you expand a 32-bit address bus (4GB) to 35 or more
>>> bits? Are you using x86 processors or some other? Enquiring Minds..
>>
>> Processors can have more physical address bits than those available to
>> a particular task, for example 40 address pins but only 32-bits of
>> addressing in a task.
>>
> Theoretically I suppose. Are there any servers sold today with such
> capability?

x86 servers have had 32-bit virtual/linear addresses but 36-bit physical
addresses for years; look up PAE.

x86-64 processors present a 32-bit virtual/linear address to 32-bit
tasks, but have physical addresses of up to 52 bits. (AMD and/or Intel
will need to define yet another page table level or two to reach a full
64 bits.) IIRC, current implementations don't go past 40 bits.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

Stephen Sprunk

On Oct 16, 10:31*am, pac...@kosh.dhis.org (Alan Curry) wrote:
> A terabyte should be enough for anyone

Off-topic: N.Y. Times published an article recently mentioning
petabyte-sized data (maybe Facebook's image collection or some such);
it defined "petabyte" as 1000 terabytes but didn't define terabyte.

It wasn't so very long ago that "megabyte" would need definition in
a general-audience newspaper article and even technies might not
have heard of "gigabyte"!

I remember my Dad coming home from work 43 years ago excited about
data processing's first terabyte-sized "random access" memory!
He said there were only two installations. It was only many years
later I learned there'd been a third installation ... in Langley,
Virg.

James

James Dow Allen

James Dow Allen <> wrote:

> On Oct 16, 10:31=A0am, pac...@kosh.dhis.org (Alan Curry) wrote:
> > A terabyte should be enough for anyone
>
> Off-topic: N.Y. Times published an article recently mentioning
> petabyte-sized data (maybe Facebook's image collection or some such);
> it defined "petabyte" as 1000 terabytes but didn't define terabyte.
>
> It wasn't so very long ago that "megabyte" would need definition in
> a general-audience newspaper article and even technies might not
> have heard of "gigabyte"!

When I hear that, I think Knuth should have gone farther with his
Potzrebie system, or even better, given it up for a futile job.

Richard

Richard Bos

>*IIRC, current implementations don't go past 40 bits.
AMD K10 go up to 48-bit.

yuhong