Cygwin32 & C++ standard

Cygwin32 & C++ standard

[Justin Hopkins]

Can someone give me an idea of how conforming cygwin32 is
to the C++ standard? Or at least to the December '96 public
draft? Thanks

Justin Hopkins

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Cygwin32 & C++ standard

[Mumit Khan]

Justin Hopkins <hop@elwood.pionet.net> writes:
> Can someone give me an idea of how conforming cygwin32 is
> to the C++ standard? Or at least to the December '96 public
> draft? Thanks

Depends on what you mean by cygwin32 C++. If you mean the original 
b18 distribution, it's horribly old, so all bets are off if you're
looking at the latest draft that was approved as the standard. On
the other hand, the egcs distribution is pretty close, and in fact,
close enough to (almost) compete with some top quality commercial 
compilers such as Kai and others based on the EDG front end.

Also note that G++ now uses unmodified SGI STL distribution, which
means that as SGI updates its implementation to match the standard,
G++ will follow automatically.

Here're some quotes from the latest cp/NEWS (my commens are within
[[ ]]):

* g++ now uses a new implementation of templates. The basic idea is that
  now templates are minimally parsed when seen and then expanded later.
  This allows conformant early name binding and instantiation controls,
  since instantiations no longer have to go through the parser.

  What you get:

     + Inlining of template functions works without any extra effort or
       modifications.
     + Instantiations of class templates and methods defined in the class
       body are deferred until they are actually needed (unless
       -fexternal-templates is specified).
     + Nested types in class templates work.
     + Static data member templates work.
     + Member function templates are now supported.
     + Partial specialization of class templates is now supported.
     + Explicit specification of template parameters to function templates
       is now supported.

[[ also, now you don't have to worry about instantiatng templates yourself
  on ELF and PE-COFF, since the linker will simply discard the duplicates.
  In fact, I've seen 25% size reduction in final code size that until now
  used explicit template instantiation in conjunction with
  -fno-impliction-template flag ]]

  Things you may need to fix in your code:

     + Syntax errors in templates that are never instantiated will now be
       diagnosed.
     + Types and class templates used in templates must be declared
       first, or the compiler will assume they are not types, and fail.
     + Similarly, nested types of template type parameters must be tagged
       with the 'typename' keyword, except in base lists.  In many cases,
       but not all, the compiler will tell you where you need to add
       'typename'.  For more information, see

            http://www.cygnus.com/misc/wp/dec96pub/template.html#temp.res

     + Guiding declarations are no longer supported.  Function declarations, 
       including friend declarations, do not refer to template instantiations.
       You can restore the old behavior with -fguiding-decls until you fix
       your code.

[[ The last one will catch lot of existing code, and using -fguiding-decls
  is really no good since that can cause trouble with library code, 
  especially iostreams. The right solution is to convert your code
  correctly, and if you need backward compatibility with older compilers,
  you can use preprocess macros. For an example of how to do this using
  autoconf, take a look at my patch to GNU Octave 2.0.9 available at:
      
    ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/cygwin32/ports/
  ]]
  

  Other features:

     + Default function arguments in templates will not be evaluated (or
       checked for semantic validity) unless they are needed.  Default
       arguments in class bodies will not be parsed until the class
       definition is complete.
     + The -ftemplate-depth-NN flag can be used to increase the maximum
       recursive template instantiation depth, which defaults to 17. If you
       need to use this flag, the compiler will tell you.
     + Explicit instantiation of template constructors and destructors is
       now supported.  For instance:

            template A<int>::A(const A&);

  Still not supported:

     + Member class templates.
     + Template template parameters.
     + Template friends.

[[ Not having Template friends stink, but since I'm not about contribute
  the code, I can't really complain. The next one in line that I'd like is
  the Template template parameters, since I have tons of code that uses
  this feature, and there is not easy work-around. I can do without the 
  member class templates feature since there are easy work-arounds. ]]

[[ Also not implemented is namespaces, but at least code that uses just
  std namespace will work. ]]

* Standard usage syntax for the std namespace is supported; std is treated
  as an alias for global scope.  General namespaces are still not supported.

[[ Other things like RTTI, exception handling work quite well. On platforms
  where Dwarf2 unwinding works well, EH work like a charm; on others, such
  as win32, where it doesn't yet, g++ uses setjmp-longjmp, which imposes
  space and time penalty when using EH. ]]
  
[[ Two more items that can potentially break existing code: ]]

