Understanding GCC Builtins to Develop Better Tools [pdf]
manuelrigger.at
Understanding GCC Builtins to Develop Better Tools [pdf]
1–10 of 28 posts
Re: Understanding GCC Builtins to Develop Better Tools [pdf]
#2Not a builtin, but a GCC feature which has improved my C code hugely is __attribute__((cleanup)). It is used to specify a destructor for a local variable; when the variable goes out of scope the function is called with a pointer to the variable as an argument.
Example:
{
__attribute__((cleanup(foo)))
int a;
…
/* foo(&a) will implicitly be called here */
}Re: Understanding GCC Builtins to Develop Better Tools [pdf]
#3Not a builtin, but a GCC feature which has improved my C code hugely is __attribute__((cleanup)). It is used to specify a destructor for a local variable; when the variable goes out of scope the function is called with a pointer to the variable as an argument. Example: { __attribute__((cleanup(foo))) int a; … /* foo(&a) will implicitly be called here */ }
It's always funny when C people rediscover parts of C++. Yet they can never admit to it.
Re: Understanding GCC Builtins to Develop Better Tools [pdf]
#4Not a builtin, but a GCC feature which has improved my C code hugely is __attribute__((cleanup)). It is used to specify a destructor for a local variable; when the variable goes out of scope the function is called with a pointer to the variable as an argument. Example: { __attribute__((cleanup(foo))) int a; … /* foo(&a) will implicitly be called here */ }
It's always funny when C people rediscover parts of C++. Yet they can never admit to it.
I write in C only when I need to; in my case I have a limited runtime environment available, so I can't use some other language (which I might otherwise prefer) with a larger runtime requirement, and I also already know C, but not C++. Also, none of the libraries I have to use have C++ APIs. Had I already known C++, and if there were C++ APIs available for the libraries I need, then sure, I might have used C++, but as it is, the results (a C++ program but full of C-style programming because of the APIs) would not be worth the effort of learning C++. C++ also imposes a cost; that of reducing possible contributors to those people who already know C++ – knowledge of C is simply more common than C++.
Re: Understanding GCC Builtins to Develop Better Tools [pdf]
#5Not a builtin, but a GCC feature which has improved my C code hugely is __attribute__((cleanup)). It is used to specify a destructor for a local variable; when the variable goes out of scope the function is called with a pointer to the variable as an argument. Example: { __attribute__((cleanup(foo))) int a; … /* foo(&a) will implicitly be called here */ }
Didn't know this existed. The closest thing I can think of similar to this is `defer` of Golang.
Re: Understanding GCC Builtins to Develop Better Tools [pdf]
#6Earlier quoted context omitted.
It's always funny when C people rediscover parts of C++. Yet they can never admit to it.
I write in C only when I need to; in my case I have a limited runtime environment available, so I can't use some other language (which I might otherwise prefer) with a larger runtime requirement, and I also already know C, but not C++. Also, none of the libraries I have to use have C++ APIs. Had I already known C++, and if there were C++ APIs available for the libraries I need, then sure, I might have used C++, but a…
Your other points are valid, but you can use C++ without any more of a runtime than C needs. The main feature that needs runtime support is exceptions, but it’s common enough to use C++ with exceptions disabled even outside embedded. There’s also global constructors, if you’re not already using them from C with GNU extensions; those can be disabled too if needed, but it’s easy enough to make sure the constructors get invoked (most crt0s should do this out of the box).
Re: Understanding GCC Builtins to Develop Better Tools [pdf]
#7Earlier quoted context omitted.
It's always funny when C people rediscover parts of C++. Yet they can never admit to it.
I write in C only when I need to; in my case I have a limited runtime environment available, so I can't use some other language (which I might otherwise prefer) with a larger runtime requirement, and I also already know C, but not C++. Also, none of the libraries I have to use have C++ APIs. Had I already known C++, and if there were C++ APIs available for the libraries I need, then sure, I might have used C++, but a…
Learning C++ is easy. What's hard is being able to afford a computer that can compile it in a reasonable amount of time.
I've seen projects written in C / Assembly that build over 9,000 objects in about 20 seconds on just one PC, whereas more than a few C++ codebases I've seen in the past couple years, that can be about as long as it takes to build just one file.
I honestly suspect the only folks really writing C++ consistently these days, on things like LLVM, are the ones who work at huge companies, with literal supercomputers devoted to compiling their code, which would prevent them from ever encountering the latency issues that exclude poor folk such as myself from any hope of ever hacking on their codebase. It's sort of like that scene of Agent Smith talking to Neo in the interrogation room: "What good is the source code... if you're unable to build?"
Re: Understanding GCC Builtins to Develop Better Tools [pdf]
#8It'd be great if the GCC devs adopted a process for introducing new builtins, that required code review, unit testing, and justification of use-cases.
Some of the GCC builtin wrappers are outstanding, e.g. __builtin_memcpy on two-power sizes, since it can do things that wouldn't be possible otherwise.
Some GCC builtins, e.g. __builtin_va_start, can take away flexibility since it locks into the core codebase nontrivial code generation that's suboptimal in certain cases.
Most of the builtins are neutral, e.g. atomics api, which provides 42 different ways to say asm("mov"), 13 different ways to say asm("xchg"), and twenty different ways to asm("lock cmpxchg").
Other GCC builtins, e.g. __builtin_ia32_rdrand32_step, don't even have the multi-architecture benefit, only seem to exist because some folks disagree with the asm() keyword, and is naturally problematic from a security standpoint when the GCC devs get it wrong.
What's great about builtins like asm() is it's one simple general-purpose abstraction that puts the power of so many compiler internals into the hands of the user at once, rather than being another narrowly-focused case-by-case feature you need to beseech the core dev team to get.
Re: Understanding GCC Builtins to Develop Better Tools [pdf]
#9Earlier quoted context omitted.
I write in C only when I need to; in my case I have a limited runtime environment available, so I can't use some other language (which I might otherwise prefer) with a larger runtime requirement, and I also already know C, but not C++. Also, none of the libraries I have to use have C++ APIs. Had I already known C++, and if there were C++ APIs available for the libraries I need, then sure, I might have used C++, but a…
Learning C++ is easy. What's hard is being able to afford a computer that can compile it in a reasonable amount of time. I've seen projects written in C / Assembly that build over 9,000 objects in about 20 seconds on just one PC, whereas more than a few C++ codebases I've seen in the past couple years, that can be about as long as it takes to build just one file. I honestly suspect the only folks really writing C++ c…
Maybe take a look at gg [0]? It seems to solve the problem of slow compilation quite nicely.
Re: Understanding GCC Builtins to Develop Better Tools [pdf]
#10It'd be great if the GCC devs adopted a process for introducing new builtins, that required code review, unit testing, and justification of use-cases. Some of the GCC builtin wrappers are outstanding, e.g. __builtin_memcpy on two-power sizes, since it can do things that wouldn't be possible otherwise. Some GCC builtins, e.g. __builtin_va_start, can take away flexibility since it locks into the core codebase nontrivia…
[deleted]