Why all of the energy on supporting VC 6? Is it really that common of a tool in production environments? It appears to me to me to be a huge waste of time and energy. This concerns me, because I do not want to support VC 6 in YARD.

-- 
Christopher Diggins
Object Oriented Template Library (OOTL)
http://www.ootl.org

Well, there's some of us who are stuck with it... for several possible reasons:

1) The SDK we're using to develop only works with VC6. In my case, the
company I work for, develops add-ins for AutoCAD, which up to version 2002
is still developed with VC6. I assume the same applies to many other big
shot apps, one or two versions old.
2) Maybe the cost of upgrading isn't justified for some companies
3) Others which I might not have thought of right now..

Having mostly only developed with it, I never noticed it to be much of an inconvenience, other than not being able to use the "latest & greatest" boost libraries. But after watching Matthew battle with it yesterday, I understand your point.

The above are my reasons, I guess you'll have to wait and see what other people have to say...


Pablo Aguilar

"christopher diggins" <cdiggins@videotron.ca> wrote in message news:d2jivb$o72$1@digitaldaemon.com...
> Why all of the energy on supporting VC 6? Is it really that common of a tool in production environments? It appears to me to me to be a huge waste of time and energy. This concerns me, because I do not want to support VC 6 in YARD.
>
> -- 
> Christopher Diggins
> Object Oriented Template Library (OOTL)
> http://www.ootl.org

Three reasons for me, all of which I consider 'important':

1. There are plenty of organisations out there that still use VC6, including some of my clients. Since I want to use STLSoft when I'm working for them - saves both parties a *lot* of time and effort - I want VC6 covered.

2. I refuse to lose the skills (or the plug-ins) I have in Visual Studio 98, and either go to Eclipse (which I've heard is really slow) or VS.NET (which I _know_ is really slow: 5 minutes to load, 40MB mem used in quiescent state!!!!!! puh-leeeze), especially since I can get by in VS 98 without ever touching the mouse. (FWIW: I also use GVIM on Windows, and use Vi/GVIM exclusively on Linux.) Any IDDE that makes me take my hands off the keyboard would slow me down and piss me off, and I simply will not go through that. Because Intel 6/7/8 all bolt nicely into VS 98, I am able to switch to a 'modern' compiler whenever I need to. The problem with Intel is that it doesn't build browse info - always has trouble with the .sbr files - which also takes away a well-used tool from my armoury. One of the aims of Arturius was (and still is!) to be able to plug any compiler into any IDDE, at which point I'll be able to use, say, VC++ 7.1/8 in VS 98, and I'll never have to 'upgrade' my IDDE.

3. C++ is getting way too complex. I find the discipline of maintaining compatibility with older compilers is quite useful in steering me away from (too many of) the excessess of the modern era.

4. Although Walter'll tell you that he thinks I'm a complete nutter, I find it very useful to be able to compile code through older compilers. Although you might not grok it unless you've done a lot of it, it's the case that some older compilers catch what some newer compilers miss: e.g. something that GCC 2.95 will choke might help cure a problem that VC 7.1 has. The overall picture is more complete when as many compilers as poss are involved.

Having said all that, there're several parts of the libraries that are only compatible with partial-template-specialising compilers. Hence, regarding YARD, there's no need for you to worry about having to work with non-modern compilers. It's just nice if it's possible and practicable. If not, no worries.

Amusingly, I'm going *really* anachronistic with STLSoft 1.9, because I'm going to try and support C compilation for the main headers and (some of) the function-only libraries. <G> (FYI: It's so I can use certain STLSoft facilities for implementing Python and Ruby extensions, as well as a few other things, including the likely C-code of Recls-2.)

Cheers

Matthew



"christopher diggins" <cdiggins@videotron.ca> wrote in message news:d2jivb$o72$1@digitaldaemon.com...
> Why all of the energy on supporting VC 6? Is it really that common of a tool in production environments? It appears to me to me to be a huge waste of time and energy. This concerns me, because I do not want to support VC 6 in YARD.
>
> -- 
> Christopher Diggins
> Object Oriented Template Library (OOTL)
> http://www.ootl.org
> 

"Pablo Aguilar" <paguilarg@hotmail.com> wrote in message news:d2kbmj$1hmj$1@digitaldaemon.com...
> Well, there's some of us who are stuck with it... for several possible reasons:
>
> 1) The SDK we're using to develop only works with VC6. In my case, the company I work for, develops add-ins for
> AutoCAD, which up to version 2002 is still developed with VC6. I assume the same applies to many other big shot apps,
> one or two versions old.
> 2) Maybe the cost of upgrading isn't justified for some companies

The above two represent a non-trivial amount of real-world scenarios.

Remember two things:

    - Up until a few months ago - when MS stopped support - many companies were still widely using NT4. My guess is that
many still will for some time
    - Microsoft are *never* going to:
        (a) admit that many people do not need to upgrade things (I still use Office 97, and it does everything I want
at 5 times the speed of Office 200-and-whatever!!)
        (b) acknowledge, or at least publicise, how many people use software that's officially demode but practically
entirely sufficient.

> 3) Others which I might not have thought of right now..
>
> Having mostly only developed with it, I never noticed it to be much of an inconvenience, other than not being able to use the "latest & greatest" boost libraries. But after watching Matthew battle with it yesterday, I understand your point.

After a while, you get a gut feeling for what's going to be tractable, and what's not. I "knew" the right_view() implementation was do-able, and so finding the solution was tolerable. When your gut's telling you there's no VC6 solution - a la much of the RangeLib stuff - it's very disheartening, and you always berate yourself afterwards for not having listened to your guts and given up earlier. (Ah, the travails of the Yorkshire Terrier ... )



Frankly, I think the best service MS could do for the C++ programming community would be to spend the very small amount of time and effort into making VC6 support partial template specialisation in the form of an SP6. But of course that'd be commercially unsound. Don't ya just love capitalism! ;)

(Actually, people'd I'd some pay real hard cash for that!!)