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