[HN Gopher] C23: A Slightly Better C
___________________________________________________________________
C23: A Slightly Better C
Author : mfiguiere
Score : 158 points
Date : 2024-01-21 19:23 UTC (3 hours ago)
(HTM) web link (lemire.me)
(TXT) w3m dump (lemire.me)
| z_open wrote:
| The auto keyword seems like a strange addition given it's already
| a C keyword with a different meaning and this change won't help
| developers that much. It's more useful in C++.
| masklinn wrote:
| It's more useful in C++ with things like generic and voldemort
| types, but I still would not discount it in C as the lack of
| namespacing impacts type names, and it could limit convenience
| typedefs (those which exist only to avoid the `struct` and
| `enum` prefixes). It might also help transitioning to fixed
| integer types, which are rather verbose.
| kevin_thibedeau wrote:
| C has generics as well. This permits the return type of
| generic functions to be preserved.
| jcranmer wrote:
| The only generic feature C has is the _Generic expression,
| which isn't a function, but closer to a switch(typeof(x))
| expression.
| kevin_thibedeau wrote:
| _Generic can be used to merge a collection of functions.
| CyberDildonics wrote:
| That's not the same as being able to write a data
| structure that takes any type.
| kevin_thibedeau wrote:
| It's still generic. You don't have to have feature parity
| with C++ to meet that bar.
| CyberDildonics wrote:
| That would be like calling function overloading generics.
| neutrono wrote:
| It should have been called _Overload or something
| similar, since it's not really a generic.
| rightbyte wrote:
| Hah. Voldemort types. The ones that can't be named (in
| practice becouse too long to fit on a line or remember)?
| gpderetta wrote:
| Also because they might be a) an undocumented
| implementation detail (the result of std::bind for
| example); b) utterly unutterable like the type of a lambda
| expression.
| masklinn wrote:
| > The ones that can't be named (in practice becouse too
| long to fit on a line or remember)?
|
| Nah those are easy to name, just annoying, it's types which
| literally don't have an external / public name, like
| lambdas, or locally defined types.
| bheadmaster wrote:
| It's actually a struct that only has a name in the scope of
| the function which returns `auto`, and thus cannot be named
| outside of it. Like this: #include
| <iostream> auto createVoldemortType(int value)
| { struct Voldemort { int value;
| }; return Voldemort{value}; }
| int main() { auto voldemort =
| createVoldemortType(7); std::cout <<
| voldemort.value << std::endl; // output: 7 }
| krater23 wrote:
| This way to code is a good reason to make auto the same
| tabu as goto.
| trealira wrote:
| I wonder how much this complicates parsing C++. Because
| of this, you can't discard/free struct and class
| definitions as soon as you leave the scope, like you can
| in C, because the definition can still escape the scope
| by being returned from a function with the "auto"
| keyword.
| humanrebar wrote:
| The entities and their destructors still have names that
| the compiler and linker understand. Programs just can't
| name them.
| anthomtb wrote:
| Are there any publicly-viewable C codebases that make use of
| pre-C23 auto? When I learned C (2003-ish) auto vs. register was
| at best a footnote that came up when discussing static.
|
| I agree that you don't need auto pointers in C the way you do
| in C++. C++ type names can get so cumbersome...much easier to
| let the compiler figure it out for you.
| trealira wrote:
| It could help in generic macros, like this:
| #define SWAP(var1, var2) do { \ auto tmp = var1; \
| var1 = var2; \ var2 = tmp; \ } while (0)
|
| Previously, you would have needed a third macro for the type,
| or you would have needed to do a byteswap to be generic.
| unwind wrote:
| True, and now we also get typeof() so there is more than one
| way! const typeof(var1) tmp = var1;
| kstrauser wrote:
| Why's that inside do/while?
| asplake wrote:
| To scope the temporaries?
| peterfirefly wrote:
| No, a block would be enough for that. It's to make ;
| handling natural when the macro is used.
| glouwbug wrote:
| Forces the use of a semicolon:
|
| SWAP(...);
| trealira wrote:
| If you simply put braces around it, you'd generate
| syntactically invalid code when you don't use braces for
| if-else statements.
|
| Consider this: if (e) SWAP(a, b);
| else something_else();
|
| Currently, that expands to this, which is still valid code:
| if (e) do { // ...macro...
| } while(0); else something_else();
|
| If it were just wrapped in braces, the code would be parsed
| like this: // One-armed if-statement
| if (e) { // ...macro... } //
| Empty statement ; // Another statement
| else something_else();
|
| It's incorrect syntax to start a statement with else, so
| the compiler will say something like "Unexpected 'else' at
| line N."
| kstrauser wrote:
| I would not have come up with that on my own. Thanks for
| the explanation!
| trealira wrote:
| No problem! I didn't come up with it on my own, either. I
| simply read it somewhere, and now I'm repeating it.
| _kst_ wrote:
| https://www.c-faq.com/ question 10.4
|
| "What's the best way to write a multi-statement macro?"
| Conscat wrote:
| It standardizes existing common practice. Everyone already has
| `__auto_type` macros, but nearly nobody was using `auto` as a
| synonym for `int`.
| Karellen wrote:
| > If you have GCC 23 or LLVM (Clang) 16
|
| gcc 23? That doesn't sound right
| quincepie wrote:
| probably meant 13
| kevin_thibedeau wrote:
| The eighth line uses the static_assert keyword, which is a
| feature of C++11
|
| C11 already had _Static_assert() and static_assert() in assert.h
| jwolfe wrote:
| That's already noted at the end:
|
| > The idea behind static_assert is great. You run a check that
| has no impact on the performance of the software, and may even
| help it. It is cheap and it can catch nasty bugs. It is not new
| to C, but adopting the C++ syntax is a good idea.
| Brian_K_White wrote:
| fta "It is not new to C, but adopting the C++ syntax is a good
| idea."
| zeckalpha wrote:
| Did that work at compile time?
| jonathrg wrote:
| What would it mean for _Static_assert to not work at compile
| time?
| hmry wrote:
| The keyword is new though
| mgaunard wrote:
| C++ is already a better C.
|
| So much so that new revisions of C are just backporting features
| at this point.
| z_open wrote:
| C++ and C are no longer used for the same types of projects so
| C++ is not a better C.
| pjmlp wrote:
| Until C fixes its string and array story, C++ keeps being a
| better C.
| cyberpunk wrote:
| I just use bstrlib... It's solid and works perfectly..
| pjmlp wrote:
| It is not part of ISO C and that is a big difference.
| mgaunard wrote:
| I think you must be from the 90s -- if so can you share your
| time machine?
|
| All kinds of major projects switched to C++ already, for
| example GCC. All the major new projects, for example LLVM,
| are also in C++ from the get-go.
|
| Even the Linux kernel is considering switching to C++ now.
| leosanchez wrote:
| > Even the Linux kernel is considering switching to C++
| now.
|
| Source?
| mgaunard wrote:
| https://www.phoronix.com/news/CPP-Linux-
| Kernel-2024-Discuss
| franzb wrote:
| https://lore.kernel.org/lkml/3465e0c6-f5b2-4c42-95eb-2936
| 148...
| kleiba wrote:
| I wonder if Linus has changed his views on C++ too in the
| mean time.
|
| http://harmful.cat-v.org/software/c++/linus
| liquid153 wrote:
| No they're not
| rzzzt wrote:
| A weird way to spell "Rust".
| mgaunard wrote:
| I giggled -- thank you.
| riku_iki wrote:
| > Even the Linux kernel is considering switching to C++
| now.
|
| considering doesn't mean it will happen in near future,
| because toolchains/ecosystem is not there, the same is
| applicable for many other projects.
| mgaunard wrote:
| I'm not aware of any toolchain limitations; making the
| kernel compile as C++ is doable with a few trivial
| patches, and the kernel already is heavily GCC-specific,
| which supports both C and C++ to the same level.
| riku_iki wrote:
| software is complex, and you can't be sure until you run
| it in mission critical production.
| janice1999 wrote:
| C++ is a better C in the same way that a Cybertruck is a better
| bicycle.
| PaulDavisThe1st wrote:
| funny, but false.
|
| the only sense in which the relationship between C & C++ is
| like that of a cybertruck to a bicycle is the one in which
| the latter are "transportation devices" and the former are
| "programming languages". there is no particular feature of a
| bicycle represented by a cybertruck other than "it gets you
| somewhere".
| janice1999 wrote:
| Yes, that's literally the point I was making.
| PaulDavisThe1st wrote:
| Sure, but it's wrong. There's a ton of features of C
| present in C++. You might not like the C++ context they
| are present in, but it's nothing at all like the
| cybertruck/bicycle relationship.
| tyree731 wrote:
| Nah. More like C is a bunch of hand tools, and C++ is those
| same hand tools, plus a bunch of power tools. Sure, you could
| just use the hand tools, and hey maybe they even give you a
| better of sense of what you're building at a low level, but
| it's exhausting, and it turns out the power tools are really
| useful.
| janice1999 wrote:
| Some of C++ features are great, as recently discussed on
| the Linux kernel mailing list. However for many of Cs
| usecases, they are not appropriate, like exceptions and
| RAII in embedded. Once you start disabling major features
| those 'power tools' become far less attractive. Also, to
| extend the metaphor, hand tools are usually obvious and
| easy to use while power tools can have very long manuals.
| See for example the 275 page book on just Initilisation in
| C++ [0].
|
| [0] https://www.cppstories.com/2022/cpp-init-book/
| spacechild1 wrote:
| How is RAII a problem on embedded platforms? It is
| basically about scoped cleanup, something you would
| otherwise have to do manually.
| pjmlp wrote:
| I guess some people are happy with a macro Assembler with a
| better syntax than MASM/TASM/NASM/yasm high level macros.
| Xeamek wrote:
| 'just backporting [good] features' doesn't sound that bad when
| c++ is widely considered the most bloated mixture of the good,
| the bad and the ugly that there is.
|
| Maybe the c++ killer will turn out to be just some future,
| modern version of C...
| bluetomcat wrote:
| C++ is a different animal of a language. It is about compile-
| time meta-abstractions that generate a ton of invisible code
| under your feet. It has complex expression semantics and a
| crowded syntax space.
| dzonga wrote:
| quick qn ? for the tinkerers -- is there a language these days
| that nicely interfaces with c i.e able to use all c libraries
| through ffi. without loss of performance or extra fu.
|
| the language being small enough that all basics can be grasped in
| a day.
|
| the language being complete that it will remain the same in 10
| years.
|
| while at the same time being memory safe.
|
| btw I don't think golang applies given the bad ffi story in go.
|
| --- edit btw:: yeah this implies the use of a GC. though it must
| not have massive pauses or stop the world GC.
| umanwizard wrote:
| Zig
| andyjohnson0 wrote:
| I've heard good things about Zig. Interop with C libraries
| seems to be good, and there is some degree of memory safety
| (though not, as i understand it, anything like .net/Java).
| xcdzvyn wrote:
| Zig's probably GP's best bet. Though its still developing
| rapidly, it sees production use already, so while it might be
| radically different in 10 years, it probably won't be gone.
|
| There's also Rust, but that's a little harder.
| Yujf wrote:
| Also not stable, will change a lot afaik
| paulddraper wrote:
| D
|
| [x] nicely interfaces with c
|
| [x] the language being small enough that all basics can be
| grasped in a day
|
| [x] the language being complete that it will remain the same in
| 10 years (the 1.0 release was 23 years ago)
|
| [x] while at the same time being memory safe.
| brabel wrote:
| All points are subjective and many people would claim this is
| false for all bullet points.
|
| > [x] nicely interfaces with c
|
| Unfortunately, that's only if you can avoid D Strings.
| Otherwise, you'll need to use toStringZ which makes copies of
| each string to ensure they have a null terminator.
|
| > [x] the language being small enough that all basics can be
| grasped in a day
|
| I'm still learning new stuff after several weeks using D. The
| basics are indeed simple, but there's A LOT of stuff in D.
|
| > [x] the language being complete that it will remain the
| same in 10 years (the 1.0 release was 23 years ago)
|
| D is evolving slowly but evolving. With the new ideas about
| making parts of the stdlib GC-free and the borrowing concepts
| being slowly introduced, the language is changing... people
| are making a lot of pressure to add new "cool features" from
| other languages, like the recently accepted string
| interpolation proposal. It will not be the same in 10 years,
| but it's true that most of it will be unchanged.
|
| > [x] while at the same time being memory safe.
|
| D is not memory safe by default, you need to use `@safe`
| which is annoying because currently , a lot of the stdlib is
| not `@safe` (but it could be!). It's true it's much, much
| harder to mess up in D than in C, but compared to Rust, I
| think it's quite unsafe (which is why it's introducing
| borrowing, to catch more unsafety bugs).
| paulddraper wrote:
| C strings are just...bad, bad, bad. C++, D, Zig, Go, Rust
| have ALL decided to not use C strings as their primary
| string type. But converting is as simple as a function
| call. (And literals are null terminated)
|
| What features of D are deep?
|
| A feature like string interpolation is modest syntax sugar.
| The kind of change that takes 40 seconds to understand.
|
| > Rust
|
| Bwhahahaha if D is not simple or simple, IDK what to call
| Rust.
| bachmeier wrote:
| > Unfortunately, that's only if you can avoid D Strings.
| Otherwise, you'll need to use toStringZ which makes copies
| of each string to ensure they have a null terminator.
|
| There's nothing that would prevent them from using C
| strings. Since they want a safe language, I doubt this
| would be a reason they don't want to use D.
|
| > I'm still learning new stuff after several weeks using D.
| The basics are indeed simple, but there's A LOT of stuff in
| D.
|
| This is a bad question, because there really is no language
| in 2024 that you can learn everything in a day.
|
| > D is evolving slowly but evolving.
|
| Again, a bad question. Even C is evolving. The main
| complaint about D is that it isn't evolving fast enough,
| with too much emphasis on avoiding breaking changes. If
| they implement editions, it actually would work as OP
| wants, because code that compiles today will compile
| forever in the future.
| qznc wrote:
| Memory safe and easy implies a garbage collector to me.
| Unfortunately, garbage collection and C libraries easy to use
| is at odds.
|
| In other words: Memory safe, easy to learn, easy C-FFI? Pick
| two.
| chc wrote:
| They also wanted "without loss of performance" (compared to
| C, I think, based on the context), which also has tension
| with the other requirements. I don't think it's possible to
| make a memory-safe language that has easy C FFI with no
| overhead and doesn't require you to think about C stuff. The
| esoterica of C have to be addressed somewhere.
| edflsafoiewq wrote:
| LuaJIT
| winrid wrote:
| Nim [0][1], but will obviously evolve in 10 years. Even Java
| will likely deprecate some things in that time... Nim allows
| importing C/C++ OOTB.
|
| [0] https://livebook.manning.com/book/nim-in-
| action/chapter-8/60
|
| [1] https://github.com/nimterop/nimterop
| riku_iki wrote:
| Maybe rust if you ignore all the stuff you think looks
| complicated.
| lolinder wrote:
| The instant that you have hassle-free FFI, it seems like you've
| given up on memory safety. Heck, just yesterday I got a
| segfault in a _Python_ project because a library that I pulled
| in was just a wrapper for a faulty C module.
|
| You can have all the memory safety in the world within the
| bounds of your own language, but it mostly gives you an
| illusion of security if the common pattern in the community is
| to just wrap C libraries. Having FFI be a bit of a hassle can
| actually go a long way towards shaping the community towards
| stronger memory safety.
| odiroot wrote:
| Try V https://vlang.io/
|
| One caveat is still being heavily developed.
| desiderantes wrote:
| Vala?
| akira2501 wrote:
| > while at the same time being memory safe.
|
| lua? luajit's got great ffi.
|
| If you meant a compiled language then you can write code that
| is memory safe in C. You can even run tools against your code
| to measure this in various ways.
|
| All "memory safe" languages that compile to lowest level ISA
| code are just memory safe "by default" and all of them
| necessarily offer escape hatches that turn it all off.
|
| No "memory safe" compiled languages offers memory protections
| beyond what the operating system provides. If it's within the
| memory space of the process you can access it without
| limitation. "Memory safety" can reduce your exploit surface but
| it can't eliminate it out of an incorrectly designed program.
| bitwize wrote:
| If you're willing to tolerate a GC, Gambit Scheme may be the
| closest. You can learn the basics of Scheme in a short time
| (but _any_ programming language will take time to master). The
| C FFI is also pretty straightforward to use, but developing
| complete Scheme interfaces to large C libraries can get
| tedious.
|
| Gambit is also reputed as the second fastest Scheme compiler
| out there; only Chez Scheme produces faster code.
| oconnor663 wrote:
| No there really isn't. The closest thing is "Rust after you've
| already gotten over the learning curve", but I realize that
| that learning curve is why you phrased your question the way
| you did.
|
| Zig is aiming for what you're talking about, but it's not yet
| stable. They're interested in memory safety, but they don't
| want to add a borrow checker and they certainly don't want to
| add a GC, so my outsider guess is that they'll end up
| tolerating memory unsafety and trying to make up for that with
| debug modes and tooling. I don't really have a sense of what
| the end result will feel like, and the problems discussed in
| https://youtu.be/dEIsJPpCZYg make it sound like the basic
| semantics still have a ways to go.
|
| Go could've been the language you're talking about if they'd
| given up on goroutines and just used the C stack, but
| goroutines are arguably the most important feature in the
| entire language, and it's not clear to me that there's a market
| for "Go but worse for network services and better for FFI". It
| would be hard to carve out a niche as a systems programming
| language that's great at making syscalls but can't
| realistically _implement_ a syscall.
| adrusi wrote:
| _while at the same time being memory safe._
|
| memory safety doesn't mean just one thing, but probably it
| requires either a lot of rust-like features, a tracing garbage
| collector, or automatic reference counting.
|
| _the language being small enough that all basics can be
| grasped in a day_
|
| that disqualifies taking the rust-like path.
|
| _able to use all c libraries through ffi. without loss of
| performance or extra fu._
|
| that disqualifies most (all?) advanced tracing gc strategies
|
| _it must not have massive pauses or stop the world GC._
|
| that disqualifies simpler tracing gc strategies
|
| depending on what precisely you're looking for, it's possible
| it might be a pipe dream. but it's also possible you'll find
| what you want in one of D, Nim or Swift. Swift is probably the
| closest to what you want on technical merit, but obviously
| extremely tied to Apple. D and Nim strap you with their
| particular flavor of tracing gc, which may or may not be suited
| to your needs.
| liquid153 wrote:
| No mention of typed enums and nullptr. Small things but makes dev
| experience better
| synergy20 wrote:
| based on https://en.cppreference.com/w/c/compiler_support/23
|
| even the newest clang does not support many of the c23 features.
|
| gcc13 is much better, only a very few c23 are yet to be
| supported.
|
| this is a long standing problem with clang/clang++: they're used
| in many linters and intellisense but they're lagging behind by a
| lot comparing to gcc.
| xxpor wrote:
| >they're used in many linters and intellisense but they're
| lagging behind by a lot comparing to gcc.
|
| Pure speculation, but I wouldn't be surprised if these two were
| directly related to each other. Clang/LLVM is more modular,
| which makes it easy to write new things that integrate it (like
| a linter), but this can slow down adding new things that change
| the data model and external interfaces. GCC is the opposite:
| one big blob that makes it easier to add things since the
| surface area is lower.
| pjmlp wrote:
| Actually it is a mix of factors, companies enjoy their
| downstream forks without contributing to upstream thanks
| license.
|
| Almost all major compiler vendors have migrated to clang
| forks and if they contribute upstream, is on the backend
| side, for their platforms, not fronted changes.
|
| Big contributors like Apple and Google, deciding to refocus
| on their own languages, and current language support being
| good enough for their LLVM use cases.
| ronsor wrote:
| Pelles C for Windows actually supports all (perhaps missing one
| or two) C23 features, even `#embed`.
| slacka wrote:
| All of the features descried in the article are supported by
| clang except maybe for the constexpr keyword. By your own list,
| neither one supports all the features. Also, gcc only supports
| about 4 or 5 features more than gcc, and clang supports a few
| gcc doesn't. Hardly "much better".
| jakearmitage wrote:
| Why no std::string?
| layer8 wrote:
| Memory allocation, interoperability with existing libraries.
| Would require a huge new API and tricky design choices.
| AlectronikLabs wrote:
| Why don't they start to support units instead of these ugly
| header files to finally stop duplicating code? I see this might
| break stuff but you could implement it side by side with the
| preprocessor so old code would continue to work.
| j-krieger wrote:
| why not introduce an "import" keyword and keep the include
| keyword for old headers?
| Gibbon1 wrote:
| Walter Bright says he was able to implement modules in C with
| 10 lines of code. That probably works with C but it'd make C
| incompatible with C++. Most people think that's reason enough
| not to do it. I think breaking compatibility with C++ would be
| like cutting the ropes to a sinking ship to save your own.
| Sebb767 wrote:
| > That probably works with C but it'd make C incompatible
| with C++.
|
| C is not a subset of C++. The simplest example:
|
| > int new = 1;
|
| Perfectly valid C, but not valid C++.
|
| Now, modules would obviously be a bigger break than a few
| keyword incompatibilies, but at that point you'd also
| massively increase complexity and basically start creating
| C++ again, which is probably the actual reason it hasn't
| happened yet.
| Gibbon1 wrote:
| If you listen to the C++ people it's obvious they think the
| incompatible changes are a terrible mistake. They can't
| undo them but they're adamant no other breaking changes be
| allowed. They don't want things to get worse for them.
| Meaning better for everyone else.
|
| And no modules wouldn't make C more like C++. It's just
| make C a bit saner and faster to compile. Because modules
| are complete and don't depend on code compiled before the
| import. Which means you can compile your modules exactly
| once and only once. Well written C code bases you could
| probably just change #include to #import and reap the
| benefits.
| malkia wrote:
| I hoped for defer (e.g. "RAII" of sorts), is there any way?
| oconnor663 wrote:
| There was an update on this just last week:
| https://github.com/ThePhD/future_cxx/issues/67#issuecomment-...
| joshkel wrote:
| According to https://www.open-
| std.org/jtc1/sc22/wg21/docs/papers/2021/p23..., it's an
| "unadopted feature being explored."
|
| There's more information about the proposal at
| https://gustedt.wordpress.com/2022/01/15/a-defer-feature-usi...
| mike_hock wrote:
| > typeof
|
| What was wrong with "decltype"?
|
| Seems utterly bizarre given that the rest is verbatim copypasta
| from C++, even the attribute syntax that sticks out like a sore
| thumb in C, and also given that auto and decl.. I mean, typeof,
| serve no useful purpose in C.
| camel-cdr wrote:
| IIRC behavior is has slightly different behavior, and most
| compilers already support typeof in c.
| hmry wrote:
| Because it has different behavior than decltype. (Isn't that
| why they decided to call it decltype in C++ in the first place?
| To show that it has different behavior than the GCC extension
| typeof?)
| edflsafoiewq wrote:
| https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2927.htm#e...
| Arch-TK wrote:
| "slightly better" - nah, just as mediocre. Let me tell you,
| nobody stuck with C is going to bat an eyelid at this standard.
| They're going to continue using C89, or maybe C99 if they're
| lucky, for whatever reasons that justify it.
|
| People who casually write C don't really care for C23 since it
| fixes all the wrong things. Nobody really wanted C+ (i.e.
| something slightly closer to C++ than before) which is basically
| all this standard achieves.
| JackSlateur wrote:
| Huh ? I use the cleanup attribute, for instance, which is a
| Real game changer
|
| Nobody wants that ? Everybody who knows it exist wants that.
| Arch-TK wrote:
| That's not a C23 feature. It's a non-portable compiler
| extension which has existed for a _long_ time.
| JackSlateur wrote:
| Ha ? Maybe I just woke up in 2023 and get confused :/
|
| Thank you for the correction
| LAC-Tech wrote:
| I remember back in the day everyone insisted C codebases had to
| be C89 so people could compile them in visual studio. EG the
| python interpreter. Is this still the case?
| pjmlp wrote:
| Visual C now does C17, minus the C99 features that became
| optional in C11 like VLAs.
| keithnz wrote:
| Interesting to see they are removing some of the quirkier
| things...
|
| - Remove Trigraphs.
|
| - Remove K&R function definitions/declarations (with no
| information about the function arguments)
| TwentyPosts wrote:
| Wait, no trigraphs anymore???
|
| This is horrible, I loved using `and` and `not` and `or` in C
| boolean expressions and to pretend I'm writing Python code.
| It's fun!
| bombela wrote:
| I find those keywords much more readable, and faster to type
| (qwerty). I also wish Rust had those instead of the weird
| symbols. Oh well, c'est la vie.
| pitaj wrote:
| In Rust you can just use the method call `expr.not()`
| agapon wrote:
| Those are not trigraphs, of course.
| TwentyPosts wrote:
| Really? The Wikipedia article on trigraphs seems to
| disagree. Why do you think so?
| iainmerrick wrote:
| Looks like that article is a general one on two- and
| three-character sequences.
|
| In C, "trigraph" specifically refers to nine special
| sequences beginning with "??":
| https://en.wikipedia.org/wiki/Digraphs_and_trigraphs#C
|
| They were used to provide an alternate way of typing
| punctuation characters for keyboards that don't have them
| (e.g. "??(" is "[").
| trealira wrote:
| Those aren't trigraphs; those are macros defined in the
| <iso646.h> header, like this: #define and &&
| #define not ! /* ... and so on */
|
| In C++, they're actually keywords that are built into the
| language, so you don't need a header then.
|
| When people talk about trigraphs in C, they're talking about
| the trigraphs listed on this page: https://en.cppreference.co
| m/w/c/language/operator_alternativ...
| fuzztester wrote:
| >Remove K&R function definitions/declarations (with no
| information about the function arguments)
|
| Not used C for many years, but used it a lot earlier.
|
| And had read both the first and second editions of the k&r c
| book (ed. 1 pre-ansi, ed. 2 ansi).
|
| based on that, iirc, this:
|
| >Remove K&R function definitions / declarations
|
| should actually be:
|
| function definitions / declarations as in the _first edition_
| of the k &R C book.
| trealira wrote:
| The second edition of K&R distinguishes between them by
| calling the pre-ANSI declarations old-style functions, and
| the ANSI declarations new-style functions. Although, since
| it's not 1989 anymore, they're not exactly new to C either.
| ANSI C has been around for 35 years at this point, whereas in
| 1989, C was only 17 years old.
| parenthesis wrote:
| ckd_add(), ckd_sub() are ckd_mul() are what I'm looking forward
| to using.
___________________________________________________________________
(page generated 2024-01-21 23:00 UTC)