From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a3782bc93aeb7709 X-Google-Attributes: gid103376,public From: rlk@rational.com (Bob Kitzberger) Subject: Re: Just a question... Date: 1996/04/17 Message-ID: <4l3cbg$j24@rational.rational.com>#1/1 X-Deja-AN: 148025929 distribution: world references: <4l32nn$mqn@boson.epita.fr> organization: Rational Software Corporation newsgroups: comp.lang.ada Date: 1996-04-17T00:00:00+00:00 List-Id: : " What are the 3 or 4 advices you would tell to a C programmer who : wants to use Ada ?" - When defining types, learn to think in terms of the problem domain (range, precision, enumeration, etc.) rather than the predefined types (integer, character, etc.). Try to avoid using predefined types directly; define new types that match the problem domain - Forget about the preprocessor, at least initially. Think of alternate ways to solve the problem that you are used to using the preprocessor for (Ada has idioms to handle almost every macro processor usage) - Start thinking in terms of the contract model of programming, i.e. Ada's separation of specification and implementation (body). In C at it's best, a header file is equivalent to the specification, and the .c file is equivalent to the body (I _rarely_ see C code with that high level of quality!) - Use the contract model to hide implementation details: avoid placing type definitions in package specifications (at least for ADTs) instead use private types to defer implementation details to the body. - Do _not_ use the USE clause until you feel comfortable knowing when it's appropriate. These are not intended to ease the transition -- but rather help you learn to program in Ada the way I like it ;-) If you try to program "C in Ada" you will be frustrated, but if you learn the idioms things will be much easier... (holds true for any language, IMHO). -- Bob Kitzberger Rational Software Corporation rlk@rational.com