www.digitalmars.com         C & C++   DMDScript  

c++ - Comparison Watcom and DMC

reply "Christian Kaiser" <chk online.de> writes:
Hi,

I am a year-long user of Watcom and I just stumbled over Digital Mars again
(before Watcom I used Zortech C++ in DOS and Win16 times), and now I created
a small test suite for a first impression. The results are:

Watcom C++ (11.0c, but it should speak for OpenWatcom too) makes the EXE a
tad smaller (46592 compared to 64620), which is unimportant since the
difference is neglectable, but Watcom's speed is about 25% faster (27 s
compared to 36 s!), which is impressive for the compiler that was not cared
about for years.

I uploaded my small test suite to www.invest-tools.com/pub/wc_dmc.zip. It
consists of a small program which stores a number of integers in a list
(skip list or single linked list) and iterates the list afterwards.

What is worse, DMC does not compile all the library code (i.e. the skip
lists). This code from the Watcom compiler might be somehow convoluted, but
I like these easy-to-use classes much better than the STL, so compiling is
mandatory for an alternative compiler. If someone can find out the reason
why it does not compile, it would be nice. I would like to have another
compiler at hand, at least to be able to compile my code with a different
compiler to find bugs, and DMC compiles much faster, which would allow
faster turnaround cycles during development.

The code (with single linked list, which compiles) is also pasted below as
well as the batch file to produce the application. I will test it using MSVC
also once I have that compiler here. (Complete code in the ZIP).

Thanks,

Christian

----------------------

 echo off
echo.
echo ---------- DM:
l:\dm836\bin\sc -cpp -mn -o+all -5 -v1 -w17 -i. -d__386__ -d__SMALL__ -odmc.
exe x.c wcexcept.cpp wchash.cpp wclist.cpp wcskip.cpp
echo ---------- WC:
l:\wc110\binnt\wcl386 -cc++ -zq -oafinmrhkbt -s -oe -5r -i. -fe=wc.exe x.c
wcexcept.cpp wchash.cpp wclist.cpp wcskip.cpp

----------------------

#include <stdio.h>
#include <stdlib.h>

#include <wclist.h>
#include <wclistit.h>

int main(int argc, char* argv[])
{
int i;

WCValSList<int> List;
WCValSListIter<int> Item(List);

for (i = 0; i < 10000; ++i)
    List.append(rand());

int n = 0;
for (i = 0; i < 100000; ++i)
    {
    Item.reset();
    while (++Item)
        n += Item.current();
    }
printf("%d\n",n);
return(0);
}
Oct 01 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
Nice to have you with us! Some initial thoughts:

1) use -6, not -5, for modern Intel CPUs, which might help the speed a bit.

2) to help figure out where the syntax error is, see
www.digitalmars.com/faq.html#error. My initial thought is that since by its
name it appears to be a watcom specific header, that it relies on some
unique feature of watcom.

-Walter

"Christian Kaiser" <chk online.de> wrote in message
news:blfdrv$2fts$1 digitaldaemon.com...

 Hi,

 I am a year-long user of Watcom and I just stumbled over Digital Mars


again

 (before Watcom I used Zortech C++ in DOS and Win16 times), and now I


created

 a small test suite for a first impression. The results are:

 Watcom C++ (11.0c, but it should speak for OpenWatcom too) makes the EXE a
 tad smaller (46592 compared to 64620), which is unimportant since the
 difference is neglectable, but Watcom's speed is about 25% faster (27 s
 compared to 36 s!), which is impressive for the compiler that was not


cared

 about for years.

 I uploaded my small test suite to www.invest-tools.com/pub/wc_dmc.zip. It
 consists of a small program which stores a number of integers in a list
 (skip list or single linked list) and iterates the list afterwards.

 What is worse, DMC does not compile all the library code (i.e. the skip
 lists). This code from the Watcom compiler might be somehow convoluted,


but

 I like these easy-to-use classes much better than the STL, so compiling is
 mandatory for an alternative compiler. If someone can find out the reason
 why it does not compile, it would be nice. I would like to have another
 compiler at hand, at least to be able to compile my code with a different
 compiler to find bugs, and DMC compiles much faster, which would allow
 faster turnaround cycles during development.

 The code (with single linked list, which compiles) is also pasted below as
 well as the batch file to produce the application. I will test it using


