Ada & C

Ada & C

[A.J. Werner]

Hello,
  I've used Ada for the past 5 years and really got to apply what I know
this past summer.  Now I'm being hired (hopefully) back by the same company
but for a different position.  In this instance, they want me to know MS
Visual C++ and are willing to put me through training to get caught up to
speed (mainly MFCs).  I've had a limited exposure to C++ and only used C a
little bit in my academic career (from which I'm a recent grad).
  I have two books right now for C - "The C Programming Language (2nd Ed. )
by Kernighan and Ritchie" and O'Reilly's "Practical C++ Programming edited
by Steve Oualline"  Aside from pouring over these books, are there any other
books or material that I can purchase for my own library that anyone would
recommend??  Thanks.

-A.J. Werner
http://www.pr.erau.edu

Re: Ada & C

[Robert L. Klungle]

"A.J. Werner" wrote:

> Hello,
>   I've used Ada for the past 5 years and really got to apply what I know
> this past summer.  Now I'm being hired (hopefully) back by the same company
> but for a different position.  In this instance, they want me to know MS
> Visual C++ and are willing to put me through training to get caught up to
> speed (mainly MFCs).  I've had a limited exposure to C++ and only used C a
> little bit in my academic career (from which I'm a recent grad).
>   I have two books right now for C - "The C Programming Language (2nd Ed. )
> by Kernighan and Ritchie" and O'Reilly's "Practical C++ Programming edited
> by Steve Oualline"  Aside from pouring over these books, are there any other
> books or material that I can purchase for my own library that anyone would
> recommend??  Thanks.
>
> -A.J. Werner
> http://www.pr.erau.edu

I would recommend "Programming Windows" by Charles Petzold. Good intro to MFC.
He also has some references.
Available at Crown, etc.

bob

Re: Ada & C

[Brian Rogoff]

> "A.J. Werner" wrote:
> 
> > Hello,
> >   I've used Ada for the past 5 years and really got to apply what I know
> > this past summer.  Now I'm being hired (hopefully) back by the same company
> > but for a different position.  In this instance, they want me to know MS
> > Visual C++ and are willing to put me through training to get caught up to
> > speed (mainly MFCs).  I've had a limited exposure to C++ and only used C a
> > little bit in my academic career (from which I'm a recent grad).
> >   I have two books right now for C - "The C Programming Language (2nd Ed. )
> > by Kernighan and Ritchie" and O'Reilly's "Practical C++ Programming edited
> > by Steve Oualline"  Aside from pouring over these books, are there any other
> > books or material that I can purchase for my own library that anyone would
> > recommend??  Thanks.
> >
> > -A.J. Werner
> > http://www.pr.erau.edu

"Essential C++" by Lippman
"C Interfaces and Implementations" by Hanson

The first book is a quick intro to ISO C++ with an STL focus. 

The second book shows you how to write Ada-like C code, if you haven't
learned already. It also provides a bunch of reusable data structures, 
consistent and well documented. You can check out that books web page at 
http://www.cs.princeton.edu/software/cii/

-- Brian

Re: Ada & C

[Ehud Lamm]

I am not sure I understand from the quoted part in Brian's answer your
exact position (I am experiencing failures in news propagation here, so I
will not wait until the original answer floats this way).

What's your level of experience with C++ and OOP idioms?
If these can be problematic, than you'd better concentrate your efforts on
these. 

What I'd do is read Stroustrup on C++ (still my favorite), the GOF design
patterns book (the example are in C++, and the patterns themselves an
essential part of OOP vocabulary). [Links to patterns on my web page]

"Effective C++" from Scott Meyers, can also prove useful.

Finally, I guess it goes without saying that the place to get answers on
these topics is comp.lang.c/c++.* ;-)

Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!

Re: Ada & C

[Brian Rogoff]

On Sun, 9 Jan 2000, Ehud Lamm wrote:
> Finally, I guess it goes without saying that the place to get answers on
> these topics is comp.lang.c/c++.* ;-)

Perhaps, but I think that there is a lot to be said for adopting an Ada
like style in C (and C++) and selecting books which demonstrate how this can 
be done is helpful for Ada programmers learning C. The comp.lang.c{++}.* 
newsgroups probably don't have the same ratio of people who know Ada and 
C/C++ as comp.lang.ada, since C and C++ are so much more popular. 

Anyone who knows Ada and not C is likely to have to learn it, and C++ too.
It turns out that in the space of programming languages, Ada and C++
occupy a very similar position. 

-- Brian

Re: Ada & C

[Larry Kilgallen]

In article <Pine.BSF.4.21.0001091455020.29083-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> writes:
> On Sun, 9 Jan 2000, Ehud Lamm wrote:
>> Finally, I guess it goes without saying that the place to get answers on
>> these topics is comp.lang.c/c++.* ;-)
> 
> Perhaps, but I think that there is a lot to be said for adopting an Ada
> like style in C (and C++) and selecting books which demonstrate how this can 
> be done is helpful for Ada programmers learning C.

