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.

"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.

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

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

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

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

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

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

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

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