next topic »

[Reply #15 on:]

having to learn the basics of templates

I personally would prefer that Arduino NOT become overly full of C++isms.

[Reply #16 on:]

The only difference to an end user is calling functions where parameters go in '<>' rather than '()', This is incredibly simple even for a novice.

I don't see how the bugs imposed on #defines are a trade off for secure guaranteed execution of a well defined template.
This would save mass amounts of headaches.

C is great but C++ is better*



*this is my own opinion, Moved from C to C++ and never looked back.

[Reply #17 on:]

This only works for gcc as it is a gcc extension. Does anybody use anything else...

Good question.  The Arduino folks are trying to add support for more processor types (like ARM).  There is a possibility that a non-GCC compiler may come into play.

[Reply #18 on:]

I don't see how the bugs imposed on #defines are a trade off for secure guaranteed execution of a well defined template.
This would save mass amounts of headaches.

I believe that a final solution needs to work for both C and C++

There are no "bugs imposed on #defines"
The existing bugs in the min/max/abs() macros are there because the implementation is too simplistic
and silently generates unintended code.
It is no different than having a bug in your  main line code.
The solution is to simply fix the code.
These simplistic macros started showing up in the early to mid 80s and I've hated them
ever since. They go back to the days before there was much optimization, before function prototypes
and even inline functions and were an attempt to generate faster code.

About macros in general:
there are some things that you can do with macros that cannot be done in any other way.

--- bill

[Reply #19 on:]

Technically unexpected behaviour is a bug.
Documentation specifying the 'unexpected behaviour' makes it an 'undefined behaviour' and explicitly leaves it to the programmer to investigate, this however is not the case.

Vastly different to having an explicitly defined error in your own code.

However I agree, the solution needs to be workable in C & C++.

that is as easy as a #ifdef  for the C++ define, which leaves reason to provide a safer version when possible.

[Reply #20 on:]

However I agree, the solution needs to be workable in C...

Why does the solution need to work in C ?

[Reply #21 on:]

Why does the solution need to work in C ?

Haha, it doesn't. GCC is capable of both. I'm only trying to conform to the masses that do not want to migrate to C++

My main point at this stage is whatever comes out of this, the macros as is now should be rolled up and smoked. I would prefer using long winded template meta programming for replacing everything 'macro' that inline functions cannot do, but I assume this would receive negative responses too.

[Reply #22 on:]

This only works for gcc as it is a gcc extension. Does anybody use anything else...

Good question.  The Arduino folks are trying to add support for more processor types (like ARM).  There is a possibility that a non-GCC compiler may come into play.

Really? What other no cost ARM compiler is out there
that works as well as gcc? Is there one?

[Reply #23 on:]

Technically unexpected behaviour is a bug.
Documentation specifying the 'unexpected behaviour' makes it an 'undefined behaviour' and explicitly leaves it to the programmer to investigate, this however is not the case.

Vastly different to having an explicitly defined error in your own code.

However I agree, the solution needs to be workable in C & C++.

that is as easy as a #ifdef  for the C++ define, which leaves reason to provide a safer version when possible.

The C language has alot of unexpected behaviors that do not qualify as bugs as there
are many folks that are not intimately familiar with many of the low level details around
precedence, char type handling and promotion.

In this case I did say it was a bug.
No different than a math library generating an incorrect sine value or floating point calculation.
The bug just happens to be in system supplied code rather than a users code.

There is no need to punish the C code in favor of C++ when looking for solutions
especially when, as I've shown, it is possible to write better macros that work
properly for both C and C++


--- bill

[Reply #24 on:]

@bperrybap:  Are you claiming that the Arduino folks, for the foreseeable future, will only be using GCC?

[Reply #25 on:]

I also have not seen any modern free optimising compilers that do not support C++ apart from non standard implementations. I'm sure they exist, but are their optimisations worth a grain of salt.

[Reply #26 on:]

@bperrybap:  Are you claiming that the Arduino folks, for the foreseeable future, will only be using GCC?

No. I have no information either way.

But given the low cost availability and realibility of gcc for so many different platforms including
ARM, it seemed like a natural fit.

I also read a thread over on the diydrones site about ardupilot from back in Sep 2011.
There was some Arduino and Atmel bashing going on.
Massimo Banzi made a comment about having an ARM environment with gdb up and working with a new IDE
prototype.

http://diydrones.com/profiles/blogs/arm-arduino-coming?id=705844%3ABlogPost%3A645017&page=4#comments

Seems to at least "smell" like gcc is going to be solution for the foreseeable future.

--- bill

[Reply #27 on:]

I believe that a final solution needs to work for both C and C++

Why for C?

[Reply #28 on:]

I believe that a final solution needs to work for both C and C++

Why for C?

Why create a C++ only solution?

Not everything in Arduino is C++
There is core code that is C and there are some libraries that use C++ wrappers on top of C code.

[Reply #29 on:]

Why create a C++ only solution?

At this point, there is no reason not to.

Not everything in Arduino is C++ ... There is core code that is C

The list is short...
  WInterrupts.c
  wiring.c
  wiring_analog.c
  wiring_digital.c
  wiring_pulse.c
  wiring_shift.c

and there are some libraries that use C++ wrappers on top of C code.

The list is even shorter...
  twi.c


None of those modules use the macros in question.


Why does the solution need to work for C?