News for hackers. Stuff that matters.
Re:A comprehensive guide to 50 years of evolution of strict ... by everslick on Friday November 26, 2021 @02:57AM (#29348247)
what's wrong with that?
Re:A comprehensive guide to 50 years of evolution of strict ... by wruza on Friday November 26, 2021 @04:30AM (#29348698)

  *a++
doesn’t increment the value pointed to by `a`, it increments `a` itself. The value remains intact.
Re:A comprehensive guide to 50 years of evolution of strict ... by jacquesm on Friday November 26, 2021 @03:21AM (#29348360)

   int increment(a)

   {
      return a+1;
   }

   void somefunc()

   {
       int b = 5;

       b = increment(b);

       printf("b now %d\n", b);
   }
Re:A comprehensive guide to 50 years of evolution of strict ... by everslick on Friday November 26, 2021 @03:50AM (#29348475)
that exact example is given in the document and presented as 1 of 2 possible solutions. I believe, the critique in the parent comment was unwarranted, but I thought I maybe missed something.
Re:A comprehensive guide to 50 years of evolution of strict ... by jacquesm on Friday November 26, 2021 @03:57AM (#29348515)
This is the only proper way of doing that. Having pointers to variables on input that functions modify is ugly and error prone. C gets a lot better the moment you try to make your functions as pure as you can.
Re:A comprehensive guide to 50 years of evolution of strict ... by wruza on Friday November 26, 2021 @04:45AM (#29348774)
What do you think of

  T get_t(int how, char **error);
  int get_val(T *v);
One could rewrite these as

  struct get_t_res {T; char *};
  struct get_t_res get_t(int);

  struct get_val_res {int; T};
  struct get_val_res get_val();
But what do you think of it?
Re:A comprehensive guide to 50 years of evolution of strict ... by jacquesm on Friday November 26, 2021 @04:52AM (#29348824)
Less clear. I much prefer for functions to do what's on the tin in the most simple way possible.
Re:A comprehensive guide to 50 years of evolution of strict ... by jcelerier on Friday November 26, 2021 @04:12AM (#29348589)
As long as you don't return structs, as the compiler may introduce memcpys here. C doesn't have C++'s RVO, last time I checked many cases that GCC and Clang did optimize in C++ weren't optimized in C.
Re:A comprehensive guide to 50 years of evolution of strict ... by pjmlp on Friday November 26, 2021 @09:01AM (#29350231)
True, but still one way I appreciate making C safer is by using poor man's Abstract Data Types with translation units.

For the use cases that are too expensive to use functions, macros can be used instead.

However that is only if C++ cannot be used at all, otherwise don't bother.

Re:A comprehensive guide to 50 years of evolution of strict ... by jacquesm on Friday November 26, 2021 @11:03AM (#29351350)
That works, at the expense of possibly hiding bugs in plain sight. Macros are a double edged sword in that sense, you can almost but not quite create a DSL on top of C that is a lot more safe but it has its drawbacks, and you need to be very good at mentally modeling macro expansion to read and debug code like that in order to ensure that it does what it seems to be saying that it will do.
Re:A comprehensive guide to 50 years of evolution of strict ... by pjmlp on Friday November 26, 2021 @11:33AM (#29351646)
Agree, if it is me, I rather use inline functions, but anyway as mentioned only use C when there is no other option.
Re:A comprehensive guide to 50 years of evolution of strict ... by tpush on Friday November 26, 2021 @04:29AM (#29348693)
Do you have an example of that where C++ struct returns are optimized but not C ones?
Re:A comprehensive guide to 50 years of evolution of strict ... by jcelerier on Friday November 26, 2021 @06:57AM (#29349443)
enjoy: https://gcc.godbolt.org/z/7Pn8eqhdK

that's latest GCC, at -O3

Re:A comprehensive guide to 50 years of evolution of strict ... by moonchild on Saturday November 27, 2021 @03:12AM (#29358502)
Clang does generate good code https://gcc.godbolt.org/z/z781r7Phh

But yes, sadly I think it's still generally advisable to avoid returning large structs by value.

Note that this has nothing to do with RVO; as I understand it, RVO is about eliding copy constructors, not actual memory copies, and c has no copy constructors and so gets 'RVO' in all cases.

Re:A comprehensive guide to 50 years of evolution of strict ... by rep_movsd on Friday November 26, 2021 @12:50PM (#29352335)
Should be `(*a)++`

Noob mistake