MSVC

 also once I have that compiler here. (Complete code in the ZIP).

 Thanks,

 Christian

 ----------------------

  echo off
 echo.
 echo ---------- DM:


l:\dm836\bin\sc -cpp -mn -o+all -5 -v1 -w17 -i. -d__386__ -d__SMALL__ -odmc.

 exe x.c wcexcept.cpp wchash.cpp wclist.cpp wcskip.cpp
 echo ---------- WC:
 l:\wc110\binnt\wcl386 -cc++ -zq -oafinmrhkbt -s -oe -5r -i. -fe=wc.exe x.c
 wcexcept.cpp wchash.cpp wclist.cpp wcskip.cpp

 ----------------------

 #include <stdio.h>
 #include <stdlib.h>

 #include <wclist.h>
 #include <wclistit.h>

 int main(int argc, char* argv[])
 {
 int i;

 WCValSList<int> List;
 WCValSListIter<int> Item(List);

 for (i = 0; i < 10000; ++i)
     List.append(rand());

 int n = 0;
 for (i = 0; i < 100000; ++i)
     {
     Item.reset();
     while (++Item)
         n += Item.current();
     }
 printf("%d\n",n);
 return(0);
 }
Oct 01 2003
parent reply "Christian Kaiser" <chk online.de> writes:
Yes, it might be - but MSVC compiles the code too :)

I will try -6 for speed optimization; I used 5 as Watcom's P5 optimization
was slightly better than P6 when I tested it.

Did you take a look at these files, as it might tell you more than me? I'm
not unexperienced, but that message did not tell me much.

In the files there's a direct call to a template destructor

template <class Type>
class MyClass: public Base<Type>
{
....
node->~Base<Type>();
....
};

which works in VC and in WC, but not DMC. Right now I'm at work, but when I
find some time in the evening I will post the exact error message, and maybe
try MSVC speed tests too.

Thanks,

Christian

"Walter" <walter digitalmars.com> schrieb im Newsbeitrag
news:blffkq$2iek$1 digitaldaemon.com...

 Nice to have you with us! Some initial thoughts:

 1) use -6, not -5, for modern Intel CPUs, which might help the speed a


bit.

 2) to help figure out where the syntax error is, see
 www.digitalmars.com/faq.html#error. My initial thought is that since by


its

 name it appears to be a watcom specific header, that it relies on some
 unique feature of watcom.

 -Walter

 "Christian Kaiser" <chk online.de> wrote in message
 news:blfdrv$2fts$1 digitaldaemon.com...

 Hi,

 I am a year-long user of Watcom and I just stumbled over Digital Mars


 again

 (before Watcom I used Zortech C++ in DOS and Win16 times), and now I


 created

 a small test suite for a first impression. The results are:

 Watcom C++ (11.0c, but it should speak for OpenWatcom too) makes the EXE




a

 tad smaller (46592 compared to 64620), which is unimportant since the
 difference is neglectable, but Watcom's speed is about 25% faster (27 s
 compared to 36 s!), which is impressive for the compiler that was not


 cared

 about for years.

 I uploaded my small test suite to www.invest-tools.com/pub/wc_dmc.zip.




It

 consists of a small program which stores a number of integers in a list
 (skip list or single linked list) and iterates the list afterwards.

 What is worse, DMC does not compile all the library code (i.e. the skip
 lists). This code from the Watcom compiler might be somehow convoluted,


 but

 I like these easy-to-use classes much better than the STL, so compiling




is

 mandatory for an alternative compiler. If someone can find out the




reason

 why it does not compile, it would be nice. I would like to have another
 compiler at hand, at least to be able to compile my code with a




different

 compiler to find bugs, and DMC compiles much faster, which would allow
 faster turnaround cycles during development.

 The code (with single linked list, which compiles) is also pasted below




as

 well as the batch file to produce the application. I will test it using


 MSVC

 also once I have that compiler here. (Complete code in the ZIP).

 Thanks,

 Christian

 ----------------------

  echo off
 echo.
 echo ---------- DM:




