Blogs >> Technology >>
Can Programming Be Strictly Portable Relative To Language?The activity associated with development of strictly portable methods
The activity associated with development of strictly portable methods of software development will be presented here. Included in this Portability effort will be Windows based C, C++, C#, and Visual Basic; and Linux based C and C++.
FRIDAY: One of the challenges regarding developing a set of portable standards relative to the definition and use of the routines is the fact that an argument can be a variable containing data or a constant. I am currently considering defining variables to contain the constants and then exclusively using variables as arguments. This, on the surface, would appear to be obsessive restrictive. On the other hand, properly done, it would help the source code to be self-documenting.
SATURDAY: I have decided to use variables to contain both numerical and string constants. It will improve the self-documenting properties of the source and will "Simplify and Add Lightness" the development and use of the associated software parts.
SUNDAY: The software parts defining the argument list of a routine has been prepared for CPP.
MONDAY: The software parts defining the end argument list of a routine has been prepared for CPP. The next task associated with the CPP routine software parts library is the implementation of the command values. This set of constants is important relative to the communication between the called routine and the calling routine.
TUESDAY: To properly define the variables used to define the command constants, the scripts defining a routine declaration, routine, and use must be individually defined. It was originally thought that these three scripts were sufficiently similar that a single definition could be used.
WEDNESDAY: I have already made the decision to use a global set of basic data types. This decision has already greatly simplified the software design process and the associated software parts libraries. I am now considering globalism the command and status values.
FRIDAY: One of the challenges regarding developing a set of portable standards relative to the definition and use of the routines is the fact that an argument can be a variable containing data or a constant. I am currently considering defining variables to contain the constants and then exclusively using variables as arguments. This, on the surface, would appear to be obsessive restrictive. On the other hand, properly done, it would help the source code to be self-documenting.
SATURDAY: I have decided to use variables to contain both numerical and string constants. It will improve the self-documenting properties of the source and will "Simplify and Add Lightness" the development and use of the associated software parts.
SUNDAY: The software parts defining the argument list of a routine has been prepared for CPP.
MONDAY: The software parts defining the end argument list of a routine has been prepared for CPP. The next task associated with the CPP routine software parts library is the implementation of the command values. This set of constants is important relative to the communication between the called routine and the calling routine.
TUESDAY: To properly define the variables used to define the command constants, the scripts defining a routine declaration, routine, and use must be individually defined. It was originally thought that these three scripts were sufficiently similar that a single definition could be used.
WEDNESDAY: I have already made the decision to use a global set of basic data types. This decision has already greatly simplified the software design process and the associated software parts libraries. I am now considering globalism the command and status values.
|
|
