Embedded Systems October 2000 Vol13_11

Issue link:

Contents of this Issue


Page 39 of 181

The C and C++ languages do not give you many choices when it comes to representing scalar variables. You basically have two choices: integer 01' floating point. TABLE 1 Scale factor 10-9 10-6 10-3 10-2 10-1 10 102 103 106 109 . ••• . - Prefix nano micro milli centi deci mega giga S mbol n 1.1 m c deka (or decal da hecto kilo d h k M G Orbite r th at thrus t sho uld be ex pressed in pounds. If th ey had checked th e design docume n t, th ey would have found othe rwise. The problem of units in software The C and C++ languages do nOL give you many choices whe n it comes to re presenting scalar variables. You basi- cally have two choices: in teger o r floaLing poin t. The language makes no a sumptions about what th e data represents, so you get no complaints from th e compi le r when you do things like: • Assign uni ts of one type to a vari- able in different units; for example, "length = time" • Add or subtract variables that al-e not in the same uni ts; for example, "length = length + time" • Multiply or divide variables in d if- fe rent units and store the resul t in a variable in the wrong units; for example, "frequency = time/ cycles" In a nutshell , what we need to defIn e is a unique scalar type fo r each uni t of measure, such as length or time, Lhat is derived from one of the native scalar Lypes (in t, double, floaL). The goal is to defin e some simple rules and let the compiler enforce them. Some languages, like Ada, have this ability bui lt-in . Once you defin e your own scalar L ype, an Ada compiler won't allow you to mix up the math unless you explicitly instruct it to do so. Unfortunately, this is not so u-ivial in C and C++. The typedef keyword, which pro- vides the simples t way to define your own scalar type in C and C++, creates nothing more than an ali as. The com- piler doesn 't care if you mix up an expression using a "mete r_type" and a "second_type," as long as they al-e both scalars. In mOSL cases you won 't get a warning, much less an errOI -. To make matters worse, program checkers like I in t do n 't care abo ut user-defi ned scalar L ypes eithe r l You may as well just use the preprocessor. The next logical step is to defin e a class, but tllat opens up a new can of worms. In C++ a class cannot inherit from a scalar. For instance, the follow- ing C++ statement will not compile: cLass METER : doubLe {}; II Does not compiLe If you want to create your own scalar class, you must seLtle fo r sometlling like the fo llowing: cLass METER { doubLe vaLue; }; This is unfortunate because now the compiler knows absolu tely noth- ing about scalar operations for this cl ass. Yo u must wr ite code fo r every scalar operation, including several you may not have tllought of. For instance, in addition to writing operato r metll- ods for "+", " - ", and so o n, you must supply the code to perform all L ype conversions, which are necessary to evaluate a simple expression like the following: veLocity = (METERS_PER_SEC) meters I (METERS_PER_SEC) seconds; You have to defin e a method for 38 OCTOBER 2000 Embedded Systems Programming the METERS_PER_SEC typecast in both tile METERS type and the SECONDS type. You also have to provide vario us con- structo rs and as ignment operators before Lhis class wi ll wo rk li ke a plain scalar. A complete example wo uld take several pages and can be found in the fi r t reference at the end of this article. I'm sure you can find one in you r favori te C++ textbook. You will also have to revise these classes regu- larly to provide access to new derived units. This is not a low maintenance solution. All we wanted was for the compiler to enforce better Lype checking of scalars. BUL L O do tllat we are fo rced to wri te lots of extra code that adds no value to the application. As if that weren 'L bad enough, using a scalar class such as this will produce ineffi- cient code. It fo rces tile compiler to insert a call to a conSLructor o r meth od whe re it would normally insert a single machine instruction. Even with inli ne code and aggressive optimization, I doubt tllaL tllis code could ever be as efficient as code wri t- ten wiLh plain scalars. For me, the ultimate q uesti o n regarding a solution like this is "does it add value to the code?" I have tllree simple C1iteria I use for deciding if a solution adds value: • Does iL reduce tile amount of code tllat must be written? Fewer lines of code means fewer opportunities for bugs • Is iL low main tenance? Code tl1aL has to be constan tly modified L O accommodate every a pplicatio n does not help. The act of modi fy- ing th e code in troduces more opportunities fo r bugs • Is it easy to understand? If you can live with high main tenance code, it had bette r be easy to understand. The more difficulL iL is to under- stand the easier it is to make a mis- take when "main taining" it. A kludge solution that works well for o nly one application is not much of a solution

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems October 2000 Vol13_11