c++.beta - DMC and my project, TnFOX
- Niall Douglas (68/68) Feb 27 2004 After Mark Evans informed me of my incorrect views of DMC++, I finally g...
- Arjan Knepper (9/75) Mar 01 2004 I asume the type NullType is defined like this:
- Niall Douglas (6/13) Mar 01 2004 Well you could do that too. However, the point of default template
- Arjan Knepper (8/27) Mar 01 2004 Yes right. But the compiler does not seem to understand it right now, a
- Niall Douglas (7/11) Mar 01 2004 I'm very hesitant to alter my source if it's valid C++. My view is that ...
- Walter (6/13) Mar 02 2004 I understand your reluctance to do so. But it would make sense to fork t...
- Niall Douglas (15/25) Mar 02 2004 I am happy to do as with GCC Bugzilla and either post reduced examples
- Scott Michel (15/29) Mar 03 2004 I can understand your reluctance to forking code or providing an #ifdef ...
- Mark Evans (14/16) Mar 03 2004 Go easy on Niall. His position is reasonable and he can
- Niall Douglas (13/26) Mar 03 2004 Already posted the most important one which causes an error in every
- Mark Evans (9/12) Mar 03 2004 Walter's strenghts are exactly what is needed for Linux.
- Mark Evans (9/9) Mar 03 2004 I just ran into a full-page magazine ad for Intel compilers.
- Niall Douglas (14/25) Mar 04 2004 v3.4 is a very substantial improvement. Debug executables are a third of...
- Ilya Minkov (4/7) Mar 05 2004 I think it is not, since it's a usual practice when using precompiled
- Niall Douglas (11/17) Mar 05 2004 For me at least I manually include each individual header file I need on...
- Scott Michel (16/28) Mar 04 2004 I'm sorry, but I'm not going to apologize for reacting to people who lam...
-
Niall Douglas
(22/39)
Mar 04 2004
- Walter (9/14) Mar 05 2004 I appreciate that and understand your position. All I'm asking is that y...
- Niall Douglas (9/19) Mar 05 2004 Well I can go nowhere until at least the core header files can be parsed...
- -scooter- (7/24) Mar 08 2004 So what's difficult about (a) forking your source temporarily and (b)
- gf (9/31) Mar 09 2004 I guess he likes to waste everybody's time with his stubborn position an...
- Ilya Minkov (5/16) Mar 09 2004 I frankly don't know what this discussion is for. :) If someone else
- Niall Douglas (13/25) Mar 03 2004 I always found GCC v3.2.2 fine for most tasks - any work arounds were
- Mark Evans (7/15) Mar 06 2004 Such a statement is not justified by the one (very minor) issue you have
- Niall Douglas (17/27) Mar 07 2004 People are too quick to knock Microsoft. While some of their stuff is so...
- Mark Evans (30/45) Mar 07 2004 Everyone here is aware of MS quality issues. Walter is too, even
- Mark Evans (10/10) Mar 07 2004 An accurate picture of GCC may be obtained from their public bug list.
- Niall Douglas (11/20) Mar 07 2004 Yeah I know, you'll find some reported by me. In working use it's
- Mark Evans (19/25) Mar 08 2004 So you have encountered GCC bugs in, ah, "nonworking use" then. The
- Walter (5/6) Mar 08 2004 Ever since the very first Microsoft C compiler came out, I've been regul...
- Jan Knepper (8/11) Mar 08 2004 HA!
- Niall Douglas (48/62) Mar 08 2004 You are confusing how people work with the two different ideologies. Wit...
- Mark Evans (13/13) Mar 08 2004 Folks here know Microsoft tools and don't need lectures. We have all
- gf (5/11) Mar 08 2004 I thought you were against working around bugs/issues... It seems you're...
- Niall Douglas (21/40) Mar 07 2004 None. And with GCC v3.4, now none too except for move constructors which...
- Walter (48/55) Mar 03 2004 Check out the CNET download statistics here:
- Walter (7/9) Mar 03 2004 The download statistics for DMC averaged over 900 per day in February. I
- Jan Knepper (8/13) Mar 03 2004 Also, there are quite a few very long term users that have been using
- =?iso-8859-1?Q?Robert_M._M=FCnch?= (6/9) Mar 05 2004 That's right :-) but I missed the Zortech period ...
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
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
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
Niall Douglas wrote:On Mon, 01 Mar 2004 10:23:14 +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. 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?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! :)
Mar 01 2004
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
"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: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. -WalterYes 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.
Mar 02 2004
On Tue, 2 Mar 2004 17:17:21 -0800, Walter <walter digitalmars.com> 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? Cheers, NiallI'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.
Mar 02 2004
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
If you really want a bug fixed... -scooterGo 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
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
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 strengthsWalter'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
Mark Evans <Mark_member pathlink.com> 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
On Thu, 4 Mar 2004 00:11:13 +0000 (UTC), Mark Evans <Mark_member pathlink.com> wrote: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.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 strengthsWalter'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?For non commercial use yes. Which is the majority of development for Linux. Cheers, Niall
Mar 04 2004
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
On Sat, 06 Mar 2004 00:40:18 +0100, Ilya Minkov <minkov cs.tum.edu> wrote: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, NiallPrecompiled 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
Mark Evans 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. 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. -scooterIf want a bug fixed... -scooterGo 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.
Mar 04 2004
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
"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
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
Niall Douglas wrote:On Fri, 5 Mar 2004 18:58:24 -0800, Walter <walter digitalmars.com> wrote: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 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!
Mar 08 2004
-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: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.ptSo 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.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!
Mar 09 2004
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
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
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
On Sat, 06 Mar 2004 22:23:48 -0700, Mark Evans <nospam nospam.not> 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. 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 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.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 :)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.If he fixes the bug I posted, I'll see. Cheers, Niall
Mar 07 2004
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.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.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.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
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
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
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
"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
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
On Mon, 08 Mar 2004 01:48:55 -0700, Mark Evans <nospam nospam.not> wrote: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.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.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
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
Niall Douglas <s_digitalmars remove.me.nedprod.com> wrote in news:opr4i7lmgskpcwcj news.digitalmars.com:I thought you were against working around bugs/issues... It seems you're just selective about it. ~/gnf.ptNow 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
Mar 08 2004
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.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.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.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, NiallIf 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").
Mar 07 2004
"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 begin 666 b.gif K1TE&.#EA ` end begin 666 ttu.gif M1TE&.#EA M+ `````.`!$```,[2+H2^S ,!Y^<==T 1+Y35W%#Z$5 H*I/Z;Z8`I?K2<PO <)\_U M.B&ZQF6PV#BLY*A4QVGL\,`6HC) ``.P`` ` end begin 666 sm_dl2.gif M1TE&.#EA M,0"7, !J(P!;'EUL8 !]*OK[^NSM[/KZ^G2%>0`:"6&<=72< 8*$ P"5, "/ M(&%O94J(7P`]% "&+</%PP!Z*0&9,P",+UA 6P!/& `````````````````` M`````````````````````````````````"P`````$ `4```&DD"!<$ L&H_$ M&DM.)Q!S)2Y[7!X"+6D>( P'AEL5$)-X,B\PD !]0AHB, "857!>'AXJ'A6 MD&,6#P-C %UT5!`#L` ` end
Mar 03 2004
"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
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
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