l:\dm836\bin\sc -cpp -mn -o+all -5 -v1 -w17 -i. -d__386__ -d__SMALL__ -odmc.

 exe x.c wcexcept.cpp wchash.cpp wclist.cpp wcskip.cpp
 echo ---------- WC:
 l:\wc110\binnt\wcl386 -cc++ -zq -oafinmrhkbt -s -oe -5r -i. -fe=wc.exe




x.c

 wcexcept.cpp wchash.cpp wclist.cpp wcskip.cpp

 ----------------------

 #include <stdio.h>
 #include <stdlib.h>

 #include <wclist.h>
 #include <wclistit.h>

 int main(int argc, char* argv[])
 {
 int i;

 WCValSList<int> List;
 WCValSListIter<int> Item(List);

 for (i = 0; i < 10000; ++i)
     List.append(rand());

 int n = 0;
 for (i = 0; i < 100000; ++i)
     {
     Item.reset();
     while (++Item)
         n += Item.current();
     }
 printf("%d\n",n);
 return(0);
 }
Oct 02 2003
parent "Walter" <walter digitalmars.com> writes:
I haven't looked at the code, as I'm pretty buried with work. If you can
reduce the problem to the usual small test case, I'll add it to the bug list
and see about fixing it in the next go-round. Thanks, -Walter

"Christian Kaiser" <chk online.de> wrote in message
news:blh1h2$1rph$1 digitaldaemon.com...

 Yes, it might be - but MSVC compiles the code too :)

 I will try -6 for speed optimization; I used 5 as Watcom's P5 optimization
 was slightly better than P6 when I tested it.

 Did you take a look at these files, as it might tell you more than me? I'm
 not unexperienced, but that message did not tell me much.

 In the files there's a direct call to a template destructor

 template <class Type>
 class MyClass: public Base<Type>
 {
 ....
 node->~Base<Type>();
 ....
 };

 which works in VC and in WC, but not DMC. Right now I'm at work, but when


I

 find some time in the evening I will post the exact error message, and


maybe

 try MSVC speed tests too.

 Thanks,

 Christian

 "Walter" <walter digitalmars.com> schrieb im Newsbeitrag
 news:blffkq$2iek$1 digitaldaemon.com...

 Nice to have you with us! Some initial thoughts:

 1) use -6, not -5, for modern Intel CPUs, which might help the speed a


 bit.

 2) to help figure out where the syntax error is, see
 www.digitalmars.com/faq.html#error. My initial thought is that since by


 its

 name it appears to be a watcom specific header, that it relies on some
 unique feature of watcom.

 -Walter

 "Christian Kaiser" <chk online.de> wrote in message
 news:blfdrv$2fts$1 digitaldaemon.com...

 Hi,

 I am a year-long user of Watcom and I just stumbled over Digital Mars


 again

 (before Watcom I used Zortech C++ in DOS and Win16 times), and now I


 created

 a small test suite for a first impression. The results are:

 Watcom C++ (11.0c, but it should speak for OpenWatcom too) makes the






EXE

 a

 tad smaller (46592 compared to 64620), which is unimportant since the
 difference is neglectable, but Watcom's speed is about 25% faster (27






s

 compared to 36 s!), which is impressive for the compiler that was not


 cared

 about for years.

 I uploaded my small test suite to www.invest-tools.com/pub/wc_dmc.zip.




 It

 consists of a small program which stores a number of integers in a






list

 (skip list or single linked list) and iterates the list afterwards.

 What is worse, DMC does not compile all the library code (i.e. the






skip

 lists). This code from the Watcom compiler might be somehow






convoluted,

 but

 I like these easy-to-use classes much better than the STL, so






compiling

 is

 mandatory for an alternative compiler. If someone can find out the




 reason

 why it does not compile, it would be nice. I would like to have






another

 compiler at hand, at least to be able to compile my code with a




 different

 compiler to find bugs, and DMC compiles much faster, which would allow
 faster turnaround cycles during development.

 The code (with single linked list, which compiles) is also pasted






below

 as

 well as the batch file to produce the application. I will test it






using

 MSVC

 also once I have that compiler here. (Complete code in the ZIP).

 Thanks,

 Christian

 ----------------------

  echo off
 echo.
 echo ---------- DM:






