561–570 of 978 posts
- Basic type inference to reduce keystrokes, and prevent ripples when changing types. (like auto in C++)
- Equality operators defined for structs. Perhaps even lexicographical comparison, if I'm dreaming.
Any thoughts on either of those?
A 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. */ Thank you, CodeandC
1. When will we get proper strings in the stdlib? 2. When we will get the Secure Annex K extensions? 3. When we will get mandatory warnings when the compiler decides to throw away statements it thinks it doesn't need? Like memset or assignments. Compilers are getting worse and worse, and certainly not better. ad 1) Strings are Unicode nowadays, not ASCII. Nobody uses wchar but Microsoft. Everybody else is using utf8,…
Going to try to answer these separately. For (1) if you mean strings that are primitive types my guess is never. When had an hour discussion on this topic at a London meeting where we were discussing new features for C11 and my take away was that this would never happen because it would require a significant change to the memory model for the language.
But at least add wcsnorm and wcsfc as I implemented them in the safeclib are required. Not even coreutils, grep, awk, ... can search unicode strings.
And u8 library variants of str* and wcs* are definitely needed, maybe just with uchar* not char*.
A 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. */ Thank you, CodeandC
I'd also say there is consensus that (2) would be beneficial. There are some good ideas in http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2067.pdf although I don't think repurposing the register keyword for it was very popular. Not just because it wouldn't be compatible with C++ which deprecated register some time ago, but also because it's novel with no implementation or user experience behind it. My impression that this is waiting for a new proposal.
The standard string library is still pretty bad. This would have been a much better addition for safe strcpy. Safe strcpy char *stecpy(char *d, const char *s, const char *e) { while (d Existing solutions are still error-prone, requiring continual recalculation of buffer len after each use in a long sequence, when the only thing that matters is where the buffer ends, which is effectively a constant across multiple cal…
*p += sprintf(*p, "hello");
*p += sprintf(*p, "world");C has been making strides towards complete Unicode support. I've been having trouble following along though: Am I correct in assuming that there's no actual multi-byte UTF-8 to UTF-32 Rune function and the best approximation depends on whatever wchar_t is? How would I best handle pure Unicode input and output scenarios on a "hostile" OS whose native character encoding is some EBCDIC abomination or a Windows codepage?
Probably link libicu rather than rely on libc.
Additionally the used UNICODE_MAJOR and _MINOR are needed. They are always years behind, and you never know which tables versions are implemented.
The standard string library is still pretty bad. This would have been a much better addition for safe strcpy. Safe strcpy char *stecpy(char *d, const char *s, const char *e) { while (d Existing solutions are still error-prone, requiring continual recalculation of buffer len after each use in a long sequence, when the only thing that matters is where the buffer ends, which is effectively a constant across multiple cal…
There are many improved versions of string APIs out there, too many in fact to choose from, and most suffer from one flaw or another, depending on one's point of view. Most of my recent proposals to incorporate some that do solve some of the most glaring problems and that have been widely available for a decade or more and are even parts of other standards (POSIX) have been rejected by the committee. I think only mem…
Does anyone have insight on why?
Earlier quoted context omitted.
A good example might be 1's complement signed integers. They were dead weight in the standard for a long time.
Yes, but that is a slightly different question: how long you do you keep something in the standard after all the relevant hardware has disappeared, e.g,. is there a framework for periodically re-evaluating decisions in light of the changing hardware landscape. My question was more about when behavior is being defined for the first time, which admittedly doesn't happen that often (but it could apply e.g., when thing f…
In my view C and C++ now almost different languages with a different philosophy of programming, different future, and different language design.
It will be sad if "modern" C++ almost replace C. Many C++ developers use "Orthodoxy C++" https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b, and this shows that people will be more comfortable with C plus some really useful features(namespaces, generics, etc), but not modern C++. I very often hear from my job colleagues and from many other people who work with C++ is how terrible modern C++ (https://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/, https://www.youtube.com/watch?v=9-_TLTdLGtc) and haw will be good to see and use new C but with some extra features. Maybe time to start thinking about evolution C, for example:
- Generics. Something like generics in Zig, Odin, Rust. etc.
- AST Macros. For example Rust or Lisp macroses, etc.
- Lambda
- Defer statement
- Namespaces
https://ziglang.org/documentation/master/#Generic-Data-Struc...
https://odin-lang.org/docs/overview/#parametric-polymorphism
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 {…