601–610 of 978 posts
Earlier quoted context omitted.
typedef struct {uint8_t *data; size_t len;} ByteBuf; is the first line of code I write in a C project.
That's a really bizarre layout for your struct. Why don't you put the length first?
Will Effective C cover the strict aliasing rule and also why the BSD sockets API seems to get away with it (e.g. (sockaddr *) &sockaddr_in)?
Why not mandate a warning every time the compiler detects and makes use of UB? It would solve SO many issues. If you are looking to improve security of C programs, then letting the user know what the compiler does should be number one.
Try to convert as many UB's to Platform specific, as possible would also be a big help.
I would love to see native vector types. Its time. Vector types are now more common in hardware then float was when it was included in the C spec. Time to make it a native type. Hoping the compiler does the vectorization for you is not good enough.
Allow for more then one break.
for(i = 0; i is equal to:
for(i = 0; i < n; i++) for(j = 0; j < n; j++) if(array[i][j] == x) goto found; found :
struct foo {
enum { t_char, t_int, t_ptr, /* .. */ } type;
int count;
union {
char c[];
int i[];
void *p[];
/* .. */
};
};
Furthermore, you can't work around this by wrapping the union's members in a struct because they must have more than one named member:
struct foo {
enum { t_char, t_int, t_ptr } type;
int count;
union { /* not allowed! */
struct { char c[]; };
struct { int i[]; };
struct { void *p[]; };
};
};
struct foo {
enum { t_char, t_int, t_ptr } type;
int count;
union { /* this works but is silly and redundant */
struct { int dumb1; char c[]; };
struct { int dumb2; int i[]; };
struct { int dumb3; void *p[]; };
};
};
union { char c; int i; void *p; } u[];
Earlier quoted context omitted.
typedef struct {uint8_t *data; size_t len;} ByteBuf; is the first line of code I write in a C project.
That's a really bizarre layout for your struct. Why don't you put the length first?
A possible tiny advantage for this layout is that a pointer to this struct can be used as a pointer to a pointer-to-bytes, without having to adjust it. Although i'm not sure that's not undefined behaviour.
Why is still the learning curve for C so high? * Why can't the learning curve be solved using tools? * Why don't we actively promote more higher level languages which are implemented in C (by fewer people)?
So I don't think C has a very high learning curve, C++ on the other hand...
1. How likely are named constants of any types to be included in C2x? I'm referring to the idea of making register const values be usable in constant expressions. 2. Is there, or was there ever a proposal to make struct types without a tag be structurally typed? This would not break backwards compatibility as far as I can see, and would make these types much more useful as ad-hoc bags of data. Small example: struct {…
3. would have to be a new mechanism for variadic functions, that would have to be distinguished in header files from the old mechanism with which it is incompatible. So this proposal would imply some new keyword or syntax. I am not in the committee, but I don't think this is going to happen. The improvement is way too incremental to force a new syntax. (The committee is fine with incremental improvements, but new syn…
Earlier quoted context omitted.
> 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 impl…
C++ doesn't have arrays which know their length.
1. How likely are named constants of any types to be included in C2x? I'm referring to the idea of making register const values be usable in constant expressions. 2. Is there, or was there ever a proposal to make struct types without a tag be structurally typed? This would not break backwards compatibility as far as I can see, and would make these types much more useful as ad-hoc bags of data. Small example: struct {…
1. I want this too.
2. Here is my proposal: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2366.pdf
3. Yes, variadic functions should be improved.
Thanks for the AMA 1. Will the Apple's Blocks extension, which allows creation of Closures and Lambda functions, be included in C2X? 2. Are there any plans to improve the _Generic interface (to make it easy to switch on multiple arguements, etc.)?