What is isize_t?
Modern C and What We Can Learn from It [video]
121–130 of 132 posts
Re: Modern C and What We Can Learn from It [video]
#122Earlier quoted context omitted.
> Out parameters are mostly a legacy feature from the time when C compilers didn't allow struct return values though, or implemented this inefficiently (besides, out parameters via pointers works too). ah yes, that legacy, age-old GCC 11 compiler https://gcc.godbolt.org/z/rYsxxTxqd
Wow. The function produces identical code when inlined, so why does the C version require that memcpy when it's not inlined?
because C++ allows RVO and not C (as this is technically a change in behaviour as one may instrument memcpy - there are also a few cases where the copying of the return value of a function is observable so this does not fall under the default "as-if" rule of optimization)
Re: Modern C and What We Can Learn from It [video]
#123Earlier quoted context omitted.
>The reason (I believe) is that complex things are like hard drugs for smart people. >That is the golden explanation I kind of understood internally but never formulated consciously. I am thinking would it be fair to say C++ are for the wicked smart but C are for ones with age old wisdom.
Some more: Any problem has many possible solutions, but only one (well... few) are simplest. It doesn't take much intelligence to write complicated code, this is just finding "a" solution. Finding simple solution requires understanding of range of all possible solutions or at least a lot of them, understanding what makes them simple, and selecting the one that is simplest. If you are smart and want to show it, why no…
One problem is these sort of simple solutions are hard to judge by seniors for your bonus.
Part of Resume Driven Development problem?
Re: Modern C and What We Can Learn from It [video]
#124Earlier quoted context omitted.
> The problem with C++ is that many of those "features" are actually "anti-features". From the top of my head: operator overloading, copy-constructors, constructors, destructors, function overloading. While these "features" may make correct code easier to write, they always make incorrect code much, much harder to understand. > For example, you find a simple line of C++ that says "y=f(x);", and it can do anything: ha…
>I have yet to see any of this be an actual problem in real-world projects Just on Monday, I was bitten by a bug caused by operator overloading. I'm building a static analysis tool in C++. There's a method `getType()` that returns the qualified type of an expression. I had a call to `getType()` nested in some other calls, e.g. `expr->asAssignmentExpr()->getRHS()->getType()->getSomeQualifiedTypeProperty()`. The creato…
> So, I just needed to write `expr->asAssignmentExpr()->getRHS()->getType().getSomeQualifiedTypeProperty()`.
with any decent IDE you'd type something like
expr.as.get.get.get
so I fail to see how this can be an issue if you don't use prehistoric tooling
Re: Modern C and What We Can Learn from It [video]
#125Earlier quoted context omitted.
Wow. The function produces identical code when inlined, so why does the C version require that memcpy when it's not inlined?
because C++ allows RVO and not C (as this is technically a change in behaviour as one may instrument memcpy - there are also a few cases where the copying of the return value of a function is observable so this does not fall under the default "as-if" rule of optimization)
Clang produces identical code between C++ and C:
https://gcc.godbolt.org/z/vWqn4s5ev
I don't think that C disallows RVO, gcc just might be more conservative there (maybe because of special Linux requirements)?
Re: Modern C and What We Can Learn from It [video]
#126Earlier quoted context omitted.
> If you can program C well, C++ isn't going to be too much of a problem for you. I only agree that understanding C helps somewhat , e.g. by avoiding the traps of not thinking hard about the underlying memory model. But it won't help you with template metaprogramming or how exceptions can break your supposedly memory-safe code: https://herbsutter.com/gotw/_102/
And that's why I am not claiming I know C++. Don't get me wrong, I can read the code, debug it and correct it. But in C++ being able to read the code and understanding consequences of every single line of it are completely different things. There is just so much magic involved that no one ever can claim they fully know C++ and if they do I can safely and provably call them liars and find something they will not be ab…
My main problem with C++ is not that there's a lot to know (although this too). It's something else: even if you know C++ very well, you need a lot of external research to understand a snippet of code.
A single line of C++ can trigger a lot of mechanisms which change the semantics. Overloaded operators, custom allocation, template overloads, copy vs reference - all of this depending on a huge graph of header files.
Re: Modern C and What We Can Learn from It [video]
#127Earlier quoted context omitted.
because C++ allows RVO and not C (as this is technically a change in behaviour as one may instrument memcpy - there are also a few cases where the copying of the return value of a function is observable so this does not fall under the default "as-if" rule of optimization)
Clang produces identical code between C++ and C: https://gcc.godbolt.org/z/vWqn4s5ev I don't think that C disallows RVO, gcc just might be more conservative there (maybe because of special Linux requirements)?
> I don't think that C disallows RVO,
optimizations should never change the output of a program unless explicitely allowed (the as-if rule).
In c++ since RVO is allowed, it is ok for
intptr_t value = 0;
struct foo f() {
struct foo the_foo;
value = (intptr_t)&the_foo;
return the_foo;
}
int main()
{
struct foo the_foo = f();
assert(value == (intptr_t)&the_foo);
}
Re: Modern C and What We Can Learn from It [video]
#128An account of modern C should also note , which came with C99, and makes "sin()" and "cos()" do the right thing w.r.t. argument type (float, double, long double), something that has long been possible in Fortran. In C, this allows you to typedef a "real" type, set to either float or double at compile-time, in order to conveniently explore trade-offs associated with the different floating point precisions. The impleme…
Note that C11 added _Generic to the language, so things like the type-generic functions from tgmath.h can nowadays be implemented in user space.
Although I disagree with some part of the presenter's ideas. I learned struct initializers and _Generic keyword from the presentation. So that is a great win for me. Now I can write safer code with the const and non-const pointer types.
Suppose that I want to return a pointer to a field inside of a struct. Either I had to write const and non-const versions of the same function and use them which brings unreadable code. Or I would have to define argument as const and return non-const pointer which defeats the purpose of const in the first place.
This keyword allows me to use same function name with const and non-const pointers.
Re: Modern C and What We Can Learn from It [video]
#129What is isize_t?
Presenter doesn't give any information about it. But I think it is not a type defined in C standard and presenter's own implementation.
Re: Modern C and What We Can Learn from It [video]
#130Earlier quoted context omitted.
Note that C11 added _Generic to the language, so things like the type-generic functions from tgmath.h can nowadays be implemented in user space.
Although I disagree with some part of the presenter's ideas. I learned struct initializers and _Generic keyword from the presentation. So that is a great win for me. Now I can write safer code with the const and non-const pointer types. Suppose that I want to return a pointer to a field inside of a struct. Either I had to write const and non-const versions of the same function and use them which brings unreadable cod…
I just noticed your comment and I'm intrigued. Can you explain more or give a tiny example of this const/non-const flexibility?