Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!aplcen!uunet!tcs!nujoizey!gwu From: gwu@nujoizey.Berkeley.EDU (George Wu) Newsgroups: comp.lang.c++ Subject: Re: porting tips for c++ Message-ID: <957@tcs.tcs.com> Date: 14 Aug 90 00:01:13 GMT References: <1990Aug6.133901.25745@swbatl.sbc.com> <943@tcs.tcs.com> Sender: usenet@tcs.com Reply-To: gwu@nujoizey.Berkeley.EDU (George Wu) Lines: 82 In article , cline@cheetah.ece.clarkson.edu (Marshall Cline) writes: |> In article <943@tcs.tcs.com> gwu@nujoizey.tcs.com (George Wu) writes: |> >... This memorandum summarizes the necessary procedures used to switch from |> >GNU's C++ compiler to Sun's C++ compiler (AT&T Cfront 2.0).... |> |> Summary: Most of the things cfront wouldn't accept are in fact wrong C++. |> |> > o Constructors cannot have default argument values. The compiler does |> > not always complain about this problem. Consider the following |> > example: |> > class C { |> > public: |> > C(int x = 0); |> > C(int x, int y = 0); |> > }; |> |> A good reason that cfront wouldn't accept this is that it's ambiguous! Ex: |> C c(10); //Should `c' be constructed with C::C(int) or with C::C(int,int=0)? Yes, you can see the weasel wording I used where I didn't really understand why the compiler was complaining (only sometimes). |> |> > o Default argument values can only be declared in one place. Declare |> > default argument values in the class definition, not in the function |> > definition. |> |> This is not a bug in cfront: ``A default argument cannot be redefined |> by a later declaration (not even to the same value).'' [ARM, p.141]. |> However ``early versions of C++ allowed multiple default initializers |> for a single argument, as long as they were equivalent. Defining |> "equivalent" proved problematic, however.'' [ARM, p.144]. |> Note however that subsequent declarations can *add* default args in a |> right-to-left fashion... Apparently, GNU C++ 1.36.2 was such an "early" compiler. |> |> > o Values of type void* can only be assigned to variables of type void*. |> > The C++ permits any pointer value to be automatically cast to a |> > void* where necessary, but this relationship is not symmetrical. |> > Expressions of type void* must therefore be explicitly cast to the |> > appropriate pointer type. For example, given char* s and void* p, |> > s = p becomes s = (char *) p. |> |> Again cfront is correct (I'd be surprised if GNU C++ accepted this either!). |> ANSI C allows automatic coersion from void* to anything*, but this is a BIG |> hole in the type system, since the anything* to void* cast (which is allowed |> in both C and C++) would allow any pointer type to be silently coersed to any |> other pointer type by going through void*. We in fact knew about this problem, and have discussed it to some degree with Michael Tiemann. GNU C++ does indeed permit the automatic coercion from void* to any other pointer type, at least in 1.36.2. I was not involved in the discussion with Michael Tiemann, and therefore do not know the resolution, if any. Michael, if you care to reply, the person who complained to you about this from our company was Chris Bedford. |> |> > o The type of a pointer to a function includes the function argument |> > types, ie. the function prototyping must also be specified when |> > using function pointer. |> ^^^^^-- I assume you mean `declaring' -- M.Cline |> |> Yes, this too is correct. The type of a pointer-to-function not only |> includes the number and types of the function's parameters, it also |> has the function's return value. In general, most of our bugs were indeed because our code was wrong. I'd even recommend porting between the two compilers even if you don't need to. We found quite a few bugs that wouldn't have arisen until much later if we hadn't, epecially since not a few of our programmers were writing their very first C++ code, often using outdated texts or examples. George ---- George J Wu | gwu@tcs.com or ucbcad!tcs!gwu Software Engineer | 2121 Allston Way, Berkeley, CA, 94704 Teknekron Communications Systems, Inc.| (415) 649-3752