Re: [Paparazzi-devel] Software architecture design

[Conrado Miranda]

Gautier,

My idea of objects for some parts is to make clearer what needs to be
changed to create a new algorithm. Probably just better documentation
(I know it's an issue in all projects) would suffice, but some parts
of the code ("sw/airborne/math/pprz_algebra_*.h" is an awesome but
isolated example) could clearly benefit from some function overload
and operator implementations.

As for the "I don't like C/C++", I agree it's important to be
comfortable with the language, but it doesn't provide any technical
advantage, which is what I'm interested.

I don't like the idea of starting a new project for two reasons:
1- I do think that paparazzi is an awesome project, but I think the
learning curve could be much more gentle.
2- I don't like reinventing the wheel. I think that's a dumb thing to
do when you don't have some major philosophical problem, which isn't
the case.

I'll definitely contribute with the code latter on. Also, I didn't
knew about the Ivy software bus (I've only used ROS), but it seems
nice too.

Felix,

I have still to work out the details about the compile time stuff...

I do believe that C++ allows more screw-ups in some cases, but if
people would coding without keeping MCU constraints in mind, I don't
see what may possibly stop them from doing so using C. For instance,
line 93 of sw/airborne/math/pprz_algebra_float.h says:

#define FLOAT_ANGLE_NORMALIZE(_a) {       \
    while (_a >  M_PI) _a -= (2.*M_PI);       \
    while (_a < -M_PI) _a += (2.*M_PI);       \
  }

I know this should be an inlined function and this code is bad, but
it's an example of how someone may screw things in C (this code will
produce unexpected and very hard to find bugs in some cases). This
also is an example of a case in which C++ could avoid screw-ups: it's
possible for people to forget to normalize the angle, which may be a
problem when you're dealing with values that are used across modules.

I don't like the idea of dynamic memory allocation in a controller
like this at all (either in C or C++).

Converting the code isn't an option and, in my mind, never was.
However, the C functions interface is already out there and I think it
would be a minor trouble if someone, when refactoring a piece of the
code to improve it, linked the C function with the class. No, it's no
ideal, but it's feasible.

I should also point out that I love C and it's my major language, but
I see some major drawbacks when you're dealing with vectors and stuff
like that. I'm not saying "let's stop doing what we're doing and
refactor the whole code", but I'm suggesting that better documentation
(again yes, I know it's a common issue and I'll definitely contribute
to that latter) and some very specific C++ stuff may be very helpful.

Cheers,

Conrado.

PS: I don't know whether I should send one gigantic e-mail or separate it...

On Thu, Feb 14, 2013 at 10:28 PM, Felix Ruess <address@hidden> wrote:
> Hi,
>
> Gautier has already pointed out some of the reasons why we are using C and
> not C++.
>
> Regarding abstraction/encapsulation and ease of learning the system: I'm not
> really sure that C++ necessarily helps for the overall picture here...
> (Keeping in mind that some of the C stuff is not well written and is being
> refactored whenever there is need and especially time.)
>
> Some more personal remarks (disregarding the all the work that would be
> needed to convert to C++):
>
> Yes, we need to get rid of quite a few macros, a lot can be converted to
> plain (inline) functions directly or just written better in C.
> Quite a few (generated) macros can't be nicely replaced by templates...
> For math functions and the like, function and operator overloading would
> help. And templates...
> Although you have to be careful with templates... (also while most my code
> at work is heavily templated, I hate debugging that stuff)
> While a lot of things that are usually encapsulated in classes can be done
> in C as well, classes are IMHO often a bit nicer to read.
> Most of configuration options, etc.. are designed to be done at compile time
> and not runtime anyway.
> I convinced this is a good idea, as most things you don't want to change in
> flight anyway and
> it means you don't have to deal with the problems that come with runtime
> changes...
>
>
> In C++ you have to be really careful about what functionality you use on an
> MCU system, but it is certainly possible and has it's benefits.
> But also IMHO the potential for (accidental) screwups in C++ is much greater
> and my experience is that once you allow people to use advanced (C++)
> features, they will get used sooner or later without actually keeping the
> MCU constraints in mind. You end up with dynamic memory allocation where you
> didn't expect it, templates quickly get out of hand...
>
> From my standpoint (and in a perfect world) we would use C++, but restrict
> it to a certain subset which is really beneficial for us.
> So while I would like to be able to use some C++ features, I currently don't
> see this happening in paparazzi for two main reasons:
>
> It is a _lot_ of work and not clear if it's worth putting in all that effort
> to convert instead of improving code and providing new features...
> Some core devs prefer C over C++, and hence are not keen to put in time for
> 1.
>
> In the absence of godly intervention to update our codebase in one go, it
> looks like in a lot of cases (e.g. driver encapsulation) incrementally
> writing better C code solves the problems or at least helps a lot....
>
> Regarding python on the ground side:
> There are already a few python implementations (e.g. of the messages tool,
> sim launcher, calibration/visualization scripts, documentation tools).
> Personally I would like to see more of this, as I quite like python... but
> this can easily be done in parallel to the existing tools in most cases...
>
> Cheers, Felix
>
>
> On Thu, Feb 14, 2013 at 11:53 PM, Chris Gough
> <address@hidden> wrote:
>>
>> > And of course, lets do not talk about python in a microcontroller.... xD
>>
>> Other people are:
>>
>> http://code.google.com/p/python-on-a-chip/
>>
>> This is considered most likely choice for a new flight plan scripting
>> language in another autopilot (ahead of lua and squirrel). Python
>> syntax might be nicer to look at but that's all you get,
>> python-on-a-chip isn't "batteries included". The paparazzi flight
>> planning language is awesome.
>>
>> Chris Gough
>>
>> _______________________________________________
>> Paparazzi-devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
>
>
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>