But helping Ada programmers learn C is not the purpose of this newsgroup,
just as helping Ada programmers learn how to change the oil in their
automobile engine is not the purpose.  There will necessarily be some
comparisons with other languages here, but C tutorial efforts belong
in comp.lang.c{++}.*.  Certainly it is better that the folks over there
get experience with questions of how to create true enumerated types :-)

Larry Kilgallen

C question (was: Ada & C)

[Wes Groleau]

> Anyone who knows Ada and not C is likely to have to learn it, and C++ too.
> It turns out that in the space of programming languages, Ada and C++
> occupy a very similar position.

OK, I started learning it long ago, but I only study when I'm forced
to.  :-)

Anyway, I am trying to build c2ada.  I'd like to solve a problem without
getting attacked for the folly of wanting to translate C into Ada, so
I'm asking here instead of in comp.lang.c  :-)

What should I do about this:

gbmsrv1:/usr/tools/bin/c2ada 259 -> make
gcc -g -W -Wimplicit -Wreturn-type -MMD -DDEBUG -DHAVE_CONFIG_H
-I/usr/tools/bin/python1.5/Include -I/usr/tools/bin/python1.5
-DPPATH=\":/usr/tools/bin/python1.5/Lib\"   -c htype.c -o htype.o
In file included from htype.c:6:
printf.h:8: warning: No include path in which to find sys/stdtypes.h
In file included from htype.c:6:
printf.h:11: conflicting types for `fclose'
/usr/include/stdio.h:162: previous declaration of `fclose'
printf.h:12: conflicting types for `fflush'
/usr/include/stdio.h:163: previous declaration of `fflush'
printf.h:13: conflicting types for `fprintf'
/usr/include/stdio.h:169: previous declaration of `fprintf'
printf.h:14: conflicting types for `fputc'
/usr/include/stdio.h:185: previous declaration of `fputc'
printf.h:15: conflicting types for `fputs'
/usr/include/stdio.h:186: previous declaration of `fputs'
printf.h:16: conflicting types for `fwrite'
/usr/include/stdio.h:195: previous declaration of `fwrite'
printf.h:17: conflicting types for `vfprintf'
/usr/include/stdio.h:180: previous declaration of `vfprintf'
printf.h:18: conflicting types for `fscanf'
/usr/include/stdio.h:171: previous declaration of `fscanf'
printf.h:23: conflicting types for `printf'
/usr/include/stdio.h:173: previous declaration of `printf'
printf.h:24: conflicting types for `puts'
/usr/include/stdio.h:192: previous declaration of `puts'
printf.h:25: conflicting types for `rename'
/usr/include/stdio.h:156: previous declaration of `rename'
make: *** [htype.o] Error 1

I suppose I need to change an environment variable or a -I somewhere,
but how do I figure out where and what to change it to?

Re: C question (was: Ada & C)

[David Starner]

On Wed, 12 Jan 2000 15:41:00 -0500, Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:
>
>> Anyone who knows Ada and not C is likely to have to learn it, and C++ too.
>> It turns out that in the space of programming languages, Ada and C++
>> occupy a very similar position.
>
>OK, I started learning it long ago, but I only study when I'm forced
>to.  :-)
>
>Anyway, I am trying to build c2ada.  I'd like to solve a problem without
>getting attacked for the folly of wanting to translate C into Ada, so
>I'm asking here instead of in comp.lang.c  :-)
>
>What should I do about this:
Delete printf.h, and remove all references to it. That got me one more
step before giving up; c2ada is non-trival to build.