* The overload resolution code has been rewritten to conform to the latest
  C++ Working Paper.  Built-in operators are now considered as candidates
  in operator overload resolution.  Function template overloading chooses
  the more specialized template, and handles base classes in type deduction
  and guiding declarations properly.  In this release the old code can
  still be selected with -fno-ansi-overloading, although this is not
  supported and will be removed in a future release.

* (void *)0 is no longer considered a null pointer constant; NULL in
  <stddef.h> is now defined as __null, a magic constant of type (void *)
  normally, or (size_t) with -ansi.

Happy New Year
Mumit -- khan@xraylith.wisc.edu
http://www.xraylith.wisc.edu/~khan/
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

gdb and egcs

[John F. Kolen]

I have a problem using gdb on egcs generated code.  Gdb works fine on the
first pass through the program.  On the second pass it hangs right after
the "running ..." message, if there are arguments.  Running with no arguments
does not display this message, but it still hangs.  And it hangs pretty good--
doesn't respond to ^C or kill (Win32) or abort task (Windows95).

Any help would be appreciated.

---------------------- begin the culprit -------------------
#include <stdio.h>
void f(int a, int b, int c)
{
  printf("f:  %d %d %d\n",a,b,c);
}

main()
{
  int a,b,c;
  a = 1;
  b = 2;
  c = a+b;
  f(a,b,c);
  printf("main: %d %d %d\n",a,b,c);
}
---------------------- end the culprit -------------------

-- 
John F. Kolen				voice: (850)474-3075 
Assistant Professor			fax:   (850)474-3023
Dept. of Computer Science
University of West Florida
Pensacola, FL 32514
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: gdb and egcs

[Christopher Faylor]

In article < 9801051521.ZM8162@typhoon.coginst.uwf.edu >,
John F. Kolen <jkolen@typhoon.coginst.uwf.edu> wrote:
>I have a problem using gdb on egcs generated code.  Gdb works fine on the
>first pass through the program.  On the second pass it hangs right after
>the "running ..." message, if there are arguments.  Running with no arguments
>does not display this message, but it still hangs.  And it hangs pretty good--
>doesn't respond to ^C or kill (Win32) or abort task (Windows95).
>
>Any help would be appreciated.

I don't believe that this is an EGCS problem.  I've seen the same thing
happen with binaries compiled with "stock" B18.

I've noticed that if I let the program I'm running run to completion or if
I kill it from another window without letting gdb kill it, that things seem
to run better, i.e., no hangs.  Maybe it's just superstitious behavior on
my part, though.
-- 
http://www.bbc.com/	cgf@bbc.com			"Strange how unreal
VMS=>UNIX Solutions	Boston Business Computing	 the real can be."
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: gdb and egcs

[Mumit Khan]

cgf@bbc.com (Christopher Faylor) writes:
> 
> I don't believe that this is an EGCS problem.  I've seen the same thing
> happen with binaries compiled with "stock" B18.

You're right, it isn't. I dread running gdb because it hangs up my W95
box everytime I forget to quite and restart.

has anybody figured out the __image_base problem yet? This happens when
you try to step over a DLL exported routine (and possibly other times too,
but that's the one I usually notice), and you have to do a "finish"
followed by a "next" unless you want gdb to go to la-la land.

Mumit
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Cygwin32 & C++ standard

[hgfernan]

On 31 Dec 97 at 18:55,  Mumit Khan <khan@xraylith.wisc.edu> wrote:

> Depends on what you mean by cygwin32 C++. If you mean the original 
> b18 distribution, it's horribly old, so all bets are off if you're
> looking at the latest draft that was approved as the standard. On
> the other hand, the egcs distribution is pretty close, and in fact,
> close enough to (almost) compete with some top quality commercial 
> compilers such as Kai and others based on the EDG front end.
> 
> Also note that G++ now uses unmodified SGI STL distribution, which
> means that as SGI updates its implementation to match the standard,
> G++ will follow automatically.
>

I'd like to thank all GNU and egcs developers -- particularly Mumit
Khan -- for the  nice job they're doing.  For a GNU price, one is 
able to have an excellent compiler, better than hugely priced 
commercial ones.

Amazing and laudable.

Now that the C++ drafts seem to have stabilized and such a nice
compiler is available we C++ programmers can begin to try to tame
the new C++ beast. 

Thanks for the nice Christmas gift! 


Regards,
++Hilton
-------------------
Hilton Fernandes
email: hgfernan@usp.br
www:   http://www.lsi.usp.br/~hilton.html (inactive)
M. Sc. Student of Parallel Distributed Applications
at Escola Politecnica (Polytechic School)
University of S. Paulo - Brazil
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".