Can/should the C language be extended to better support vector processors and GPGPU?
Tell HN: C Experts Panel – Ask us anything about C
421–430 of 978 posts
Re: Tell HN: C Experts Panel – Ask us anything about C
#422Earlier quoted context omitted.
It would presumably involve a new type that didn't exist in the current ABI. Those pointers would stay the same, and the new (twice as big) pointers would be used for the array feature.
The point of uintptr_t is that it's an integer type to which any pointer type can be cast. If you introduce a new class of pointers which are not compatible with uintptr_t, then suddenly you have pointers which are not pointers.
Ditto uintmax_t. We do not want a uintmax2_t.
Re: Tell HN: C Experts Panel – Ask us anything about C
#423Earlier quoted context omitted.
Fat pointers in C would involve an ABI break for existing code, in that uintptr_t and uintmax_t would probably need to double in size.
Existing code would be using normal pointers, not fat pointers, so there would be no ABI break. New code using fat pointers would know that they fit into a pair of uintptr_t, so the size of uintptr_t would not need to change either.
I don't think we want a uintptr_t and uintptr2_t.
Re: Tell HN: C Experts Panel – Ask us anything about C
#424Are there any plans to "clean up C"? A lot of effort has been put into alternative languages, which are great, but there is still a lot of momentum with C, and it seems that a lot of improvements that could be done in a backwards compatible way and without introducing much in the way of complexity. For example: - Locking down some categories of "undefined behaviour" to be "implementation defined" instead. - Proper ar…
> Proper array support (which passes around the length along with the data pointer). I second this one. One of the best things from Rust is its "fat pointers", which combine a (pointer, length) or a (pointer, vtable) pair as a single unit. When you pass an array or string slice to a function, under the covers the Rust compiler passes a pair of arguments, but to the programmer they act as if they were a single thing (…
The C family has already evolved in this direction decades ago. Have you heard of C++ (Cee Plus Plus)?
It is production-ready; if you want a dialect of C with arrays that know their length, you can use C++. If you wanted a dialect of C in 1993 with arrays that know their length for use in a production app you could also have used C++ then.
The problem with all these "can we add X to C" is that there is always an implicit "... but please let us not add Y, Z and W, because that would start to turn C into C++, which we all agree that we definitely don't want or need."
The kicker is that everyone wants a different X.
Elsewhere in this thread, I noticed someone is asking for namespace { } and so it goes.
C++ is the result --- is that version of the C language --- where most of the crazy "can you add this to C" proposals have converged and materialized. "Yes" was said to a lot of proposals over the years. C++ users had to accept features they don't like that other people wanted, and had to learn them so they could understand C++ programs in the wild, not just their own programs.
Re: Tell HN: C Experts Panel – Ask us anything about C
#425A couple of (I hope easy) requests -
1. Can we add separators in constants (C++ does 0xFFFF'FFFF'FFFF'FFFF any other reasonable scheme is fine too?)
2. I think many compilers already do this, but can the static initialization rules be relaxed a bit?
static const int a = 0;
static const int b = a; /* This is not standard C afaik. */
Re: Tell HN: C Experts Panel – Ask us anything about C
#426Earlier quoted context omitted.
I would say that the committee does pay attention to hardware variations, even when there are no examples of existing hardware that implement a feature (for example, a trap representation for integers other than _Bool). Some of the thinking is that "if it was ever implemented in hardware, it could be again). I'm not crazy about this thinking, and I largely think that language features for which there are no existing…
Some example of hardware variation (since you mentioned shifting and overflow): - signed integer overflow or division by zero occurs, a division instruction traps on x86, while it silently produces an undefined result on PowerPC - left-shifting a 32-bit one by 32 bits yields 0 on ARM and PowerPC, but 1 on x86; - left-shifting a 32-bit one by 64 bits yields 0 on ARM, but 1 on x86 and PowerPC
On x86 it's actually mixed: scalar shifts behave as you describe, but vectorised logical shifts flush to zero when the shift amount is greater than the element size!
So x86 actually has both behaviors in one box (three behaviors if you could the 32-bit and 64-bit scalar things you mentioned separately).
This is an example of where UB for simple operations actually helps even on a single hardware platform: it allows efficient vectorization.
Re: Tell HN: C Experts Panel – Ask us anything about C
#427Is there a chance to ever see C++-template-like features appear in C?
For instance, a lot of redundant code (or ugly macro business) could be neatly replaced by function templates. Even just template functions with only POD values allowed would be a great readability improvement.
Re: Tell HN: C Experts Panel – Ask us anything about C
#428Does the following code fragment cause undefined behaviour? unsigned int x; x -= x; There's a lengthy StackOverflow thread where various C language-lawyers disagree on what the spec has to say about trap values, and under what circumstances reading an uninitialised variable causes UB. I'd appreciate an authoritative answer. Thanks for dropping by on HN! https://stackoverflow.com/q/11962457/
This example is clearly UB.
You could argue that it suddenly becomes less UB if you take the address of x:
unsigned int x;
&x;
x -= x;
So the short answer is that, for all intent and purposes, you should consider use of uninitialized variables as UB, because C compilers already do. (There exists somewhere a document clarifying what C compilers can and cannot do with indeterminate values. A search for “wobbly values” might turn it up. Anyway, you do not want to have wobbly values in your C programs any more than you want it to have undefined behavior.)
Re: Tell HN: C Experts Panel – Ask us anything about C
#429Earlier quoted context omitted.
UTF-8 encoding works "as is" based on byte strings (char[]). The latest versions of the draft standard provide somewhat more support. I recommend heading toward a future where only UTF-8 encoding is used for multibyte characters and UCS-2 or similar for wchar_t. There is no need to support several different encodings.
UCS-2 is a bad choice -- it fails to represent most unicode characters. If you meant UTF-16, that's also a bad choice, because UTF-16 is also a variable width encoding, forcing programmers to use a some for of "extra-wide char". I'm of the opinion that wchar_t should become an alias for char32_t.
Yes, I meant the 31-bit code point value (more than 16, anyway). It is the most useful width for doing things with wide characters.
Re: Tell HN: C Experts Panel – Ask us anything about C
#430Earlier quoted context omitted.
Thanks for your answers. A related question: this article [0] appears to single out memcpy and memmove as being special regarding effective type. Is it accurate? It seems to be at odds with your suggestion that there's nothing stopping me writing my own memcpy provided I'm careful to use the right types. [0] https://en.cppreference.com/w/c/language/object#Effective_ty...
memcpy and memmove aren't special. The part that discusses the copying of allocated objects is 6.5, p6, quoted below: The effective type of an object for an access to its stored value is the declared type of the object, if any. If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object f…
I see, so in short the article is failing to reflect this excerpt: or is copied as an array of character type. Thanks again.