One thing that would be appreciated is if someone would take over the
upstream maintnance of c2ada, or, alternately, write a easier to
build version in Ada (the fact that stuff like c2ada was writen in C never
seemed like a great selling point for the language.)

-- 
David Starner - dstarner98@aasaa.ofe.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

Re: C question (was: Ada & C)

[Ted Dennison]

In article <85ipn5$7pu2@news.cis.okstate.edu>,
  dstarner98@aasaa.ofe.org wrote:
> One thing that would be appreciated is if someone would take over the
> upstream maintnance of c2ada, or, alternately, write a easier to
> build version in Ada (the fact that stuff like c2ada was writen in C
> never seemed like a great selling point for the language.)

Hmmm. This sounds like a good application for OpenToken. It currently
only ships with Java and Ada syntaxes, but a C syntax shouldn't be too
tough for someone with an ANSI C standard handy to cobble together. I
actually thought C would be the *first* syntax someone submitted, but up
to now no one seems to have been that interested in C. :-)

lalr(1) parsing capability will be included in the upcomming release. I
have it in the source cleanup and documentation phase right now.

I suppose an easier idea would be to just run c2ada through c2ada. :-)

--
T.E.D.
http://www.telepath.com/~dennison/Ted/TED.html
OpenToken URL -
http://www.telepath.com/~dennison/Ted/OpenToken/OpenToken.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C question (was: Ada & C)

[David Starner]

On Wed, 12 Jan 2000 23:38:47 GMT, Ted Dennison <dennison@telepath.com> wrote:
>> [c2ada not working well]
>Hmmm. This sounds like a good application for OpenToken. It currently
>only ships with Java and Ada syntaxes, but a C syntax shouldn't be too
>tough for someone with an ANSI C standard handy to cobble together. I
>actually thought C would be the *first* syntax someone submitted, but up
>to now no one seems to have been that interested in C. :-)
ANSI C's a bit of a bear to parse, or so I've heard. 

>lalr(1) parsing capability will be included in the upcomming release. I
>have it in the source cleanup and documentation phase right now.
Oh, cool! I'll stop my hacking on Ayacc to get it compile clean, and
wait for OpenToken.

>I suppose an easier idea would be to just run c2ada through c2ada. :-)
Unfortunetly, c2ada mainly works on header files, which is what's really
useful (especially if you listen to Robert Dewar.) It also depends on the
whole of Python being compiled in, which is one of the reasons it's hard
to build.

-- 
David Starner - dstarner98@aasaa.ofe.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

Re: C question (was: Ada & C)

[Ted Dennison]

In article <85j4r7$9qe1@news.cis.okstate.edu>,
  dstarner98@aasaa.ofe.org wrote:

> Unfortunetly, c2ada mainly works on header files, which is what's
> really useful (especially if you listen to Robert Dewar.) It also

I'd agree with that. Thinking about it, for completeness you'd almost
need a full implementation of the C preprocessor. I'm not sure what that
would involve, but it doesn't sound easy to me. Perhaps free access to
the preprocessor was the reason C was used for c2ada.

Perhaps one could cheat a little by requiring the code to first be sent
through the C preprocessor.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C question (was: Ada & C)

[David Starner]

On Thu, 13 Jan 2000 15:08:57 GMT, Ted Dennison <dennison@telepath.com> wrote:
>Perhaps one could cheat a little by requiring the code to first be sent
>through the C preprocessor.
Quite possible. This would prevent you from translating macros, like c2ada
did, and tie you into the specific defines chosen at the time for the header
translation. Which isn't awful, but it prevents translating some of the hairer
headers. 

-- 
David Starner - dstarner98@aasaa.ofe.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

Re: C question (was: Ada & C)

[Keith Thompson]

