JSF++

Since I got flamed for mentioning MISRA C++ the other week I though I
would ask first.

Can I post a link to the Word version JSF++ or is that against the
c.l.c++ rules as well?

Chris


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

re: JSF++

Chris Hills wrote:[color=blue]
> Since I got flamed for mentioning MISRA C++ the other week I though I
> would ask first.
>
> Can I post a link to the Word version JSF++ or is that against the
> c.l.c++ rules as well?
>
> Chris
>
>
> --
> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
> /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/[/color]

This group is not moderated. As a consequence, it is up to yourself as
to what you consider topical - and you risk getting flamed.
I believe MISRA C++ should be topical here, but my knowledge of MISRA
is limited.
If you believe JSF++ is topical and if your ego can take a flame, I
would post it.

/Peter

re: JSF++

peter koch wrote:[color=blue]
> Chris Hills wrote:[color=green]
>> Since I got flamed for mentioning MISRA C++ the other week I though I
>> would ask first.
>>
>> Can I post a link to the Word version JSF++ or is that against the
>> c.l.c++ rules as well?[/color][/color]

The new version of Java Sever Faces, AKA Shale, AKA Struts2, AKA
StrutsShale? :P (not the ESE link in google)
[color=blue]
> This group is not moderated. As a consequence, it is up to yourself as
> to what you consider topical - and you risk getting flamed.
> I believe MISRA C++ should be topical here, but my knowledge of MISRA
> is limited.
> If you believe JSF++ is topical and if your ego can take a flame, I
> would post it.[/color]

Knowing Chris, I'm sure he'd survive.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

re: JSF++

In article <4416c830$0$3321$6d36acad@taz.nntpserver.com>, Ben Pope
<benpope81_REMOVE_@gmail.com> writes[color=blue]
>peter koch wrote:[color=green]
>> Chris Hills wrote:[color=darkred]
>>> Since I got flamed for mentioning MISRA C++ the other week I though I
>>> would ask first.
>>>
>>> Can I post a link to the Word version JSF++ or is that against the
>>> c.l.c++ rules as well?[/color][/color]
>
>The new version of Java Sever Faces, AKA Shale, AKA Struts2, AKA
>StrutsShale? :P (not the ESE link in google)[/color]

Joint Strike Fighter ++ the JSF C++ coding guide. Up until now it has
been Restricted under US National Security Rules (in case AQ start
hacking into the JSF as it flies :-)

URL: http://www.jsf.mil/downloads/down_documentation.htm
File: JSF_AV_C++_Coding_Standards_Rev_C.doc

It will do until the release of MISRA C++ :-)

[color=blue][color=green]
>> This group is not moderated. As a consequence, it is up to yourself as
>> to what you consider topical - and you risk getting flamed.
>> I believe MISRA C++ should be topical here, but my knowledge of MISRA
>> is limited.
>> If you believe JSF++ is topical and if your ego can take a flame, I
>> would post it.[/color]
>
>Knowing Chris, I'm sure he'd survive.
>
>Ben Pope[/color]

I am a shy delicate flower wot is sensitive and easily hurt :-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

re: JSF++

Chris Hills wrote:[color=blue]
> In article <4416c830$0$3321$6d36acad@taz.nntpserver.com>, Ben Pope
> <benpope81_REMOVE_@gmail.com> writes
>[color=green]
>>peter koch wrote:
>>[color=darkred]
>>>Chris Hills wrote:
>>>
>>>>Since I got flamed for mentioning MISRA C++ the other week I though I
>>>>would ask first.
>>>>
>>>>Can I post a link to the Word version JSF++ or is that against the
>>>>c.l.c++ rules as well?[/color]
>>
>>The new version of Java Sever Faces, AKA Shale, AKA Struts2, AKA
>>StrutsShale? :P (not the ESE link in google)[/color]
>
>
> Joint Strike Fighter ++ the JSF C++ coding guide. Up until now it has
> been Restricted under US National Security Rules (in case AQ start
> hacking into the JSF as it flies :-)
>
> URL: http://www.jsf.mil/downloads/down_documentation.htm
> File: JSF_AV_C++_Coding_Standards_Rev_C.doc
>
> It will do until the release of MISRA C++ :-)[/color]

I, for one, would love to see some review/discussion of this document.
It looks fairly complete and thorough.

Joe

re: JSF++

Joe Van Dyk wrote:[color=blue]
> I, for one, would love to see some review/discussion of this document.
> It looks fairly complete and thorough.[/color]

Some of the rules are bad due to tool-based restrictions. For example,
try/catch/throw is banned. They don't mention the use of anonymous
namespaces to restrict visibility. They recommend the use of some
custom Array class instead of std::vector, etc...

re: JSF++

red floyd wrote:[color=blue]
> Joe Van Dyk wrote:
>[color=green]
>> I, for one, would love to see some review/discussion of this document.
>> It looks fairly complete and thorough.[/color]
>
>
> Some of the rules are bad due to tool-based restrictions. For example,
> try/catch/throw is banned. They don't mention the use of anonymous
> namespaces to restrict visibility. They recommend the use of some
> custom Array class instead of std::vector, etc...
>[/color]

Why do they recommend the custom Array class? And what do you mean by
"tool-based restrictions?"

re: JSF++

Joe Van Dyk wrote:[color=blue]
> red floyd wrote:[color=green]
>>
>> Some of the rules are bad due to tool-based restrictions. For
>> example, try/catch/throw is banned. They don't mention the use of
>> anonymous namespaces to restrict visibility. They recommend the use
>> of some custom Array class instead of std::vector, etc...
>>[/color]
>
> Why do they recommend the custom Array class? And what do you mean by
> "tool-based restrictions?"[/color]

tool-based restrictions: their compiler doesn't support it.

"AV Rule 208
C++ exceptions shall not be used (i.e. throw, catch and try shall not be
used.)
Rationale: Tool support is not adequate at this time."

As for use of a custom Array class, they didn't specify why to use that
instead of std::vector. My guess is that JSF began before C98 became
official, and they already had an Array class written.

re: JSF++

The standard attempts to balance many competing interests. So, why no
exceptions?

Remember the JSF will not fly on a desktop machine, but rather on
specialized hardware. Moreover, the bsp, operating system, run-time
environment, libraries, etc. must be certified to DO-178B level A
standards or higher (very costly). Hence, you can't just pull your
favorite compiler off the shelf and use it. Given the above
restrictions, your choices are limited. The particular tool suite did
not support exceptions, rtti, etc. Hence the rule. (Note the commercial
version of the tool suite does support these capabilities--the DO-178B
level A version does not).

As more companies begin to use C++ in aviation, hopefully the
certifiable versions of the libraries will be expanded. When that
happens, you will probably see the rule go away.

Now, why the "custom" Array class? Again, it is a balance of
competing interests. The c-style array has long been a source of
errors, especially when used in interfaces. You encounter the so-called
"array-decay" problem. The std::vector is an excellent alternative in
many cases, but not all. The standard containers make use of dynamic
memory. However, extensive heap usage can subject a system to
fragmentation and subsequent determinism issues.

The JSF must operate within hard real-time constraints and guarantee
memory exhaustion can never happen. Consequently, the Array class was
developed as a c-style array alternative that can operate under a hard
real-time environment while eliminating typical problems associated
with c-style arrays. The philosophy is to provide "safer" alternatives
to known "unsafe" or "error-prone" structures.

In summary, some rules will seem odd at first glance. However, the
context of the JSF development environment will hopefully shed a little
light on the subject. Not all rules will be appropriate for all
environments (e.g. use exceptions where you can), but this may be a
good starting place for other safety-critical, hard real-time work.

re: JSF++

kevin.p.carroll@lmco.com wrote:[color=blue]
> Given the above
> restrictions, your choices are limited. The particular tool suite did
> not support exceptions, rtti, etc. Hence the rule. (Note the commercial
> version of the tool suite does support these capabilities--the DO-178B
> level A version does not).
>[/color]
I agree. I said that they were tool-based restrictions -- I assumed the
compiler suite did not support them.
[color=blue]
>
> Now, why the "custom" Array class? Again, it is a balance of
> competing interests. The c-style array has long been a source of
> errors, especially when used in interfaces. You encounter the so-called
> "array-decay" problem. The std::vector is an excellent alternative in
> many cases, but not all. The standard containers make use of dynamic
> memory. However, extensive heap usage can subject a system to
> fragmentation and subsequent determinism issues.
>
> [further discussion redacted][/color]

Good point. I suspect the Array class is similar to std::tr1::array,
i.e. a class with a fixed size array, but bounds checking, etc... I
hadn't thought of that.

re: JSF++

> Good point. I suspect the Array class is similar to std::tr1::array,[color=blue]
> i.e. a class with a fixed size array, but bounds checking, etc...[/color]

Correct.