On 02/05/2014 10:42 AM, Jan Kiszka wrote:
On 2014-02-05 10:36, Philippe Gerum wrote:
On 02/05/2014 10:06 AM, Jan Kiszka wrote:
On 2014-02-05 09:58, Philippe Gerum wrote:
On 02/05/2014 09:49 AM, Jan Kiszka wrote:
On 2014-02-05 09:33, Philippe Gerum wrote:
On 02/04/2014 07:03 PM, Jan Kiszka wrote:
On 2014-02-04 18:53, Philippe Gerum wrote:
On 02/04/2014 06:48 PM, Philippe Gerum wrote:
On 02/04/2014 06:44 PM, Gilles Chanteperdrix wrote:
On 02/04/2014 06:39 PM, Philippe Gerum wrote:
On 02/04/2014 06:32 PM, Gilles Chanteperdrix wrote:
On 02/04/2014 06:27 PM, Philippe Gerum wrote:
If g++ chokes on the initializer part because it is outdated,
then
using
old-fashioned ones may be an option. Actually, I find
macroizing
this
definition quite bad.
static const RT_TASK no_alchemy_task = {
- .handle = 0,
- .thread = 0
+ handle: 0,
+ thread: 0
};
No, the previous version is better, it is standard compliant
C and
C++,
the second version is a gcc extension, which works only when
compiling
C, if I remember correctly.
Recent g++ is happy with both (no -std forced though). But the
former is
allowed by the C++ parser only since recently.
Well, on the other hand:
static const RT_TAKS no_alchemy_task;
Will zero initialized the structure just as well...
In that case you will have the object exist in the .bss.
It turns out that old gcc 4.x releases will create a private bss
entry
for this symbol in any case, which recent ones won't produce
regardless
of the optimizing level (unless I messed up with nm, but it does not
seem so).
Then what is so bad about the symbolic NO_ALCHEMY_TASK? The code
will be
the same anyway.
BTW, there are way more issues with C++ when enabling standard
compliance. Not sure where all the errors come from and if they
easy to
fixing. But I think we should try to be as clean as possible in out
external interfaces.
Mmm, no. I don't want to rush merging all kinds of isolated fixes for
all sorts of pedantic modes. I see the other one following with typeof
constructs, later we will get other changes triggered by other
restrictions on gcc extensions, and this general trend is not
acceptable. The fact that the external API headers still share
portions
with the implementation does not help, but this is not a reason for
downgrading the C dialect of the latter with ugly work arounds.
If you really want to go this way, I suggest that you issue a single,
all-in-one patch making the current code base conforming with the
C/C++
standard you aim at, so that we have a general overview of the
changes.
With that information, we should be able to address strict standard
conformance better, which may involve addressing the
interface/implementation issue with headers.
It's pointless to make the core standard-compliant, C or even C++. But
This has never been considered for sure.
we are exposing an interface that definitely has to be compatible with
C++ (most of my patches) as we do not have control over the user's
toolchain and language (there would be no good reason to restrict it).
And if it is trivial to get the interface even ANSI compliant (last
patch) and also recommended by GCC to do so in libraries, what pain
does
it cause to us to follow this road?
The pain is that we seem to be adding more and more restrictions to the
C dialect usable by the implementation, because of that sharing with the
interface. This is not acceptable.
Were do we restrict us here? Give me one example.
Forcing cast on assigning generic pointers is a restriction, the same
way disabling arithmetic on them is yet another artificial restriction
with absolutely no upside on our side, only obfuscation.
Unfortunately required for ordinary C++ support, not only strict
standard compliance. So it is pointless to moan about it IMHO - unless
we want to drop C++ completely.
Yes, the amount of internals currently exposed via the external headers
should be optimized. But I guess this is something to be done as
cleanup
once the code base, including Mercury, settled a bit more.
This is a copperplate issue, regardless of whether you stack it over the
dual or single kernel system, and in this respect, the copperplate API
is stable (although I really have to document it at some point though).
Well, I can have a look at that patch again and try to get those inline
helpers out of the public. Or are they supposed to be used, directly or
indirectly, by applications?
Some of them may be, such as pvmalloc(), which guarantees a rt-capable,
private memory allocation regardless of the underlying real-time core.
Others won't, such as all of the threadobj_* routines, which are for
API/skin designers instead.
This is the reason why I suggest again to have all the required changes
for building for -ansi/c++11 introduced in place first, without even
trying to move code around, all in a single patch. With that
information, we may then define some coding rules for the exposed API
headers for the future, and possibly rearrange the implementation so
that it is not exposed uselessly to external interfaces.
So you just want me to fold patch 2 and 3 together? I don't fully get it
yet.
I'm asking for a clarification: do you have more patches following these
two? I understood from the past conversation that more work was
required, so I'm assuming you will have. If so, then we may save a lot
of time by seeing the complete change set that would fit the bill for
supporting standard C/C++ restrictions, the way your current port work
seems to require it.
The no_alchemy_task thing is not a dialect issue, so I think it's clear
now.
This issue is only relevant to how smart the compiler you use is with
respect to optimizing the output, when it sees a statically-scoped
variable which is explicitly read-only.
Right, so one of the issue it causes has nothing to do with [strict] C++
compliance.
Which is the reason why I tend to suspect patches claiming about fixing
some perceived ugliness, factual information is better. This construct
is valid, but does not fit well with the gcc release you are aiming at,
which is another issue. Xenomai 3.x does impose minimum requirements on
the compiler/toolchain, including sane/working support of builtin sync
primitives and tls.
In this respect, your patch about no_alchemy_task would have been better
explained by the goal of not depending on too recent optimizers, which
does make sense to me. The language is important so that my limited
mono-neuronal brain can deal with your commit logs.
And the __typeof__ is, IMHO, also clear as gcc clearly recommends
to use the underscore version in public headers. And that's all.
I don't have any issue with using the alternative keywords to please
compilers switched to pedantic mode, just like I'm usually preferring
__asm__ over asm in code. The fact that I'm arguing about some of the
proposed changes toward supporting -ansi or -std=<whatever>, does not
mean that I'm asking for all changes to be dropped mindlessly.
Again, the typeof is for ansi, the rest is for [gcc-]C++.
By pedantic mode, I do mean strict -ansi. So we basically agree. Again.
--
Philippe.
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
