Live data from Hacker News

Comp.lang.c Frequently Asked Questions

c-faq.com

41–50 of 56 posts

Re: Comp.lang.c Frequently Asked Questions

#41

Earlier quoted context omitted.

This is literally the reason `size_t` was created.

Why isn't it called index_t then?

I think the next (or current - I've lost track) version of C++ has an idx_t type which is an unsigned int of some sort, which will be the recommended type for for loops.

Re: Comp.lang.c Frequently Asked Questions

#42
post #39
post #27

Earlier quoted context omitted.

Modern C (from C99 onward) introduces a few families of sized types -- [u]int[_least|_fast|][8|16|32|64]_t. The non-least-or-fast types are not guaranteed to exist (e.g., int8_t is optional because implementation may be unreasonable on a 24-bit DSP with no sub-word operations), but the _least and _fast types are generally what you want anyway, unless you're relying on unsigned overflow behavior. In my experience, mod…

> bit-packing with int_fast8_t allows you to represent I assume you meant `int_least8_t`?

Either is valid, but int_fast8_t is more meaningful, in my mind. Using an int_fast8_t encourages the compiler to use the fastest representation, except when explicitly bit-packed. When the value is pulled into a register it's probably not going to matter (unless the compiler is doing something quite silly with regards to handling unsigned overflow for a uint*), but it means that spilling it to the stack, etc, will prefer word-sized operations (which may or may not be preferred, but is my default). Meanwhile, the bit packing is fully specifying the representation when the struct containing the value is written to memory, so there's no distinction between _fast and _least here.

Re: Comp.lang.c Frequently Asked Questions

#43

Earlier quoted context omitted.

As a fellow student of "why is this named that, what does this name mean" I have found that asking about counterfactuals is rarely satisfying. Naming stuff is hard and the question assumed a level of intent that I think is rarely present. Asking "how did this thing get named that" works out better, cause it seems that occasionally gets written down.

My point was that it seems more likely that size_t was created to represent sizes than to represent indexes. I don't disagree that size_t is an appropriate type for indexes, but I don't think indexes are literally the reason it was created.

Well, my point is that "more likely" and "more reasonable" are rarely reasons why things were done in the first place so using the benefit of hindsight to try and suss out cause and effect will frequently lead you to plausible but incorrect answers (specifically for the history and naming of things).

Then again, being wrong about something seems faster than asking a question, and this little thread has already unearthed interesting answers, so maybe you have the right of it!

Re: Comp.lang.c Frequently Asked Questions

#44

Earlier quoted context omitted.

My point was that it seems more likely that size_t was created to represent sizes than to represent indexes. I don't disagree that size_t is an appropriate type for indexes, but I don't think indexes are literally the reason it was created.

It's named for sizeof, a C operator which returns a positive integer but annoyingly the core C language itself doesn't define what the type of that integer is, the standard library does though, naming it size_t Now, sizeof does measure the size of things, but, one of the obvious sizes you can measure is an array†, and that's definitely also the maximum index value for the array, so I do think it's fair to say that's…

The core language says that the result of sizeof is size_t, defined in (and other headers).

size_t is a typedef (alias) for an implementation-defined unsigned integer type.

It could have been worded differently with the same meaning. For example, the core language (section 6 of the standard) could have said that sizeof yields a result of an implementation-defined unsigned integer type without referring to "size_t". The library section (section 7) already says that size_t "is the unsigned integer type of the result of the sizeof operator". Personally I think that referring to size_t in the language section adds clarity, even if it's slightly redundant.

In a given implementation, a compiler might arrange for sizeof to yield a result of type unsigned long, for example. The corresponding header must then define size_t as unsigned long for the implementation to be correct.

Re: Comp.lang.c Frequently Asked Questions

#45
I often cite section 6. It's the best explanation I've found of the (often confusing and counterintuitive) relationship between arrays and pointers in C.

If you think arrays are really pointers, you need to read section 6 of the FAQ.

Re: Comp.lang.c Frequently Asked Questions

#46

Earlier quoted context omitted.

Why isn't it called index_t then?

I think the next (or current - I've lost track) version of C++ has an idx_t type which is an unsigned int of some sort, which will be the recommended type for for loops.

I don't see a reference to "idx_t" anywhere in the latest draft of the C++ standard.

Re: Comp.lang.c Frequently Asked Questions

#49
post #46

Earlier quoted context omitted.

I think the next (or current - I've lost track) version of C++ has an idx_t type which is an unsigned int of some sort, which will be the recommended type for for loops.

I don't see a reference to "idx_t" anywhere in the latest draft of the C++ standard.

Yep, I can't find anything either - I thought I read it four or five years ago in an interview with someone big in the C++ community.

Re: Comp.lang.c Frequently Asked Questions

#50

Earlier quoted context omitted.

As a fellow student of "why is this named that, what does this name mean" I have found that asking about counterfactuals is rarely satisfying. Naming stuff is hard and the question assumed a level of intent that I think is rarely present. Asking "how did this thing get named that" works out better, cause it seems that occasionally gets written down.

My point was that it seems more likely that size_t was created to represent sizes than to represent indexes. I don't disagree that size_t is an appropriate type for indexes, but I don't think indexes are literally the reason it was created.

I agree and disagree. Yes it was created for size. But when indexing std::vector you can index up to the size, and thus should use the same type for both.
Post reply on HN