dvdeug@x8b4e53cd.dhcp.okstate.edu (David Starner) writes:
> On Wed, 12 Jan 2000 23:38:47 GMT, Ted Dennison <dennison@telepath.com> wrote:
> >> [c2ada not working well]
> >Hmmm. This sounds like a good application for OpenToken. It currently
> >only ships with Java and Ada syntaxes, but a C syntax shouldn't be too
> >tough for someone with an ANSI C standard handy to cobble together. I
> >actually thought C would be the *first* syntax someone submitted, but up
> >to now no one seems to have been that interested in C. :-)
> ANSI C's a bit of a bear to parse, or so I've heard. 

Indeed.  The biggest problem is typedef names.  When a typedef is in
scope, the name of the typedef has to be treated as a distinct token,
not as an identifier -- unless it's a new declaration of the same
name.  Thus you have to have feedback from the symbol table to the
parser.  Ick.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: C question (was: Ada & C)

[Ira D. Baxter]

If you have the right parser technology, parsing C is not hard and you
don't need the symbol table immediately.   GLR parsing handles problems
like typedef names by proposing multiple parses: in this case, one
assuming its a typedef name, and the other assuming its a conventional
identifier.
Which can be resolved later, of course, with the symbol table.

We offer reengineering tools that not only parse C, but C++, Ada95,
Fortran95,
you name it using this technology.   See
http://www.semdesigns.com/Products/DMS/DMSToolkit.html.

I would expect C2ADA to not be very easy.   Pointer casts and arithmetic
are a bitch to translate.


Keith Thompson wrote in message ...
>dvdeug@x8b4e53cd.dhcp.okstate.edu (David Starner) writes:
>> On Wed, 12 Jan 2000 23:38:47 GMT, Ted Dennison <dennison@telepath.com>
wrote:
>> >> [c2ada not working well]
>> >Hmmm. This sounds like a good application for OpenToken. It currently
>> >only ships with Java and Ada syntaxes, but a C syntax shouldn't be too
>> >tough for someone with an ANSI C standard handy to cobble together. I
>> >actually thought C would be the *first* syntax someone submitted, but up
>> >to now no one seems to have been that interested in C. :-)
>> ANSI C's a bit of a bear to parse, or so I've heard.
>
>Indeed.  The biggest problem is typedef names.  When a typedef is in
>scope, the name of the typedef has to be treated as a distinct token,
>not as an identifier -- unless it's a new declaration of the same
>name.  Thus you have to have feedback from the symbol table to the
>parser.  Ick.
>
>--
>Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
>San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
>Welcome to the last year of the 20th century.
>

Re: C question (was: Ada & C)

[Charles Hixson]

"Ira D. Baxter" wrote:

> If you have the right parser technology, parsing C is not hard and you
> don't need the symbol table immediately.   GLR parsing handles problems
> like typedef names by proposing multiple parses: in this case, one
> assuming its a typedef name, and the other assuming its a conventional
> identifier.
> Which can be resolved later, of course, with the symbol table.
>
> We offer reengineering tools that not only parse C, but C++, Ada95,
> Fortran95,
> you name it using this technology.   See
> http://www.semdesigns.com/Products/DMS/DMSToolkit.html.
>
> I would expect C2ADA to not be very easy.   Pointer casts and arithmetic
> are a bitch to translate.
>

Actually, I tend to feel that pointer casts *SHOULD NOT* be translated.  Some
things ought to be with a semantic level of understanding rather than merely a
syntactic level.

Re: C question (was: Ada & C)

[Gautier]

Charles Hixson wrote:

> Actually, I tend to feel that pointer casts *SHOULD NOT* be translated.

* If the Ada code is made to run in the same platform & memory model, it is surely
the wisest solution (avoids adding bugs) - but then it may not be necessary to translate the C.

* If the pointer arithmetics are specific to a memory model and you have to change
(e.g.) from 16-bit C to portable Ada, I'm afraid you may be obliged to understand what had be done
in the original code and translate the pointer casts...

G.

Re: Ada & C

[tmoran]

>I would recommend "Programming Windows" by Charles Petzold. Good intro to MFC.
  But don't pick up his bad habits like ignoring error returns from
functions.