www.digitalmars.com         C & C++   DMDScript  

c++.beta - DMC and my project, TnFOX

reply Niall Douglas <s_digitalmars remove.me.nedprod.com> writes:
After Mark Evans informed me of my incorrect views of DMC++, I finally got 
round to generating a build tool for DMC for scons (http://www.scons.org/) 
and gave it a test. Unfortunately I got:

dmc -Aa -Ab -Ae -Ar -Nc -Ns -R -mn -WD -g -s -S -gp -DFOXDLL -DWIN32 
-D_WINDOWS
-D_USRDLL -D_DEBUG -DBUILDING_TCOMMON -DFOXDLL_EXPORTS -DHAVE_JPEG_H 
-DHAVE_PNG_
H -DHAVE_TIFF_H -DHAVE_ZLIB_H -DHAVE_OPENSSL -ITnFOX\include 
-ITnFOX\windows -Ii
nclude -ITnFOX\windows\libjpeg -ITnFOX\windows\libpng 
-ITnFOX\windows\libtiff\li
btiff -ITnFOX\windows\zlib -Iopenssl\inc32 -c TnFOX\src\FXCanvas.cpp 
-oobjs\Debu
g\FXCanvas.obj
         template<> struct create<> { typedef NullType value; };
                                    ^
TnFOX\include\FXGenericTools.h(480) : Error: 'create' is already defined
TnFOX\include\FXGenericTools.h(476) : Error: ';' expected following 
declaration
of struct member
TnFOX\include\FXGenericTools.h(478) : Error: type-argument expected for 
paramete
r 'B' of template 'item'
TnFOX\include\FXGenericTools.h(545) : Error: size of 
FX::Generic::StaticError<un
signed short > is not known
TnFOX\include\FXGenericTools.h(555) : Error: type-argument expected for 
paramete
r 'B' of template 'item'
Fatal error: too many errors

The code in question is:

	template<typename A, typename B> struct item
	{
		//! The value of this item
		typedef A value;
		//! Either the next item in the list, or NullType
		typedef B next;
	};
	/*! \struct create
	\ingroup TL
	\brief Creates a typelist with up to 16 types
	\note Make sure you use the ::value member, not create<> itself
	*/
	template<typename T1 =NullType, typename T2 =NullType, typename T3 
=NullType, typename T4 =NullType,
			 typename T5 =NullType, typename T6 =NullType, typename T7 =NullType, 
typename T8 =NullType,
			 typename T9 =NullType, typename T10=NullType, typename T11=NullType, 
typename T12=NullType,
			 typename T13=NullType, typename T14=NullType, typename T15=NullType, 
typename T16=NullType>
	struct create
	{
	private:
		typedef typename create<T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, 
T13, T14, T15, T16>::value temp;
	public:
		typedef item<T1, temp> value;
	};
	template<> struct create<> { typedef NullType value; };

So, what's going on? I use these typelists through the project so getting 
this header to compile is rather important!

BTW it works fine on MSVC7.1 and GCC v3.4 CVS. I used the latest version 
of DMC, v8.4

Cheers,
Niall

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Feb 27 2004
parent reply Arjan Knepper <arjan ask.me> writes:
Niall Douglas wrote:
 After Mark Evans informed me of my incorrect views of DMC++, I finally 
 got round to generating a build tool for DMC for scons 
 (http://www.scons.org/) and gave it a test. Unfortunately I got:
 
 dmc -Aa -Ab -Ae -Ar -Nc -Ns -R -mn -WD -g -s -S -gp -DFOXDLL -DWIN32 
 -D_WINDOWS
 -D_USRDLL -D_DEBUG -DBUILDING_TCOMMON -DFOXDLL_EXPORTS -DHAVE_JPEG_H 
 -DHAVE_PNG_
 H -DHAVE_TIFF_H -DHAVE_ZLIB_H -DHAVE_OPENSSL -ITnFOX\include 
 -ITnFOX\windows -Ii
 nclude -ITnFOX\windows\libjpeg -ITnFOX\windows\libpng 
 -ITnFOX\windows\libtiff\li
 btiff -ITnFOX\windows\zlib -Iopenssl\inc32 -c TnFOX\src\FXCanvas.cpp 
 -oobjs\Debu
 g\FXCanvas.obj
         template<> struct create<> { typedef NullType value; };
                                    ^
 TnFOX\include\FXGenericTools.h(480) : Error: 'create' is already defined
 TnFOX\include\FXGenericTools.h(476) : Error: ';' expected following 
 declaration
 of struct member
 TnFOX\include\FXGenericTools.h(478) : Error: type-argument expected for 
 paramete
 r 'B' of template 'item'
 TnFOX\include\FXGenericTools.h(545) : Error: size of 
 FX::Generic::StaticError<un
 signed short > is not known
 TnFOX\include\FXGenericTools.h(555) : Error: type-argument expected for 
 paramete
 r 'B' of template 'item'
 Fatal error: too many errors
 
 The code in question is:
 
     template<typename A, typename B> struct item
     {
         //! The value of this item
         typedef A value;
         //! Either the next item in the list, or NullType
         typedef B next;
     };
     /*! \struct create
     \ingroup TL
     \brief Creates a typelist with up to 16 types
     \note Make sure you use the ::value member, not create<> itself
     */
     template<typename T1 =NullType, typename T2 =NullType, typename T3 
 =NullType, typename T4 =NullType,
              typename T5 =NullType, typename T6 =NullType, typename T7 
 =NullType, typename T8 =NullType,
              typename T9 =NullType, typename T10=NullType, typename 
 T11=NullType, typename T12=NullType,
              typename T13=NullType, typename T14=NullType, typename 
 T15=NullType, typename T16=NullType>
     struct create
     {
     private:
         typedef typename create<T2, T3, T4, T5, T6, T7, T8, T9, T10, 
 T11, T12, T13, T14, T15, T16>::value temp;
     public:
         typedef item<T1, temp> value;
     };
     template<> struct create<> { typedef NullType value; };
 
 So, what's going on? I use these typelists through the project so 
 getting this header to compile is rather important!

I asume the type NullType is defined like this: class NullType {}; I _think_ the line : template <> struct create <> { typedef NullType value; }; should be template <> struct create <NullType> { typedef NullType value; }; Or am I missing something? Arjan Knepper.
Mar 01 2004
parent reply Niall Douglas <s_digitalmars remove.me.nedprod.com> writes:
On Mon, 01 Mar 2004 10:23:14 +0100, Arjan Knepper <arjan ask.me> wrote:

 I asume the type NullType is defined like this:
 class  NullType {};

Correct.
 I _think_ the line :
 template <> struct create <> { typedef NullType  value; };
 should be
 template <> struct create <NullType> { typedef NullType  value; };

 Or am I missing something?

Well you could do that too. However, the point of default template arguments is that you don't need to specify them! :) Cheers, Niall
Mar 01 2004
parent reply Arjan Knepper <arjan ask.me> writes:
Niall Douglas wrote:
 On Mon, 01 Mar 2004 10:23:14 +0100, Arjan Knepper <arjan ask.me> wrote:
 
 I asume the type NullType is defined like this:
 class  NullType {};

Correct.
 I _think_ the line :
 template <> struct create <> { typedef NullType  value; };
 should be
 template <> struct create <NullType> { typedef NullType  value; };

 Or am I missing something?

Well you could do that too. However, the point of default template arguments is that you don't need to specify them! :)

Yes right. But the compiler does not seem to understand it right now, a work around for this problem is to specify the argument in this particular case. attn: Walter This is also a example showing a compiler problem/bug. Arjan P.S. What is TnFOX? A templated/loki'ed Fox Gui Toolkit?
Mar 01 2004
parent reply Niall Douglas <s_digitalmars remove.me.nedprod.com> writes:
On Mon, 01 Mar 2004 23:32:12 +0100, Arjan Knepper <arjan ask.me> wrote:

 Yes right. But the compiler does not seem to understand it right now, a 
 work around for this problem is to specify the argument in this 
 particular case.

I'm very hesitant to alter my source if it's valid C++. My view is that I only work around problems in major compilers and given I've ditched MSVC6 support you can see my attitude on this.
 P.S. What is TnFOX? A templated/loki'ed Fox Gui Toolkit?

See http://www.nedprod.com/TnFOX/ Cheers, Niall
Mar 01 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Niall Douglas" <s_digitalmars remove.me.nedprod.com> wrote in message
news:opr37kr3qckpcwcj news.digitalmars.com...
 On Mon, 01 Mar 2004 23:32:12 +0100, Arjan Knepper <arjan ask.me> wrote:

 Yes right. But the compiler does not seem to understand it right now, a
 work around for this problem is to specify the argument in this
 particular case.

I'm very hesitant to alter my source if it's valid C++. My view is that I only work around problems in major compilers and given I've ditched MSVC6 support you can see my attitude on this.

I understand your reluctance to do so. But it would make sense to fork the source, and make the change in a temporary version, to see if there are any other problems. That way, any issues can be resolved much more quickly. -Walter
Mar 02 2004
parent reply Niall Douglas <s_digitalmars remove.me.nedprod.com> writes:
On Tue, 2 Mar 2004 17:17:21 -0800, Walter <walter digitalmars.com> wrote:

 I'm very hesitant to alter my source if it's valid C++. My view is that 
 I
 only work around problems in major compilers and given I've ditched 
 MSVC6
 support you can see my attitude on this.

I understand your reluctance to do so. But it would make sense to fork the source, and make the change in a temporary version, to see if there are any other problems. That way, any issues can be resolved much more quickly.

I am happy to do as with GCC Bugzilla and either post reduced examples illustrating the problem or post preprocessor output - I have found this model most productive for all concerned. I'd like at least one free compiler for Windows besides GCC. If DMC occupied at least 25% of the Windows compiler market I'd consider forking the sources, but to be blunt, I have better things to be doing and so long as I have a working binary with all the major compilers for each of the three most popular PC architectures, any extra compiler support is cream on the milk as it were. Otherwise I'll let others get DMC up to scratch and then I'll develop support at that later stage. I know this is selfish but then your compiler is not a community project (ie; free software) is it? Cheers, Niall
Mar 02 2004
next sibling parent reply Scott Michel <scottm cs.ucla.edu> writes:
Niall Douglas wrote:
 I am happy to do as with GCC Bugzilla and either post reduced examples
 illustrating the problem or post preprocessor output - I have found this
 model most productive for all concerned. I'd like at least one free
 compiler for Windows besides GCC.
 
 If DMC occupied at least 25% of the Windows compiler market I'd consider
 forking the sources, but to be blunt, I have better things to be doing and
 so long as I have a working binary with all the major compilers for each
 of the three most popular PC architectures, any extra compiler support is
 cream on the milk as it were.
 
 Otherwise I'll let others get DMC up to scratch and then I'll develop
 support at that later stage. I know this is selfish but then your compiler
 is not a community project (ie; free software) is it?

I can understand your reluctance to forking code or providing an #ifdef that deals with "broken" default template instantiation. However, compared to other semi-free compilers or even "free" compilers, DMC does a much better job than most. Try compiling with OpenWatcom, which has a lot more catching up to do. If you really want a bug fixed, why not contribute some money or make it worthwhile for Walter to fix your bug before others on the list? Frankly, if I had the resources, I would make far larger donations to getting the bugs fixed that are near and dear to my heart. When push comes to shove, all compilers have issues. But DMC seems to have fewer issues than others and the C++ runtime is redistributable. That's the primary reason I use DMC -- ever tried to compile libstdc++ as a DLL? Or agonize over STLport? -scooter
Mar 03 2004
next sibling parent reply Mark Evans <Mark_member pathlink.com> writes:
If you really want a bug fixed...

-scooter

Go easy on Niall. His position is reasonable and he can serve as one more bug reporter bringing DMC++ to full compliance. DMC++ needs heavy-duty template programmers like Niall for stress testing. Niall, just post stripped- down code snippets right here for Walter. Then check back often for new beta releases incorporating fixes. The best thing is to work on full C++ compliance so that, (perhaps alone among compilers) DMC++ won't require #ifdef workarounds. That day seems not too far off and then "supporting" DMC++ will be trivial. After that, we can pound on Walter for a Linux port... but then we'll need gcc's C++ extensions as well as the current Microsoft C++ extensions...hmm... Mark
Mar 03 2004
next sibling parent reply Niall Douglas <s_digitalmars remove.me.nedprod.com> writes:
On Wed, 3 Mar 2004 19:37:30 +0000 (UTC), Mark Evans 
<Mark_member pathlink.com> wrote:

 Go easy on Niall.  His position is reasonable and he can
 serve as one more bug reporter bringing DMC++ to full
 compliance.  DMC++ needs heavy-duty template programmers
 like Niall for stress testing.  Niall, just post stripped-
 down code snippets right here for Walter.  Then check
 back often for new beta releases incorporating fixes.

Already posted the most important one which causes an error in every compilation unit. I need that fixed before I can go any further.
 The best thing is to work on full C++ compliance so that,
 (perhaps alone among compilers) DMC++ won't require #ifdef
 workarounds.  That day seems not too far off and then
 "supporting" DMC++ will be trivial.

Between MSVC7.1, ICC v8 and GCC v3.4 I need only an #ifdef for the type_info symbol demangling. Otherwise the code is identical 100% C++ compilers really have come far in recent months :)
 After that, we can pound on Walter for a Linux port...
 but then we'll need gcc's C++ extensions as well as the
 current Microsoft C++ extensions...hmm...

Why bother? Not only is GCC standard on Linux, Intel's excellent C++ compiler is free there too. If I were Walter's I'd work on my strengths rather than enter a market with much higher barriers to entry and little reward. Cheers, Niall
Mar 03 2004
parent reply Mark Evans <Mark_member pathlink.com> writes:
Why bother? Not only is GCC standard on Linux, Intel's excellent 
C++ compiler is free there too. If I were Walter's I'd work on my 
strengths

Walter's strenghts are exactly what is needed for Linux. Lean, sharp code generation with short compile cycles. GCC is a bloated cow compared to DMC++. It is rather monumentally sad how bloated GCC really is, given that it is the standard for Linux. There have been discussions about that in the past on DMC news. Linux needs a better compiler. The Intel compiler is not free on Windows last time I checked. Are you saying it is free for Linux? -Mark
Mar 03 2004
next sibling parent Mark Evans <Mark_member pathlink.com> writes:
I just ran into a full-page magazine ad for Intel compilers.
This is a January 2004 print magazine.

Intel C++ 8.0 for Linux or Windows retails at $400.
There is a separate "Math Kernel Library 6.1" for $200.

"Boost your performance with little or no source code changes.
Source/Binary compatible with Microsoft Visual C++ and GCC 3.2."

There exist free evaluation trials, but Intel compilers
are not free products.

Mark
Mar 03 2004
prev sibling parent reply Niall Douglas <s_digitalmars remove.me.nedprod.com> writes:
On Thu, 4 Mar 2004 00:11:13 +0000 (UTC), Mark Evans 
<Mark_member pathlink.com> wrote:

 Why bother? Not only is GCC standard on Linux, Intel's excellent
 C++ compiler is free there too. If I were Walter's I'd work on my
 strengths

Walter's strenghts are exactly what is needed for Linux. Lean, sharp code generation with short compile cycles. GCC is a bloated cow compared to DMC++. It is rather monumentally sad how bloated GCC really is, given that it is the standard for Linux. There have been discussions about that in the past on DMC news. Linux needs a better compiler.

v3.4 is a very substantial improvement. Debug executables are a third of the size over v3.3 and the compiler is about three times faster *without* precompiled headers enabled. Precompiled header support is still too toy for production use on GCC (being able to only precompile one header file is toy). But it's all pointing the right way. I've not tested release build output yet - the code isn't working right now. But I'm hoping for good things - GCC v3.3 was outputting a binary over twice as big as MSVC for identical code.
 The Intel compiler is not free on Windows last time I checked.
 Are you saying it is free for Linux?

For non commercial use yes. Which is the majority of development for Linux. Cheers, Niall
Mar 04 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Niall Douglas schrieb:

 Precompiled header support is still too toy for production use on GCC 
 (being able to only precompile one header file is toy). But it's all 
 pointing the right way.

I think it is not, since it's a usual practice when using precompiled headers to have an all.h or big.h or something like that. Not that it would matter too much with a fast parser.
Mar 05 2004
parent Niall Douglas <s_digitalmars remove.me.nedprod.com> writes:
On Sat, 06 Mar 2004 00:40:18 +0100, Ilya Minkov <minkov cs.tum.edu> wrote:

 Precompiled header support is still too toy for production use on GCC 
 (being able to only precompile one header file is toy). But it's all 
 pointing the right way.

I think it is not, since it's a usual practice when using precompiled headers to have an all.h or big.h or something like that. Not that it would matter too much with a fast parser.

For me at least I manually include each individual header file I need on a per-compilation unit basis - this substantially reduces knock-on effects from changing header files. Hence GCC's limited support does nothing for me. However my python bindings DLL /does/ include all headers including Boost.Python in one giant header file which all compilation units share. For this I'm greatly looking forward to see what speed increases we get (it took over eight hours on GCC 3.2.2 :( ) Cheers, Niall
Mar 05 2004
prev sibling parent reply Scott Michel <scottm cs.ucla.edu> writes:
Mark Evans wrote:

 
If want a bug fixed...

-scooter

Go easy on Niall. His position is reasonable and he can serve as one more bug reporter bringing DMC++ to full compliance. DMC++ needs heavy-duty template programmers like Niall for stress testing. Niall, just post stripped- down code snippets right here for Walter. Then check back often for new beta releases incorporating fixes.

I'm sorry, but I'm not going to apologize for reacting to people who lambast and outright reject DMC++ because default template arguments are not quite right or <insert your favorite bug here>. All products have faults. I don't quite see DMC++ as a fly-by-night operation as Niall stated in a later post. It's one thing to report a bug, it's quite another to outright reject the compiler for this one fault. I've had issues with DMC++ and Walter has been very responsive to fixing those issues. I only suggested monetary contributions as a means for attaching one's priority to getting one's particular bug fixed. I agree that GCC 3.4 is a good compiler, but on Win32, I have better things to do than turn into a fossil waiting for code to compile (or autoconf to run.) I also have an issue with libstdc++ not being a DLL -- that fact alone makes GCC a bad candidate for writing C++-based DLLs. -scooter
Mar 04 2004
parent reply Niall Douglas <s_digitalmars remove.me.nedprod.com> writes:
On Thu, 04 Mar 2004 12:25:26 -0800, Scott Michel <scottm cs.ucla.edu> 
wrote:

 I'm sorry, but I'm not going to apologize for reacting to people who 
 lambast
 and outright reject DMC++ because default template arguments are not 
 quite
 right or <insert your favorite bug here>. All products have faults. I 
 don't
 quite see DMC++ as a fly-by-night operation as Niall stated in a later
 post.

<sigh> If I were rejecting it, I wouldn't be here now would I? From hearsay I hadn't heard good things about DMC but Mark Evans put me straight. It has come along a lot from when I last looked.
 It's one thing to report a bug, it's quite another to outright reject the
 compiler for this one fault. I've had issues with DMC++ and Walter has 
 been
 very responsive to fixing those issues.

I didn't mean to be mean, but I did mean to be blunt. There are certain limits to what I will do to enable DMC support. I am happy to write a patch for scons, my make tool. I am happy to post small illustrative examples of bugs found. But I will not #ifdef in support to my library as I see DMC as having the bug, not my code.
 I agree that GCC 3.4 is a good compiler, but on Win32, I have better 
 things
 to do than turn into a fossil waiting for code to compile (or autoconf to
 run.) I also have an issue with libstdc++ not being a DLL -- that fact
 alone makes GCC a bad candidate for writing C++-based DLLs.

Far more important to me is that GCC doesn't output MSVC compatible libraries for C++. This makes it impractical to use in the majority of scenarios. Mark is right when he says there should be a compliant & free C++ compiler for Windows and DMC is the best place right now to do this. I also agree that libraries should support just such a thing. However, it's not a priority for me to the point of obfuscating my code though I'll help where I can. Sorry if I caused you any offense Scott, it was not meant that way. Cheers, Niall
Mar 04 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Niall Douglas" <s_digitalmars remove.me.nedprod.com> wrote in message
news:opr4c9l206kpcwcj news.digitalmars.com...
 I didn't mean to be mean, but I did mean to be blunt. There are certain
 limits to what I will do to enable DMC support. I am happy to write a
 patch for scons, my make tool. I am happy to post small illustrative
 examples of bugs found. But I will not #ifdef in support to my library as
 I see DMC as having the bug, not my code.

I appreciate that and understand your position. All I'm asking is that you consider forking the source, and then on a temporary branch make a few hacks to work around the problems. The point is not putting these in your production code, but to find all the problems at once. Otherwise, if there are 10 problems, it will take 10 releases of DMC++ to get it done :-( and I'd rather get it done with one release. Considering the high volume of DMC++ downloads, I think that would be to our mutual advantage.
Mar 05 2004
parent reply Niall Douglas <s_digitalmars remove.me.nedprod.com> writes:
On Fri, 5 Mar 2004 18:58:24 -0800, Walter <walter digitalmars.com> wrote:

 I appreciate that and understand your position. All I'm asking is that 
 you
 consider forking the source, and then on a temporary branch make a few 
 hacks
 to work around the problems. The point is not putting these in your
 production code, but to find all the problems at once. Otherwise, if 
 there
 are 10 problems, it will take 10 releases of DMC++ to get it done :-( and
 I'd rather get it done with one release. Considering the high volume of
 DMC++ downloads, I think that would be to our mutual advantage.

Well I can go nowhere until at least the core header files can be parsed without error - currently that example I posted previously guarantees any including compilation unit will not build which is all of them! If you were to fix that, I could at least make a start. I really don't like playing with that master file, it forces a total recompile which takes ages - which is why I extracted a reduced example and posted it here! Cheers, Niall
Mar 05 2004
parent reply -scooter- <scottm cs.ucla.edu> writes:
Niall Douglas wrote:

 On Fri, 5 Mar 2004 18:58:24 -0800, Walter <walter digitalmars.com> wrote:
 
 I appreciate that and understand your position. All I'm asking is that 
 you
 consider forking the source, and then on a temporary branch make a few 
 hacks
 to work around the problems. The point is not putting these in your
 production code, but to find all the problems at once. Otherwise, if 
 there
 are 10 problems, it will take 10 releases of DMC++ to get it done :-( and
 I'd rather get it done with one release. Considering the high volume of
 DMC++ downloads, I think that would be to our mutual advantage.

Well I can go nowhere until at least the core header files can be parsed without error - currently that example I posted previously guarantees any including compilation unit will not build which is all of them!

So what's difficult about (a) forking your source temporarily and (b) working around the default template parameter problem with a #define? Seems like a completely reasonable solution under the circumstances. Enumerating all of the bugs you encounter during the port instead of making Walter suffer death by a thousand small bug reports. Being stubborn isn't going to get your issue dealt with any faster.
Mar 08 2004
parent reply gf <mz_y2k yahoo...com> writes:
-scooter- <scottm cs.ucla.edu> wrote in
news:c2j4dc$2fm5$1 digitaldaemon.com: 

 Niall Douglas wrote:
 
 On Fri, 5 Mar 2004 18:58:24 -0800, Walter <walter digitalmars.com>
 wrote: 


 are 10 problems, it will take 10 releases of DMC++ to get it done
 :-( and I'd rather get it done with one release. Considering the
 high volume of DMC++ downloads, I think that would be to our mutual
 advantage. 

Well I can go nowhere until at least the core header files can be parsed without error - currently that example I posted previously guarantees any including compilation unit will not build which is all of them!

So what's difficult about (a) forking your source temporarily and (b) working around the default template parameter problem with a #define? Seems like a completely reasonable solution under the circumstances. Enumerating all of the bugs you encounter during the port instead of making Walter suffer death by a thousand small bug reports. Being stubborn isn't going to get your issue dealt with any faster.

I guess he likes to waste everybody's time with his stubborn position and surely he likes to feed this thread with is non-popular statements (as he described). PLEASE, fork your source, gather every compiler issue and post it here! I'm sure Walter would already have present a patch if you did fork your source instead of arguing here why you won't do it. ~/gnf.pt
Mar 09 2004
parent Ilya Minkov <minkov cs.tum.edu> writes:
I frankly don't know what this discussion is for. :) If someone else 
really has time, he could try to build tnFox himself and fork it 
temporarily. Then we could see, possibly it was the only bug?

-eye

gf schrieb:
 
 I guess he likes to waste everybody's time with his stubborn position and 
 surely he likes to feed this thread with is non-popular statements (as he 
 described).
 
 PLEASE, fork your source, gather every compiler issue and post it here! 
 I'm sure Walter would already have present a patch if you did fork your 
 source instead of arguing here why you won't do it.
 
 ~/gnf.pt
 

Mar 09 2004
prev sibling parent reply Niall Douglas <s_digitalmars remove.me.nedprod.com> writes:
On Wed, 03 Mar 2004 10:51:23 -0800, Scott Michel <scottm cs.ucla.edu> 
wrote:

 I can understand your reluctance to forking code or providing an #ifdef 
 that
 deals with "broken" default template instantiation. However, compared to
 other semi-free compilers or even "free" compilers, DMC does a much 
 better
 job than most. Try compiling with OpenWatcom, which has a lot more 
 catching
 up to do.

I always found GCC v3.2.2 fine for most tasks - any work arounds were basically clarifications in heavy usage of template parameter deduction and such. However v3.4 is OUTSTANDING and compiles stuff even MSVC7.1 has trouble with.
 If you really want a bug fixed, why not contribute some money or make it
 worthwhile for Walter to fix your bug before others on the list? Frankly,
 if I had the resources, I would make far larger donations to getting the
 bugs fixed that are near and dear to my heart.

I hate to be mean but it's a competitive market out there. Even among free (of cost) software you must compete on features and right now DMC is lagging behind GCC considerably. If I had money to splosh around, I'd pick GCC. It comes with source after all and there's no chance of it vanishing and leaving me up the creek. Cheers, Niall
Mar 03 2004
parent reply Mark Evans <nospam nospam.not> writes:
Niall Douglas wrote:
 
 I always found GCC v3.2.2 fine ... v3.4 is OUTSTANDING and compiles 
 stuff even MSVC7.1 has trouble with.

Some might say that is not much of a compliment.
 
 I hate to be mean but it's a competitive market out there. Even among
  free (of cost) software you must compete on features and right now 
 DMC is lagging behind GCC considerably.
 

Such a statement is not justified by the one (very minor) issue you have reported so far. And of course, GCC is not very good for Windows. Walter's very kind technical support is unbeatable. Please take advantage of it. His proposal seems sensible. Mark
Mar 06 2004
parent reply Niall Douglas <s_digitalmars remove.me.nedprod.com> writes:
On Sat, 06 Mar 2004 22:23:48 -0700, Mark Evans <nospam nospam.not> wrote:

 I always found GCC v3.2.2 fine ... v3.4 is OUTSTANDING and compiles 
 stuff even MSVC7.1 has trouble with.

Some might say that is not much of a compliment.

People are too quick to knock Microsoft. While some of their stuff is so awful it makes you sick to think about it (eg; COM, VB), some other stuff is really quite good. Their compilers are good. They weren't always, the old 16 bit C++ compiler suite was easily beaten by Borland. But since v4 of MSVC I couldn't fault it in comparison to the competition, and MSVC7.1 is a very good compiler. In particular, the MSVC debugger is unbeaten to my knowledge on any C++ environment.
 I hate to be mean but it's a competitive market out there. Even among
  free (of cost) software you must compete on features and right now DMC 
 is lagging behind GCC considerably.

Such a statement is not justified by the one (very minor) issue you have reported so far. And of course, GCC is not very good for Windows.

No, that was the most important bug - a parsing error of uninstantiated templates which affects every compilation unit in TnFOX. There are many, many other errors. In comparison, ICC needed two fixes and compiled everything unmodified. That was an easy port :)
 Walter's very kind technical support is unbeatable.  Please take
 advantage of it.  His proposal seems sensible.

If he fixes the bug I posted, I'll see. Cheers, Niall
Mar 07 2004
parent reply Mark Evans <nospam nospam.not> writes:
Niall Douglas wrote:

 
 People are too quick to knock Microsoft. While some of their stuff is
 so awful it makes you sick to think about it (eg; COM, VB), some
 other stuff is really quite good.

Everyone here is aware of MS quality issues. Walter is too, even more so, being in the business. I too have used their tools for many long years. I would be curious to know the MSVC7.1 workarounds implemented in TnFOX, come to that. How many #ifdefs are Microsoft-specific, etc. Independent of quality issues are open-source issues. These are standards compliance/adherence and cost. Microsoft does not really offer a C++ compiler. Microsoft offers a "managed C++" compiler. See this "polluted Java" article to understand the sorts of problems Microsoft likes to cause. http://news.com.com/2100-1001_3-216978.html It is interesting that, as Microsoft intended, users of their language tools have sunk just enough effort into supporting MS peculiarities that these users have become loathe to "port" the code to other compilers. MS tools have a lock-in effect even on open-source projects.
 
 Their compilers are good.

When they (a) work, (b) comply with open public standards, (c) don't cause vendor lock-in, and (d) don't require a second mortgage, yes.
 Such a statement is not justified by the one (very minor) issue you
 have reported so far.  And of course, GCC is not very good for
 Windows.

No, that was the most important bug - a parsing error of uninstantiated templates which affects every compilation unit in TnFOX. There are many, many other errors.

The statement was not justified by the one issue that you actually reported, a trivial bug with an easy workaround, yet which you characterize as the most important. I doubt that lesser bugs would justify such a comparison with GCC. Walter said a while ago he was going to produce a chart of DMC++ capabilities.
 If he fixes the bug I posted, I'll see.

OK Niall. Thanks for giving DMC++ a whirl. Your technical feedback will make DMC++ a better compiler. Please remember that Walter supports the C++ standard as written, not what other compilers may do with it (i.e. C++ standards violations re-christened as "features"). Good luck, Mark
Mar 07 2004
next sibling parent reply Mark Evans <nospam nospam.not> writes:
An accurate picture of GCC may be obtained from their public bug list.

http://gcc.gnu.org/bugzilla/

Last week saw about 120 bugs were fixed, and 120 more were found, in 
round numbers.  Currently over 1,000 (known and reported) bugs remain 
outstanding.

I am not clear on the status of C99 extensions in GCC.  DMC++ offers C99 
support.

Now where is that MSVC7.1 public bug list?  At least DMC++ and GCC are 
public about where things stand.  That by itself is a major benefit.

Mark
Mar 07 2004
parent reply Niall Douglas <s_digitalmars remove.me.nedprod.com> writes:
On Sun, 07 Mar 2004 23:49:56 -0700, Mark Evans <nospam nospam.not> wrote:

 An accurate picture of GCC may be obtained from their public bug list.

 http://gcc.gnu.org/bugzilla/

 Last week saw about 120 bugs were fixed, and 120 more were found, in 
 round numbers.  Currently over 1,000 (known and reported) bugs remain 
 outstanding.

Yeah I know, you'll find some reported by me. In working use it's compiling everything I throw at it, so I'm happy.
 I am not clear on the status of C99 extensions in GCC.  DMC++ offers C99 
 support.

 Now where is that MSVC7.1 public bug list?  At least DMC++ and GCC are 
 public about where things stand.  That by itself is a major benefit.

By sheer popularity it's pretty easy to discover what bugs MSVC has and how to work around them. The upcoming MSVC8 adds a lot of the stuff ICC v8 has, it's going to be interesting to see if MSVC can reclaim the performance crown off Intel for the first time in years. However I doubt if I'll be able to afford it this time round, not earned money in two years come May. Cheers, Niall
Mar 07 2004
next sibling parent reply Mark Evans <nospam nospam.not> writes:
Niall Douglas wrote:
 
 Yeah I know, you'll find some reported by me. In working use it's 
 compiling everything I throw at it, so I'm happy.

So you have encountered GCC bugs in, ah, "nonworking use" then. The point is that all compilers have bugs. I am confident that DMC++ can compile certain things that would choke GCC and MSVC7.1.
 
 By sheer popularity it's pretty easy to discover what bugs MSVC has and 
 how to work around them.

No, it is not. Even when they are known, the fixes come only after months of waiting for the next service pack or upgrade relea$e from Microsoft -- unlike DMC++, for which Walter turns around bug fixes on a dime and for FREE. Niall, I have been on the Microsoft bandwagon for a long, long time. You need not educate me about MS tools -- their history, quality, or future. It is with deliberate consideration that I have switched to DMC++. I do not "knock" Microsoft tools. I have used VC debuggers, IDEs, and so on, at guru levels. It is more nearly the case that you have tended to "knock" DMC++ without knowing much about it. Regarding MSVC8 vaporware, would you like to hear about the upcoming DMC++10 release code-named Walterhorn? I'm sure Walter will nail down the bug in his usual prompt manner. We all do appreciate your sincere interest. Mark
Mar 08 2004
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Mark Evans" <nospam nospam.not> wrote in message
news:c2hbfc$2b2l$1 digitaldaemon.com...
 Regarding MSVC8 vaporware,

Ever since the very first Microsoft C compiler came out, I've been regularly told by the pundits that my compiler would be put out of business by MSC's next release <g>.
Mar 08 2004
parent Jan Knepper <jan smartsoft.us> writes:
Walter wrote:
 Ever since the very first Microsoft C compiler came out, I've been regularly
 told by the pundits that my compiler would be put out of business by MSC's
 next release <g>.

HA! *NEVER* Definitely not as long as you are healthy and alive! -- ManiaC++ Jan Knepper But as for me and my household, we shall use Mozilla... www.mozilla.org
Mar 08 2004
prev sibling parent reply Niall Douglas <s_digitalmars remove.me.nedprod.com> writes:
On Mon, 08 Mar 2004 01:48:55 -0700, Mark Evans <nospam nospam.not> wrote:

 By sheer popularity it's pretty easy to discover what bugs MSVC has and 
 how to work around them.

No, it is not. Even when they are known, the fixes come only after months of waiting for the next service pack or upgrade relea$e from Microsoft -- unlike DMC++, for which Walter turns around bug fixes on a dime and for FREE.

You are confusing how people work with the two different ideologies. With MS people are used to bugs never getting fixed and so take an entirely different approach to how they develop their software (lower the common denominator). Conversely with free software projects, one can have bugs fixed much more quickly (esp. as you can usually fix them yourself) and so one can afford to take a much more aggressive approach despite the much more antiquated and inconsistent API. As an example, I have taken a very unique approach to fusing POSIX threads, Win32 threads and C++ in TnFOX which to my knowledge no one else has tried. It works well, but I wouldn't have been so aggressive if I didn't know I could poke around the glibc and NPTL sources. I know that eventually all common software such as an operating system or a compiler will be communal software ie; free of cost and source provided. However it is extremely unlikely that new exciting functionality will be free of cost - it'll be like any other market with the newest products costing the most. This is contrary to the economics of information goods, and if Tn is successful I have some ideas on that, but as a general rule it's likely to hold.
 Niall, I have been on the Microsoft bandwagon for a long, long time. You 
 need not educate me about MS tools -- their history, quality, or 
 future.  It is with deliberate consideration that I have switched to 
 DMC++.  I do not "knock" Microsoft tools.  I have used VC debuggers, 
 IDEs, and so on, at guru levels.  It is more nearly the case that you 
 have tended to "knock" DMC++ without knowing much about it.

I think credit should go where credit is due. I refused to use Windows let alone program for it until I saw NT v3.5 which impressed me. Regarding DMC++, you will have forgive my attitude on this, but if MSVC, ICC and GCC all compile identical source without error and DMC++ throws well over a hundred compile errors, I'm tending to think there's issues with DMC++. I did investigate some of the errors and they mostly seem to be knock ons from the bug I posted as I use typelists very extensively - if this hadn't been the case, I would have given up on DMC++ completely. Until I have experienced better, you must appreciate that my initial impression of DMC++ is not favourable. It's actually on your advice Mark that I tried it at all because you are clearly knowledgeable - however I must rely on my own real-world experiences before accepting the advice of others. And until I experience different, I will hold what initial impressions I currently do.
 Regarding MSVC8 vaporware, would you like to hear about the upcoming 
 DMC++10 release code-named Walterhorn?

That's really cynical of you, and I think highly unproductive :(. We know MSVC8 is not far from done because MSDN articles about its internals are appearing so it's soon now. Believe it or not (and I know I won't get much sympathy for saying this), MS are where they are because they are one of the best software companies on the planet. This doesn't necessarily translate to producing good quality software, or even mediocre quality software, but it does mean that some of their products are excellent (even if their business model is antiquated). (BTW I am not a supporter of MS, I think them a highly unethical company which does software a disservice costing global productivity hundreds of billions a year. But at the same time, I know they are where they are through being better at business than their rivals). Cheers, Niall
Mar 08 2004
parent Mark Evans <nospam nospam.not> writes:
Folks here know Microsoft tools and don't need lectures.  We have all 
used MS tools and know their good points and bad, from the technical 
side to the business side.  I'm not looking for an argument.  I did want 
to correct the misconceptions surrounding DMC++.  Actually, your 
comments make a solid case for migration away from MS tools.

The observation of "well over a hundred compile errors" with DMC++ is 
misleading because a single error often propagates like wildfire through 
the rest of the compilation.  That behavior is common to all compilers. 
  So the actual number of DMC++ bugs turned up by TnFOX remains to be 
seen; so far reported is exactly one.  We look forward to more.  Walter 
is just one man; he needs testers.

Thanks again for the interest, Niall.  And good luck with the project.

Mark
Mar 08 2004
prev sibling parent gf <mz_y2k yahoo...com> writes:
Niall Douglas <s_digitalmars remove.me.nedprod.com> wrote in
news:opr4i7lmgskpcwcj news.digitalmars.com: 

 Now where is that MSVC7.1 public bug list?  At least DMC++ and GCC
 are public about where things stand.  That by itself is a major
 benefit. 

By sheer popularity it's pretty easy to discover what bugs MSVC has and how to work around them. The upcoming MSVC8 adds a lot of the

I thought you were against working around bugs/issues... It seems you're just selective about it. ~/gnf.pt
Mar 08 2004
prev sibling parent Niall Douglas <s_digitalmars remove.me.nedprod.com> writes:
On Sun, 07 Mar 2004 22:08:21 -0700, Mark Evans <nospam nospam.not> wrote:

 I would be curious to know the MSVC7.1 workarounds implemented
 in TnFOX, come to that.  How many #ifdefs are Microsoft-specific, etc.

None. And with GCC v3.4, now none too except for move constructors which I'm really, really hoping will be accepted to the official ISO spec.
 Independent of quality issues are open-source issues.  These are
 standards compliance/adherence and cost.  Microsoft does not really
 offer a C++ compiler.  Microsoft offers a "managed C++" compiler.  See
 this "polluted Java" article to understand the sorts of problems
 Microsoft likes to cause.

I was a big fan of Microsoft's Java environment at the time - yes, it was polluted. Yes it encouraged you to use the MS extensions. But it was still darn faster to develop portable code in than anything Sun or Borland could provide (at that time). Ditto goes with MSVC. Yes it fits in with how MS want to you develop your application ie; for Windows only. However you're missing the fact it's still an excellent environment to develop *any* code in, including portable code. Don't knock what's good just cos there's a little bad.
 No, that was the most important bug - a parsing error of
 uninstantiated templates which affects every compilation unit in
 TnFOX. There are many, many other errors.

The statement was not justified by the one issue that you actually reported, a trivial bug with an easy workaround, yet which you characterize as the most important. I doubt that lesser bugs would justify such a comparison with GCC.

Do you know it has an easy workaround? Someone suggested adding one of the parameters which is default anyway. I didn't try it. However it would be strange if that actually worked.
 If he fixes the bug I posted, I'll see.

OK Niall. Thanks for giving DMC++ a whirl. Your technical feedback will make DMC++ a better compiler. Please remember that Walter supports the C++ standard as written, not what other compilers may do with it (i.e. C++ standards violations re-christened as "features").

Other than me forcing in move constructors and I suppose declspec(dllexport) etc, it's 100% ISO C++. BTW, the a Tn client process opened a kernel connection last night for the first time even with full 256 bit AES encryption and my own design of secure authentication. We're moving onwards and upwards! :) Cheers, Niall
Mar 07 2004
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
"Niall Douglas" <s_digitalmars remove.me.nedprod.com> wrote in message
news:opr39sb3zgkpcwcj news.digitalmars.com...
 I'd like at least one free
 compiler for Windows besides GCC.

 If DMC occupied at least 25% of the Windows compiler market I'd consider
 forking the sources, but to be blunt, I have better things to be doing and
 so long as I have a working binary with all the major compilers for each
 of the three most popular PC architectures, any extra compiler support is
 cream on the milk as it were.

Check out the CNET download statistics here: http://download.com.com/sort/3150-2069-0-1-5.html? CNET > Downloads > Windows > Software Developer > Compilers & Interpreters Compilers & Interpreters 1-25 of 46 | next 21 >> RE-SORT BY: Name Date added User rating CNET rating How we rate Downloads Total | Last week Availability Bloodshed Dev-C++ 4.0 pop Write and compile C++ programs. OS: Windows 95/98/NT/2000 File Size: 7.8MB License: Free to try, $20 to buy 04/11/2000 90% 1,086 votes 3,248 Download now Digital Mars C/C++ Compiler 8.29 pop Compile C/C++ programs for using in Windows environment. OS: Windows (all) File Size: 2.8MB License: Free 09/16/2002 71% 35 votes 1,808 Download now
Mar 03 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Niall Douglas" <s_digitalmars remove.me.nedprod.com> wrote in message
news:opr39sb3zgkpcwcj news.digitalmars.com...
 If DMC occupied at least 25% of the Windows compiler market I'd consider
 forking the sources,

The download statistics for DMC averaged over 900 per day in February. I also know that when wxWindows added support for DMC, there was a big spike in interest from DMC users. DMC flies under the radar a lot - we don't do full page ads, pay people to write books & articles, etc., but there are a lot of users out there.
Mar 03 2004
parent reply Jan Knepper <jan smartsoft.us> writes:
Walter wrote:

 The download statistics for DMC averaged over 900 per day in February. I
 also know that when wxWindows added support for DMC, there was a big spike
 in interest from DMC users. DMC flies under the radar a lot - we don't do
 full page ads, pay people to write books & articles, etc., but there are a
 lot of users out there.

Also, there are quite a few very long term users that have been using DMC++, Symantec C++, Zortech C++, etc as there primary C++ compiler every since the first Zortech C++ saw the light... -- ManiaC++ Jan Knepper But as for me and my household, we shall use Mozilla... www.mozilla.org
Mar 03 2004
parent "=?iso-8859-1?Q?Robert_M._M=FCnch?=" <robert.muench robertmuench.de> writes:
On Wed, 03 Mar 2004 18:26:03 -0500, Jan Knepper <jan smartsoft.us> wrote:

 Also, there are quite a few very long term users that have been using  
 DMC++, Symantec C++, Zortech C++, etc as there primary C++ compiler  
 every since the first Zortech C++ saw the light...

That's right :-) but I missed the Zortech period ... -- Robert M. Münch Management & IT Freelancer http://www.robertmuench.de
Mar 05 2004