Skip to Main Content
Cloud Platform

This is an IBM Automation portal for Cloud Platform products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Created by Guest
Created on Jan 29, 2013

direction flags not used for C++

Problem description
# use them (in maps to const &) etc
# warn when inconsistant with type decoration (const & not compatible
with in/out)

Idea priority Low
RFE ID 30691
RFE Product Rational Software Architect Real Time Edition
  • Admin
    Osman Burucu
    Jan 19, 2024

    As part of the review process, we strive to be transparent about our intentions with each enhancement suggestion.

    This idea is either outdated or has been implemented in one of the versions. Please check with latest version (V 12.0 at the time of writing)

    The offering team has carefully reviewed this idea and has decided that it does not fit into our current plans, so the idea will be closed. The idea will be kept in IBM's ideas repository and may still be voted on. It might be reassessed or reopened for additional feedback in the future. We value your feedback and thank you for allowing us the privilege of partnering with you in developing our products.

  • Guest
    Sep 24, 2015

    Due to processing by IBM, this request was reassigned to have the following updated attributes:
    Brand - WebSphere
    Product family - Application Platform
    Product - Software Architect Real Time Edition

    For recording keeping, the previous attributes were:
    Brand - Rational
    Product family - Design & development
    Product - Software Architect Real Time Edition

  • Guest
    May 20, 2013

    Ok, this sounds reasonable. Should we let this RFE track the addition of such validation rules in the C++ transform, and then you can open another RFE in the future for the translation of DirectionKind to C++ type "decorations"?

  • Guest
    May 15, 2013

    Feedback from our developer:
    There should be some incremental advances towards greated consistancy.

    Suggest first step be simple UML/transform level validation warning/issues if direction flag inconsistant with type decoration. e.g. if direction is out/in-out then type can't be const; if direction is in, type should be const.

    Some further future iteration could tie model or .tc preferences (const &, const *, etc) to direction flags, but agree we can't leap to that in one step.

  • Guest
    May 3, 2013

    testing email for RFE

  • Guest
    Apr 11, 2013

    I agree this could be nice, but unfortunately this change will make all existing models stop building, so it is a breaking change that needs to be made in a major release and well communicated to all users. What users typically do today is to use the UML DirectionKind as an informal way to specify the intention of a parameter. So if the C++ transform starts to take DirectionKind into consideration, users need to update the type to avoid generating the type specifiers and declarators twice.
    Also, the current scheme is more flexible since it allows a user to implement DirectionKinds in different ways. For example, an In/Out parameter could be implemented either as a reference (C++ style) or as a pointer to a pointer (C style). The user may want to have the control over this which he would loose if the C++ transform decides upon a mapping.

    Given this background, do you still want this RFE to be implemented (the new behavior could be controlled by a preference for backwards compatibility)?

  • Guest
    Feb 7, 2013

    Uncommitted candidate