l:\dm836\bin\sc -cpp -mn -o+all -5 -v1 -w17 -i. -d__386__ -d__SMALL__ -odmc.

 exe x.c wcexcept.cpp wchash.cpp wclist.cpp wcskip.cpp
 echo ---------- WC:
 l:\wc110\binnt\wcl386 -cc++ -zq -oafinmrhkbt -s -oe -5r -i. -fe=wc.exe




 x.c

 wcexcept.cpp wchash.cpp wclist.cpp wcskip.cpp

 ----------------------

 #include <stdio.h>
 #include <stdlib.h>

 #include <wclist.h>
 #include <wclistit.h>

 int main(int argc, char* argv[])
 {
 int i;

 WCValSList<int> List;
 WCValSListIter<int> Item(List);

 for (i = 0; i < 10000; ++i)
     List.append(rand());

 int n = 0;
 for (i = 0; i < 100000; ++i)
     {
     Item.reset();
     while (++Item)
         n += Item.current();
     }
 printf("%d\n",n);
 return(0);
 }
Oct 02 2003
prev sibling parent reply Paul McKenzie <paul paul.net> writes:
Christian Kaiser wrote:

 Hi,
 
 What is worse, DMC does not compile all the library code (i.e. the skip
 lists). 


The problem I have with Watcom (and the new Open Watcom) is it seems (or 
the perception is) that ANSI C++ conformance is not a priority.  What I 
am looking for is a compiler that will compile modern C++ code using 
namespaces, processes templates correctly, and yes, STL is a must.   I 
go to the Open Watcom newsgroups, and seldom is ANSI C++ standard 
conformance mentioned, and if it is, it gets a "back-burner" kind of 
response.

I will be corrected by Walter if I'm wrong, but DMC++'s goal is to get 
ANSI C++ conformance first.  I am happy that DMC++ has been able to 
compile my "heavily templated" code very well with no problems.  Yes, if 
what you mention is a bug in DMC, Walter will get around to fix it ASAP, 
since conformance is the goal.


 This code from the Watcom compiler might be somehow convoluted, but
 I like these easy-to-use classes much better than the STL, 


