 |
|
|
I read in the following article that they want to kill WTL:
http://windows.oreilly.com/news/visualc_0500.html
Has anyone heard anything else? WTL looks really cool, it would be a shame to kill it
|
|
|
|
|
|
|
Old news. That information is incorrect and has been refuted by others at MS
|
|
|
|
|
|
|
Partial specialization ? Hell I'd be happy if they could make the compiler able to even function with the Microsoft extensions switch turned off. In VC++ 6.0 it is impossible (in my experience) to compile even the simplest "Hello World" program without the MS extensions turned on. I assume this is another casualty in .NET as wel
|
|
|
|
|
|
|
You assume wrong. Well, kindof.
You can see for yourself by downloading the .NET SDK.
There are several new switches which give fine tuned ISO compliance. For instance, you can turn on or off the new for scoping specifically, and you can turn on or off native wchar_t support (wide characters as their own type).
You probably won't be able to completely turn off MS extensions, because the standard library and other MS headers depend on certain extensions for things like exporting into DLL's and #pragma once and such.
It would be nice if you could turn off MS extensions in your code only (not the library code).
|
|
|
|
|
|
|
In light of your previous installments I was actually expecting a humorous tale of the trials and tribulations of VC++ - but I guess it is kinda important that we hear about what is probably very important news for our future.
I just felt a sudden urge to do a Homer Simpson:
<Homer>Stupid TV (bang!) Be More Funny! (bang)</Homer>
|
|
|
|
|
|
|
At least I've heard that phrase a few times... :
|
|
|
|
|
|
|
From the following URL
http://www.devx.com/free/press/2000/vs-qalist.asp
We have the following quote
Does VC.NET support ANSI/ISO C++? Can VC.NET use Blitz++? http://www.oonumerics.org/blitz
VC.Net will not, I am sad to report. We are addressing compliance issues with both the compiler and with the standard library in VC.Net, some of the enhancements are in the bits distributed at the PDC, some we are still working on. However we were not able to do all the work needed to compile Blitz or its competitors that are based on expression templates in this release. E.g. we did not have sufficient time/resources to implement partial specialization. We did significant work on the standard library and on improved diagnostics for template errors, one of the main causes of frustration and hair pulling for many C++ developers trying to use templates. We are looking very hard at what it takes to fully support expression templates and other advanced template-based libraries for the next release. Ronald Laeremans, Microsoft.
Now, according to most C++ people, support for partial specialization is one of the key features of ANSI compliance. In fact, without partial specialization, a lot of hacks are necessary to get the STL to work. Unless Microsoft changed their mind after the above mentioned piece, VC.NET won't have partial specialization. Without partial specialization, VC is way way down the list of compliant compilers ( EDG, GNU, Borland, KAI are ahead of it), and Microsoft is doing a bunch of marketing hype.
Does anybody have anymore information on whether partial specialization will be in the next version of VC++, and the article I saw was outdated? If so, please post a reply and correct me.
|
|
|
|
|
|
|
To the best of my knowledge, no, VC++ 7 (VC.Net) won't include support for partial template specialization. Nearly everything else appears to be "fixed", so a fully compliant STL is possible (as long as other advanced template features work it's possible to work around lack of partial template specialization in the STL). However, expression templates, lambda libraries and other such "advanced" libraries which are quickly becoming the bread and butter of the language, won't be possible with out partial specialization. MS's failure to include this "feature" is, frankly, unforgivable at this point in time.
They crawled up from the bottom to be on top of the pack for a while, but, unfortunately, as far as the compiler itself is concerned they are nearly back to being on the bottom of the heap. To claim that they are the most compliant, or even the second most, is not only poor marketing, it's a bald faced lie that insults the intelligence of their customers.
(Would you believe that less than 6 months ago I was as strong in my feelings as I appear to be here when *supporting* the VC++ compiler?
|
|
|
|
|
|
|
Hmmm - that's interesting. I'll fire off an email to Ronald and get his reaction on this. He was quite passionate about compliance, but was equally accepting that a number of advanced features where indeed missing.
Maybe his/Microsoft's view of 'specialised' doesn't necessarily synch with the common developers view on this...
cheers,
Chris Maunde
|
|
|
|
|
|
|
Unfortunately, Ronald is out of the office for a few weeks and probably won't be responding to many emails (he posted to a newsgroup that he frequents).
Ronald's a great guy, and he's very earnest and up front. But I think he can be a little blinded by what the Microsoft culture feeds him at times. I can't imagine that he would say that the compiler is the most conforming or even second most conforming, since he knows it's not even close. That comment must have come from someone else.
I think MS is often blinded by it's peer group and usability studies. They poll a few dozen people, and assume that this is an accurate represenation of their audience.
The problem with such polls is that they typically only give you the information you're looking for.
Question 1:
What's more important to you?
A: Partial Template Specialization
B: A cool wizard that makes your job easier and faster
C: Bundtcake.
Most novice to intermediate developers will probably say B (or maybe C  and might not even know what PTS is. But in 6 months or a year when they aren't novices anymore, their answers change and suddenly, they're wondering why they can't use PTS.
While maybe it's true that only 10% of MS's customers care about full compliance, that 10% probably writes 70% of the code in major applications (or at least is influential in it's design).
In any event, the decisions about what VC7 will and will not be are made already and they aren't going to change.
|
|
|
|
|
|
|
To be perfectly honest I find C++ templates pretty daunting. Having worked on many C++ projects with numerous groups of programmers I have yet to find one who is really happy even using templates let alone writing them. This may be because you have to be an idiot to work with me, but I suspect that templates really are hard to understand (note they have yet to be included in Java and I don't think C# includes them).
Given this then the lack of partial template specialization is hardly a major issue for most programmers even after 6 years of C++ programming. If the compiler comes with a good STL out of the box then it is compliant enough for me.
|
|
|
|
|
|
|
Once you've worked with the STL, I doubt you'd retain that viewpoint. My experience with STL from both a usability standpoint and a design standpoint, is that this is the future of powerful programming. The whole concept of generic programming.. absolutely luv it! The only drawback that I can see to working with templates is in debugging them and that's the compiler's domain. What this particular framework offers far outweighs the drawbacks
|
|
|
|
|
|
|
I agree with you about STL and in fact I do use it extensively in my C++ programming (I tend to do more Java now). My point was that you can manage a good STL without partial template specialization. It may not meet the purists demands but I find the DinkumWare STL more than adequate for my needs.
|
|
|
|
|
|
|
There are many people who seem to be saying that templates are hard to use and that partial specialization does not matter. In fact, partial specialization makes templates easier to use not harder. Without partial specialization, you have to go through many tricks to do certain stuff. In addition, partial specialization does not add to the complexity of user code. It instead makes it easier for the library provider to write more efficient and usable code
|
|
|
|
|
|
|
There are many people who seem to be saying that templates are hard to use and that partial specialization does not matter. In fact, partial specialization makes templates easier to use not harder. Without partial specialization, you have to go through many tricks to do certain stuff. In addition, partial specialization does not add to the complexity of user code. It instead makes it easier for the library provider to write more efficient and usable code
|
|
|
|
|
|
|
There are many people who seem to be saying that templates are hard to use and that partial specialization does not matter. In fact, partial specialization makes templates easier to use not harder. Without partial specialization, you have to go through many tricks to do certain stuff. In addition, partial specialization does not add to the complexity of user code. It instead makes it easier for the library provider to write more efficient and usable code
|
|
|
|
|
|
|
Your are right if you say templates are hard to handle (especially if you get some errors) and most important is that STL works quite well. It's really nice that MS is working on better "template debugging".
Templates and using PTS is really, really for advanced developers. It's the whole philosophy of generic programming and C++ meta programming. Libraries like Blitz are made of this stuff. And they will be much more libraries like this, iff one day most compilers support the whole template stuff. It's a great technique and STL is only the beginnig of it.
In other words: I really would like to have PTS supported!
Danie
|
|
|
|
|
|
|
It actually is very hard to do some parts of STL in the best possible (i.e. highest performance) way without support for PTS. Which is one reason we would have liked to get this feature in.
I am very proud about the new template diagnostics though, which make finding template problems possible for most developers with average template savy instead of being a black art
|
|
|
|
|
|
|
One problem, as I have mentioned before, is that you can't learn templates if you can't use them. A great way to learn about templates and to master their use would be to buy a copy of "Generic Programming," and work through it, seeing the power that templates give you. The problem is that you can't do that with VC++, since it does not support templates fully.
As long as VC++ does not support templates, VC++ users will not understand templates well enough to take good advantage of them. It's a chicken-and-egg problem.
In my work, this is a real frustration, because for heavily numerical code, FORTRAN vastly outperforms C and C++. The Blitz++ library, mentioned at the top of this thread, promises finally to make C and C++ produce machine code that performs comparably to FORTRAN, but MS doesn't think its customers care about performance on Engineering applications---as they see it, the VC++ market is mostly developers writing client-server database applications for business.
If this is true, they probably don't lose much by ignoring us engineers and scientists, but as 3D-graphics performance becomes increasingly important, they will find that the same kinds of performance drags we see today in engineering applications will bog down tomorrow's mass-market applications and the temperature will heat up around PTS.
|
|
|
|
|
|
|
Might I add, friends, that compliance to the ANSI C++ standard, regardless of the level of the user, is of extreme importance. Things like this especially are troubling when you want to compile programs for scientific computation or even industry-scale programs such as Web server software and other high-performing code.
To make a compiler that doesn't comply to standards is very reprehensible on Microsoft's part. It doesn't matter whether or not you like or hate C++ templates, or that you can or can't use whatever else feature. The heart of the matter is that without standardization, software becomes proprietary and incompatible, and if Microsoft thinks it's OK to not make compliant software, then that could lead us on a very slippery path. This behavior from Microsoft all the more justifies suspicions that they use their monopoly power to work against interoperability and cooperation in the industry.
Plus, I don't buy the argument that Microsoft doesn't have the resources necessary to implement such features in their compilers. Bulls**t!! Microsoft has the most money in the entire world. Plus, they have a lot of very bright people there. As well, if the GNU compiler and other open-source compilers implement full compliance, or at least better compliance to the standard, then can't they use the source code from those implementations as bases from which to weave those features into their own compilers?
While I agree that people usually tend not to care whether or not advanced language features are there in the compiler, if the software is not compliant with standards, then there really is no point in using it because it might not give you either the power or the flexibility you need when you need it.
Then again, might Microsoft be just getting all of us ready to pay through the nose for "upgrades,", i.e. withholding features that they can very well put in to this software when instead they're going to make us wait and pay again? Maybe the best course is to wait out a few more versions of Visual C++, and keep on using what you have in the meantime. This way, when you're ready to upgrade, less money will have been given to Microsoft, in total, than it deserves.
Warm Regards,
brian hart
|
|
|
|
|
|
|
While you have some very valid concerns, you aren't looking at the whole picture.
First, While MS does indeed have the money to put into doing anything it wishes, like most companies, it allocates a certain number of resources to do a job and can't just throw more people at it whenever it wants. Those people are already committed to other projects and we all know that hiring compentant new people, especially in the compiler design arena is difficult.
Further, it seems clear that MS really is stretched thin on resources, since they can't even get all the .NET features into VC that they want. For instance, VC7 will ship without a WinForms designer because there weren't enough resources to get that done. Clearly, you are attributing to malice that which has other explanations.
|
|
|
|
|
|
|
(snip)
Ronald's a great guy, and he's very earnest and up front. But I think he can be a little blinded by what the Microsoft culture feeds him at times. I can't imagine that he would say that the compiler is the most conforming or even second most conforming, since he knows it's not even close. That comment must have come from someone else.
(/snip)
Erik, I enjoy your style 
As I recall, using my admittedly non-photographic memory, is that during the discussion about compiler conformance, the majority of comments were coming from another MS program manager, and not in-fact from Ronald.
The discussion went something like: (feel free to jump in here at any time Chris)
If you look at *all* features that should be in a compiler for true compliance, Microsoft is way, way up the list, either with the largest number of covered features, or maybe second in the list. The community however doesn't focus on the overall landscape of compliance, but zone in on particular features in the spec that they would like to see implemented (their favorites), and Partial Template Specialization was specifically mentioned here.
There's no question that they would like it to be in there, and I got from Ronald in particular that this was very high on his list of important features.
On a personal note, I certainly fall into the templates are interesting group, but professionally discourage their use (unless really really justified) because it makes the code written unmaintainable by 90% of the already ridiculously hard to find C++ developers out there.
I know the response to this is that *real* C++ developers should know all of C++ intimately (including templates), but that is unfortunately not reality.
|
|
|
|
|
|
|
The 90% / 10% rule is a red herring. How many developers who _use_ ATL really understand templates ? What percentage of them understand the Barton and Nackman Trick that ATL plays with templates ?
The fact is that a developer does not have to fully understand tmplates to make good use of a template library - but the compiler definitely _does_ have to understand them.
The problem isn't that VC++ does/doesn't do feature X or Y, it is what it does in comparison with other compilers. If VC++ doesn't support something that most other compilers do, then it is a problem - people happily using that feature will find they have to "port" their (correct, standard) code to VC++ instead of just build it. My impression is that VC++ template support is now definitely lagging in this way.
Whether or not you can hack around the lack of partial specialisation to get STL (or whatever library) working is not the point - if VC++ is the only compiler which requires that work, it may be that you just don't support VC++.
Rightly or wrongly, the fact that MS clearly invests a lot in producing non-standard extensions to C++ before it has implemented the standard parts of the language, gives the impression that it is not interested in portable code - and if you are trying to write portable code that seems to imply MS is not interested in supporting you.
Perhaps if you don't care about writing portable C++ then everything is fine - but then you also must not care about _using_ portable C++, because some of the small percentage of developers writing portable code are writing libraries like STL which many others use.
My worry is that among the minority complaining about missing "favourite features" are actually many of the gurus who write the libraries - and if they finally give up hacking their library to work around VC++, the rest of us are without not only feature X, but also library Z (or at least all later versions of it).
A final note - I don't think templates are that hard, but that most people haven't been able to learn them because of lack of compiler support. If you get an example out of a textbook and the compiler just gives an obscure error - _then_ it is hard to learn.
A few years ago when learning C++ I found templates very frustrating for just this reason - with g++. VC++ (v4) was wonderful by comparison, all of a sudden my textbook code worked. Pick up a current textbook and try with current versions of those compilers, and it would be the other way round.
|
|
|
|
|
|
|
Well stated.
There is no question that Microsoft has a responsiblity in their position of market leadership in this space to actually 'lead', and to me that means that they should support the latest features of the language including templates and PTS.
Tony Goodhew has come forward and set the record straight (thank you Tony) regarding the appearantly incorrect impression that both Chris and I were left with after our meeting, and so it appears that as far as compiler conformance is concerned, MS still has a long way to go.
FWIW, I think that having VC++ support portable code is important to Microsoft, at least in having that code portable to Windows
I'm not party to the research on which Microsoft makes its product decisions, but I'd have to believe they factor the Guru's in highly when considering their next steps. At every insider's meeting I've been party to Microsoft listens very, very closely to the opinions expressed.
Has anyone used a third party replacement compiler like the one offered by Intel? I'd be curious to know how popular something like that is, and whether it offers a solution to this while still allowing use of the VC IDE.
|
|
|
|
|
|
|
Chris, no need to wait for Ronald.
PTS isn't in VC.NET. Sorry. Frankly its embarrassing to many of us. Our compiler team had a ton of work to do this time around and we simply won't be able to do it.
We do have a new STL, still from Plauger. The only place where we really needed it for his library was for bitset<> and we have a workaround for that template.
We _really_ want to do this, there are other factors in place which prevented it this time.
The claim about "the most compliant compiler" I believe came from one of our marketing guys that was in the meeting who, as I recall, said that some external company ran some conformance test (I think from Plum Hall, or Perennial...don't remember who) which had the VC6 compiler at the highest or second highest in percentage of passed tests. Something like 94%.
That is when we pointed out that this number is somewhat artificial because to the person who needs a feature that the failing 6% tests, non-conformance is a big issue.
I may have a few of the details wrong, which is why a reply from Ronald would have been better since he works on the compiler, but I think the general gist of what was discussed is conveyed here accurately.
Walter Sullivan
(the real) Lead Program Manager of ATL/MF
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin