Obviously apart from typing the argument type by hand.
There doesn't seem to be a tick box available to say that you want an argument to be a const. You can select In, Out, or InOut and define a default value. Surely you should be able to say you want the argument const? It is annoying having to untick "Use Existing Type" and then typing the whole type in by hand (with const).

if you have Active Code View open the you can direclty write const before the argument - fastest approach and IN OUT and INOUT the better approach ...

I think it make sense by not having such a checkbox for const
Imaging you would have such a checkbox .. which one should have priority .. the checkbox or the IN OUT property .. ?

Yes, I'd support Mickey's view --- you should not need to specify const if the argument is "In" because it is automatically const. If it's "Out" or "InOut" it shouldn't be const.
By default, classes supplied as arguments are const reference, which works well for us (there are properties to override this for particular classes if you need a different declaration).

I agree that arguments which are classes automatically use const ref but what if the argument is a plain old integer?

Ah, yes, that seems a different use of const from that with classes.
Perhaps we could say, as a general summary, the const that is applied when you pass an instance of a class by reference means that the caller says "I'll let you see this instance, but don't you dare mess with it".
What do you mean by declaring a simple int argument as const?

The predefined types in Rhapsody have always not used const. I think this may have something to do with the attempt to map them onto the language independent Rhp types.

Nevertheless, you could open the PredefinedTypeCpp.sbs file in Rhapsody and change the appropriate property, i.e. CPP_CG:Type:In, which is currently overridden as $type rather than const $type.

Thanks Farquad.

It seems a shame to have to edit the PredefinedTypeC++.sbs every time we change to a new revision of Rhapsody. Do you think it's worth an enhancement request?

I have never used the rhp language independent types. Do you?
It seems a shame that the IN doesn't create a const arg 'out-of-the-box'.

Cheers, shanz

If I may add a further rambling to my question about the meaning of a const int argument, I should point out that defining an int argument as const has no effect on the interface to the operation from the caller. The caller doesn't care whether the operation changes the int argument or not, because int arguments are always passed by value, so cannot affect anything in the caller (different if it's a reference argument, of course). In fact, the C++ specification says that function signatures (i.e. the interface) that only differ by const or volatile are considered equivalent.
The reason that many people use const int arguments is as a self-check on what they write within the implementation of the operation: if you would like the compiler to help you by producing an error when you assign to an int argument, you make it const. The MISRA guidelines support this by saying that "A variable that is not modified shall be const qualified."
So, if the reason for const int arguments is your programming practice, I suggest that this is not something that the Rhapsody default types should impose -- after all, some people may have a different practice and frequently assign to arguments. I preferred the implied suggestion in your first posting of an enhancement to provide some way of defining an argument as const (maybe a check box, maybe a 4th option InConst to avoid the issue Mickey pointed out).
There are related issues here which also relate to the style of programming, for example using typedefs that indicate the size and signedness of basic numerical types (MISRA again). So perhaps what you should do is have a separate package that has your own types, like int32_t for a signed 32-bit int: you can then use properties to make these const by default when they are In arguments. This will then avoid having to edit the PredefinedTypesC++.sbs when you upgrade to a new revision of Rhapsody.
So could you say a little more about the background of why you use const int arguments?

OK, I want to use const arguments for the exact reasons you suspect. It is good programming practice and allows the compiler to catch unintended assignments.

Apparently the next version of Rhapsody (7.5) which is released in June will be mostly MISRA-C++ compliant.

I like your idea about using my own types instead.

One question... I don't understand your point here, "So, if the reason for const int arguments is your programming practice, I suggest that this is not something that the Rhapsody default types should impose -- after all, some people may have a different practice and frequently assign to arguments."

Do you mean that people might not want to use OUT but might still assign to the argument in the function?

Cheers.

Well, I find it a bit difficult to give a convincing reason for assigning to an argument --- I'm with you on getting all possible help from the compiler in detecting my own stupidity.
But I suppose there might be half a reason for it if the argument was a limit on doing something (e.g. number of times to repeat) and in the course of the operation there was a condition that meant that the limit should be reduced. Still might be better to have a specific local variable for this.
My comment was just because I've seen assignment to arguments and would generally prefer that Rhapsody enhancements don't cause existing code to fail to compile.

We always stick to using the Rhp language independent types when modelling at the Systems Level.

We try to make our software portable both wrt RTOS and language so we have an abstract layer, which is effectively an extension of the OSAL provided by Rhapsody. That abstract layer only uses Rhp types. The implementation of the layer may well use language specific types but only if there's no alternative.

I see that MISRA-C++ Rule 3-9-2 (Advisory) recommends using the ISO (POSIX) typedefs, eg: for a 32-bit integer machine :-

typedef signed int int32_t;
typedef signed long int64_t;

etc, ...

So I might create a CodingStandardTypesPkg package and maybe set the General::Model::CommonTypes property to point to this new package of MISRA-C++ compliant types. And I'll set the CPP_CG:Type:In, which is currently overridden as $type, to const $type.

That sounds much better!

What happens when you stop using a 32 bit machine?

To be honest I've never really understood why this is necessary.

I take the view that the only reason you want to force the use of a 32 bit integer is when you are overlaying and therefore use a bit field value. Most of the time you just want an Integer, double etc and the language independent types are named appropriately for this purpose.

// Language independent boolean type supported by Rhapsody.
//## type RhpBoolean
typedef bool RhpBoolean;

// Language independent character type supported by Rhapsody.
//## type RhpCharacter
typedef char RhpCharacter;

// Language independent address type supported by Rhapsody.
//## type RhpAddress
typedef void * RhpAddress;

// Language independent integer type supported by Rhapsody.
//## type RhpInteger
typedef int RhpInteger;

// Language independent positive integer type supported by Rhapsody.
//## type RhpPositive
typedef unsigned int RhpPositive;

// Language independent real number type supported by Rhapsody.
//## type RhpReal
typedef double RhpReal;

// Language independent string type supported by Rhapsody.
//## type RhpString
typedef OMString RhpString;

// Language independent natural number type supported by Rhapsody.
//## type RhpUnlimitedNatural
typedef long RhpUnlimitedNatural;

// Language independent VOID type supported by Rhapsody.
//## type RhpVoid
typedef void RhpVoid;

// Boolean type
//## type OMBoolean
typedef RhpBoolean OMBoolean;

for flogging such an old thread but I've just reread C++ Coding Standards 101 Rules, ... by Sutter & Alexandrescu (Chapter 15 - Use const proactively).

They recommend that when passing by value, to add const to the definition but not the declaration.

Can this be achieved by the code generator or am I stuck with no const at all or const in both the declaration and definition?

Not sure what you mean. I looked this chapter up on the net but I couldn't see what you might be referring to.

As I understand it, if you make a parameter const then it's read-only in the implementation. The definition can't override the declaration can it? Why would you want to do that?