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

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

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

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

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

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

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.

-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

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
>