But that is your personal choice.  I believe that STL is easy to use, 
also it makes my code portable and not reliant on compiler specific 
libraries. For the majority of programmers, STL *is* what is used (and 
recommended).  It's just plain foolhardy for myself and others to use a 
C++ compiler that has trouble or just doesn't have the facilities to 
compile modern C++ code. Libraries such as boost, Loki, Blitz++, 
STLSoft, and many others now use modern C++ techniques such as template 
meta-programming.  DMC is closer (if it isn't already) to making it 
compatible with these libraries, while it seems that Open Watcom is not 
making headway into getting their compiler up to standard.
Oct 02 2003
next sibling parent reply Garen Parham <nospam garen.net> writes:
Paul McKenzie wrote:

...
... Libraries such as boost, Loki, Blitz++, 

 STLSoft, and many others now use modern C++ techniques such as template 
 meta-programming.  DMC is closer (if it isn't already) to making it 
 compatible with these libraries, while it seems that Open Watcom is not 
 making headway into getting their compiler up to standard.


I've not used DMC too heavily, but couldn't get it to compile some of my 
programs that used boost a few months back -- so it was my impression that it
wasn't quite there yet.  Is this not the case now?
Oct 02 2003
parent reply Paul McKenzie <paul paul.net> writes:
Garen Parham wrote:


 Paul McKenzie wrote:
 
 ...
 ... Libraries such as boost, Loki, Blitz++, 
 

STLSoft, and many others now use modern C++ techniques such as template 
meta-programming.  DMC is closer (if it isn't already) to making it 
compatible with these libraries, while it seems that Open Watcom is not 
making headway into getting their compiler up to standard.


 
 
 I've not used DMC too heavily, but couldn't get it to compile some of my 
 programs that used boost a few months back -- so it was my impression that it
 wasn't quite there yet.  Is this not the case now?
 


Walter can address this better than I can.  I know DMC++ did have 
trouble with a couple of things in boost.  I haven't tried it out 
lately, but maybe those problems have been ironed out with the latest 
version of DMC++.
Oct 02 2003
parent "Walter" <walter digitalmars.com> writes:
"Paul McKenzie" <paul paul.net> wrote in message
news:blhj8d$2jp5$1 digitaldaemon.com...

 Walter can address this better than I can.  I know DMC++ did have
 trouble with a couple of things in boost.  I haven't tried it out
 lately, but maybe those problems have been ironed out with the latest
 version of DMC++.


Many times, compiling Boost is a function of how much effort the boost
author put into finding workarounds for various compilers rather than how
conformant the compiler is. That said, I prefer to spend my time working to
compile the code correctly rather than essentially waste the time finding
workarounds.

The current beta, 8.37, should be much further along. I'm working on
implementing template-template-parameters, that should help out a lot, too.

I also want to acknowledge what a big help Christof Meerwald has been in
getting first STLport to work with DMC++ and now Boost.
Oct 02 2003
prev sibling next sibling parent Christof Meerwald <cmeerw web.de> writes:
On Thu, 02 Oct 2003 12:12:12 -0400, Paul McKenzie wrote:

 The problem I have with Watcom (and the new Open Watcom) is it seems (or 
 the perception is) that ANSI C++ conformance is not a priority.


IMHO the problem with Open Watcom is that nobody is working on the C++
compiler (AFAIR Carl Young has tried to fix a few conformance issues, but he
hasn't had much success yet).


bye, Christof

-- 
http://cmeerw.org                                 JID: cmeerw jabber.at
mailto cmeerw at web.de

...and what have you contributed to the Net?
Oct 02 2003
prev sibling next sibling parent "Christian Kaiser" <chk online.de> writes:
Yes, that's a large deficiency. And development is a bit too slow in my
eyes.

Christian


 The problem I have with Watcom (and the new Open Watcom) is it seems (or
 the perception is) that ANSI C++ conformance is not a priority.  What I
 am looking for is a compiler that will compile modern C++ code using
 namespaces, processes templates correctly, and yes, STL is a must.   I
 go to the Open Watcom newsgroups, and seldom is ANSI C++ standard
 conformance mentioned, and if it is, it gets a "back-burner" kind of
 response.
Oct 02 2003
prev sibling next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Speaking as the STLSoft author, I can say that Watcom doesn't provide
anywhere near the required level of template support. However, there are a
few of the STLSoft components that it can work with - auto_buffer,
true_typedef - but none of the containers, or any of the really
fancy-shmancy stuff. It really is markedly distinguished from all the other
compilers supported by the libraries, which, by and large, support just
about everything in the libraries. I do hope that the Watcom team put a lot
of effort into making it compliant, since I think it will be doomed to
eventual ignominy if they do not.


-- 
Matthew Wilson

STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)

"If i'm curt with you it's because time is a factor. I think fast, I talk
fast, and I need you guys to act fast" -- Mr Wolf

----------------------------------------------------------------------------
---


"Paul McKenzie" <paul paul.net> wrote in message
news:blhib7$2ik4$1 digitaldaemon.com...

 Christian Kaiser wrote:

 Hi,

 What is worse, DMC does not compile all the library code (i.e. the skip
 lists).


 The problem I have with Watcom (and the new Open Watcom) is it seems (or
 the perception is) that ANSI C++ conformance is not a priority.  What I
 am looking for is a compiler that will compile modern C++ code using
 namespaces, processes templates correctly, and yes, STL is a must.   I
 go to the Open Watcom newsgroups, and seldom is ANSI C++ standard
 conformance mentioned, and if it is, it gets a "back-burner" kind of
 response.

 I will be corrected by Walter if I'm wrong, but DMC++'s goal is to get
 ANSI C++ conformance first.  I am happy that DMC++ has been able to
 compile my "heavily templated" code very well with no problems.  Yes, if
 what you mention is a bug in DMC, Walter will get around to fix it ASAP,
 since conformance is the goal.


 This code from the Watcom compiler might be somehow convoluted, but
 I like these easy-to-use classes much better than the STL,


 But that is your personal choice.  I believe that STL is easy to use,
 also it makes my code portable and not reliant on compiler specific
 libraries. For the majority of programmers, STL *is* what is used (and
 recommended).  It's just plain foolhardy for myself and others to use a
 C++ compiler that has trouble or just doesn't have the facilities to
 compile modern C++ code. Libraries such as boost, Loki, Blitz++,
 STLSoft, and many others now use modern C++ techniques such as template
 meta-programming.  DMC is closer (if it isn't already) to making it
 compatible with these libraries, while it seems that Open Watcom is not
 making headway into getting their compiler up to standard.
Oct 02 2003
parent "Christian Kaiser" <chk online.de> writes:
You're correct. Unfortunately. We would need the DMC tokenizer in [optional]
combination with the WC optimizer :)

Speed results for my example code (all optimized for P6, maximum
optimizations switched on):

DMC 8.36     34 s
WC 11.0       28 s
MSVC 5       25 s

I am really astonished that ONE person can really produce a compiler that is
that good in confirming the standard and that is highly motivated throughout
the years (hey, how long ago was Zortech...), even starts a new compiler (D)
in addition. So all this is not meant as (negative) criticism.

Watcom's strength is support of multiple platforms (DOS with/without
extenders, Win16, Win32, OS/2 and Linux). Most of STLPort can be compiled
with it too for people who use the STL, but I know they are lacking a lot in
the C++ field. And I know the STLPort developers had a hard time to make it
work with all those compilers. So I don't share your point of view that
Watcom will become doomed, but it will be in an even smaller niche. It does
have its place in the world though.

To be honest, I don't rely on every C++ standard, so I'm pretty content with
the Watcom limitations; I have "old" code (up to 10 years) which works
pretty well even without namespaces. I would like to have them for newer
parts of the code, but for my one-man projects I can live without. What I'm
missing most is that newer C++ code from others (CodeProject, ...) often has
to be "Watcomized" in order to be compiled, which limits the possibility to
use updates of that code without re-applying the changes. Sigh.

Newer standards provide new bugs in compilers, Walter is correct. C++ is a
very hard language for compilers, and implementation is impossible without
bugs or misinterpretations. All bugs in Watcom that I did find are not from
the C++ compiler, but other (nasty) problems with alignment of strings, the
resource compiler, the RTL and others. Maybe simply because I don't push the
C++-features to the limit.

Christian

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bli44p$9fk$1 digitaldaemon.com...

 Speaking as the STLSoft author, I can say that Watcom doesn't provide
 anywhere near the required level of template support. However, there are a
 few of the STLSoft components that it can work with - auto_buffer,
 true_typedef - but none of the containers, or any of the really
 fancy-shmancy stuff. It really is markedly distinguished from all the


other

 compilers supported by the libraries, which, by and large, support just
 about everything in the libraries. I do hope that the Watcom team put a


lot

 of effort into making it compliant, since I think it will be doomed to
 eventual ignominy if they do not.
Oct 03 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Paul McKenzie" <paul paul.net> wrote in message
news:blhib7$2ik4$1 digitaldaemon.com...

 I will be corrected by Walter if I'm wrong, but DMC++'s goal is to get
 ANSI C++ conformance first.  I am happy that DMC++ has been able to
 compile my "heavily templated" code very well with no problems.  Yes, if
 what you mention is a bug in DMC, Walter will get around to fix it ASAP,
 since conformance is the goal.


You are right, I intend to make DMC++ standards conformance.
Oct 02 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bli6ua$d26$3 digitaldaemon.com...

 "Paul McKenzie" <paul paul.net> wrote in message
 news:blhib7$2ik4$1 digitaldaemon.com...

 I will be corrected by Walter if I'm wrong, but DMC++'s goal is to get
 ANSI C++ conformance first.  I am happy that DMC++ has been able to
 compile my "heavily templated" code very well with no problems.  Yes, if
 what you mention is a bug in DMC, Walter will get around to fix it ASAP,
 since conformance is the goal.


 You are right, I intend to make DMC++ standards conformance.


Except for the export keyword, of course <g>. Also, a C++ compiler is
unbelievably complicated, and it would be ludicrous to ever claim it was
free of bugs.
Oct 02 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
I think export has just about been dumped. Have you read "Why we can't
afford export?" by Herb Sutter & Tom Plum? It's a pretty persuasive argument
against.

Always seemed a daft idea to me anyway (but what I know about writing
compilers could be writ large on the back of a postage stamp with a marker
pen).



"Walter" <walter digitalmars.com> wrote in message
news:bli8aa$f1h$1 digitaldaemon.com...

 "Walter" <walter digitalmars.com> wrote in message
 news:bli6ua$d26$3 digitaldaemon.com...

 "Paul McKenzie" <paul paul.net> wrote in message
 news:blhib7$2ik4$1 digitaldaemon.com...

 I will be corrected by Walter if I'm wrong, but DMC++'s goal is to get
 ANSI C++ conformance first.  I am happy that DMC++ has been able to
 compile my "heavily templated" code very well with no problems.  Yes,






if

 what you mention is a bug in DMC, Walter will get around to fix it






ASAP,

 since conformance is the goal.


 You are right, I intend to make DMC++ standards conformance.


 Except for the export keyword, of course <g>. Also, a C++ compiler is
 unbelievably complicated, and it would be ludicrous to ever claim it was
 free of bugs.
Oct 02 2003
next sibling parent reply Paul McKenzie <paul paul.net> writes:
Matthew Wilson wrote:

 I think export has just about been dumped. Have you read "Why we can't
 afford export?" by Herb Sutter & Tom Plum? It's a pretty persuasive argument
 against.
 
 Always seemed a daft idea to me anyway (but what I know about writing
 compilers could be writ large on the back of a postage stamp with a marker
 pen).


The Comeau compiler (www.comeaucomputing.com) supports tbe export keyword.
Oct 02 2003
parent Paul McKenzie <paul paul.net> writes:
Paul McKenzie wrote:


 
 The Comeau compiler (www.comeaucomputing.com) supports tbe export keyword.
 


A better link:

http://www.comeaucomputing.com/4.0/docs/userman/export.html
Oct 02 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bli9cf$gbu$1 digitaldaemon.com...

 I think export has just about been dumped. Have you read "Why we can't
 afford export?" by Herb Sutter & Tom Plum? It's a pretty persuasive


argument

 against.


I read one article against it by the person who implemented it for EDG. It
seems to me to be clear that features should be implemented and tried out
before burning them into a standard.


 Always seemed a daft idea to me anyway (but what I know about writing
 compilers could be writ large on the back of a postage stamp with a marker
 pen).


Actually, D has them naturally as a result of having modules <g>.
Oct 02 2003
next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
"Walter" <walter digitalmars.com> wrote in message
news:blialo$j4j$1 digitaldaemon.com...

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bli9cf$gbu$1 digitaldaemon.com...

 I think export has just about been dumped. Have you read "Why we can't
 afford export?" by Herb Sutter & Tom Plum? It's a pretty persuasive


 argument

 against.


 I read one article against it by the person who implemented it for EDG. It
 seems to me to be clear that features should be implemented and tried out
 before burning them into a standard.


You'd think!

<G>
Oct 02 2003
prev sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
 Always seemed a daft idea to me anyway (but what I know about writing
 compilers could be writ large on the back of a postage stamp with a




marker

 pen).


 Actually, D has them naturally as a result of having modules <g>.


Maybe you should mention that in a c.l.c.m post, and get yourself that
little bit more popular there than you already are! He he
Oct 02 2003
prev sibling parent "Charles Sanders" <sanders-consulting comcast.net> writes:
Yes, even the language has become too complex for my tastes, making D all
the more needed!

C
"Walter" <walter digitalmars.com> wrote in message
news:bli8aa$f1h$1 digitaldaemon.com...

 "Walter" <walter digitalmars.com> wrote in message
 news:bli6ua$d26$3 digitaldaemon.com...

 "Paul McKenzie" <paul paul.net> wrote in message
 news:blhib7$2ik4$1 digitaldaemon.com...

 I will be corrected by Walter if I'm wrong, but DMC++'s goal is to get
 ANSI C++ conformance first.  I am happy that DMC++ has been able to
 compile my "heavily templated" code very well with no problems.  Yes,






if

 what you mention is a bug in DMC, Walter will get around to fix it






ASAP,

 since conformance is the goal.


 You are right, I intend to make DMC++ standards conformance.


 Except for the export keyword, of course <g>. Also, a C++ compiler is
 unbelievably complicated, and it would be ludicrous to ever claim it was
 free of bugs.
Oct 03 2003