|
After hearing all these days about future of VC++. I think Microsoft has decided to shift its all Windows Programming to dot net Technology. It will be safer to learn VB.net, ASP.net. Still we cannot predict the future of .net architecture. Still it has to prove that it is greater than Java. So if you are programming for Microsoft Windows, then it will be wiser if you shift to new technology while keeping pace in the old technology. Lots of big projects were done in VC++ 6.0 and COM/DCOM style of programming. If we want to upgrade those components, then again I think VC++ 6.0 will be needed. Even though MFC was one a big technology, programmers still used C SDK to program. I have seen many programmer using C SDK. So I think it is matter of taste what you like most and what application demands. So I think time has come to upgrade ourself to .net. We should not dicuss now about VC++, MFC future. Because God and Bill Gates alone knows it. I think VC++ programmer can code well for .net than any other VB programmer. Because we have guts and Intreast to learn and prove our self that we are better. One thing which we should always be proud is that we can program in any platform that is windows, Unix, Linux etc.. but where as VB programmers cannot. What is that in .net which we cannot program or we cannot learn. I have seen many of C++ programmers working on Java and J2EE. So if we learn .net than we will become "STAR" who can program in any operating system in different languages. We have to take this situation optimistically![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif) .
Salman
Live and Let live
|
|
|
|
|
Who made microsoft merged all of those things such as vb,c#
into one bowl? or they did it for some political reason without
consideration of the large vc commutity? are they even planning
to supply A big final compiler for PC which will fit for everyone?
There are many many features left for us to learn individually.
we have had spent a lot of time to understand those "cuting-edge"
tech, many of us just did testing those features and reported it
to microsoft. microsoft teams made me and you and him under-experience
once again!
Productive? It is we that made microsoft more productive! where is
your over-time product? it had been merged into the powerful "windows"?
we are all students of microsoft, and employeed by microsoft's QA dept.
They did they want, and they made us did they want also!
No experts outside microsoft? definitely! no matter how experienced you
are! microsoft guys are all good at marketing!!
|
|
|
|
|
Compiler, though complicated, should not be described as a black box.
It's just a lexical parser, a syntax analyser, a symbol table manager, a code generator, an optimizer, a linker, a debugger, a runtime library, an IDE, plus something else.
Adding or improving support for template is just changing lexical parser and syntax analyser, and this may have nothing to do with the rest of the system.
So what parts can we expecting improvements
|
|
|
|
|
In principle what you say should be true, but C++ syntax is such a mess that things are not quite this simple. If you look on some of the parsing and compiler writing FAQs around the net and read the answers to people's requests for yacc C++ grammars, you will get a feel for how hard it is to parse an ugly language like C++.
I love C++, but we should all admit that it's a nightmare for a machine to parse. The language is highly ambiguous and hence cannot be parsed in the quasi-context-free way that standard parser generators such as yacc work.
Consider the statement "foo::bar<goo::moo, 475>::fubar < 12;", which refers to the attribute or method "fubar" of an instantiation of the template class bar (which lives in namespace foo, or is bar a local class within class foo?) with template parameters goo::moo (again, is goo a namespace of a class?) and 475. The lexical analysis cannot take place separately from the syntactical analysis ( is '<' the start of a template argument or is it a "less-than" sign? You need to read several tokens ahead to find out.), which cannot take place separately from the semantic analysis (distinguishing namespaces from class names).
The richness of C++ in grammatical ambiguities kills the linear picture of lex -> parse -> syntax-directed translation -> optimize that you describe above. In fact all the components are connected to one another with strange nonlinear couplings.
Adding partial template specialization to all of this will put a great load on the compiler's symbol table and complicate the already messy lexical/syntactical/semantic analysis.
I have been screaming loudly for Microsoft to address this hole in their C++ compiler, but we should recognize how hard it will be for them to actually do it. It's not impossible, as many other vendors (most notably Kuck and Associates) have implemented these features quite well. Microsoft has a lot of insanely good developers, so I don't doubt that they would be able to do a bang-up job if they wanted to.
The thought occurs to me in all of this that the same ambiguities that make C++ such a nightmare for machines to parse also may make it very difficult to maintain because a person can become just as confused as a machine about whether the left side of a "::" context token is a namespace or a class. It may be that as people get more used to working with the newer features of the language, it will become necessary to clean up the core language, as when K&R C metamorphosized into ANSI
|
|
|
|
|
Since you ask Chris, I offer my personal opinion on Templates - everything you've said is true!
They are easy to use, and hard to master. We use them in perhaps 20% of our code, and they really work well for us. However, I find that as soon as I want to take templates beyond simple containers, the lack of things like partial specialisation becomes a MAJOR issue, and one that consumes far too much time and energy trying to resolve.
As far as the 'what about the maintenance issues' for templates, I think this can be overstated - after all, most programmers 'use' major libraries rather than 'write' them. I can use the STL, but I doubt I could write or debug it! It's the same with our internal development - a few 'senior' developers design and implement the core libraries, and then the other developers build 'production' code using those libraries - only a relatively small percentage of the staff will ever need to go 'inside' the libraries. And we'd only want experienced people doing that anyway, we'll always have issues of finding suitably qualified people to replace departures, whether we use templates or not.
And finally, since we're somewhere remotely near this topic, I'd like to add my personal wishes for VC++ templates (sort in order of priority, I think):
1. Much (MUCH) better handling of error messages (especially from STL templates)
2. Better support in the debugger for the STL and templates in general. Why can't we use the debugger to easily browse through a std::vector in the same way we can with arrays, for exmaple?
3. A lot more information/documentation on the issues involved in mixing templates and DLLs. Now that has been a 'fun' learning experience! There is a real 'gap' in the book market - any any 'general purpose' C++ book will contain at least some (and sometimes a great deal) of information on templates, but almost certainly contain no information whatsoever on DLLs. And the 'classic' windows books like Petzold, etc that talk in great detail about DLLs have virtually no mention of templates at all.
4. And just to take this back to where we (sort of) started, I personally have already spent more of my life that I cared to trying to find workarounds to partial specialisation issues, so I'd really like to see VC++ support it!
But I must go - my templates need feeding ...
|
|
|
|
|
#1 we've worked on.
#2 is a great idea, I'm quite sure we didn't do anything here...but I'll try and report back if we did.
#3 sounds like a great article for you to write for MSDN Mag, VCDJ or one of those mags.
Walter Sullivan
Program Manager ATL/MF
|
|
|
|
|
I agree that I rarely develop my own templates but rather use standard template libraries like stl or mtl.
Templates are however very powerful techniques and the lack of them in C# might make me think twice about using C# for most of my work.
Johannes
|
|
|
|
|
I realize you're mostly an MFC programmer, where templates practically don't exist. I also realize that for many reasons you feel obliged to defend MS. I myself am a notorious defender of MS. I'm well known for railing against people who use inflamatory statements or acronyms about MS (such as M$, MicroSlop, etc.). I've also defended technical and market decisions made by MS. For instance, I've defended the level of compliance in VC6 with rabid enthusiasm and convictions. After all, at the time of it's release it was leading in this regard.
However, your attempt to excuse VC7's conformance to the language with the excuse that "who understands templates any way" is actually insulting to everyone involved here... you, me, MS and their customers. After all, this site is as much dedicated to ATL as it is to MFC, and ATL is the most template based framework that I know of. If you program in ATL you understand templates well enough to "take over after a template expert leaves the group".
The most crucial piece missing from VC7's template arsenal is partial specialization. Even if you've never heard of this term you can pick up the technique in a matter of seconds, so long as you can read template code. With out partial specialization many parts of the STL library become very difficult to implement, and useage is made much more difficult. For instance, using std::for_each is a royal pain since you must construct "functors" for so many simple tasks. With partial specialization it's not to difficult to develop "lambda" or "expression template" libraries that allow you to code something as simple as:
void display_elements(std::vector<int>& v)
{
std::for_each(v.begin(), v.end(),
cout << free1 << endl);
}
Someone new to templates may not understand how the above works, but they'll find it much easier to read then the "hand coded functor" approach that would have been used otherwise.
There are so many useful techniques available to us once the compiler supports partial template specialization. Take a look at Boost for several nice examples. The implementation of some of these libraries may be beyond the "template newbie", but the useage of them is definately not, while the power they give even the newbie is more than worth the effort for someone to learn how the implementation works if they have to (and it really isn't that complex).
Sorry, this isn't some geek-wish feature. It's a necessity for generic programming which is required by the language standard. Leaving it out in favor of "global optimizations" which will likely cause many bugs in the first release or "post mortem debugging" which, while nice, is possible with out the compilers help... well, IMHO MS has their priorities royally screwed up.
You're entitled to disagree... just don't do so by insulting everyone, please
|
|
|
|
|
Hey William,
I think you've taken my comments a little too far. I was definitely not trying to say that using templates is too hard, that no one should use them, or that MS shouldn't even bother fixing their compiler compliance so that things like partial template specialization are possible.
My question "is the lack of compliance vis a vis templates really an issue to most developers?" was not rhetorical - I am truly interested in what people have to say about this kind of stuff. I personally have not had a reason to use templates in my programming, so I am totally unqualified to make a statement about templates being good or bad. I have followed discussions about templatised code and have heard the good and the bad - that templates reduce the amount of code you need to write (and hence, potentially, the number of errors you make), that they provide a single elegant solutions to multiple coding tasks, plus a bunch of other pluses. I've also heard the bad - that template code is easy to write, hard to read, and potentially expensive to maintain.
The other point is that VC7 is acknowledged as being a little lax on C++ compliance. Yes, there was a mix up with what we heard from the MS guys at Redmond but Tony Goodhew has already cleared the air on that one. (see also Walter Sullivans response) Tony has stated that Microsoft is working hard for better compliance with the next release. Whether they get it right (in terms of sufficient compliance) or not is something we'll have to wait and see. If partial template specialization is important for you, then write to Tony and tell him. If enough people do this then I'm sure they'll get the message!
I would never try and excuse MS for not having a compiler that supports the features that their customers need. The thing that really struck home when talking to these guys is that they seem truly unsure of what it is that their customers actually want. There was an earnestness among them to try and inclujde the features we want within the time and resources limitations they have. Maybe their market research department needs an overhaul, maybe they need to reduce the number of projects they are working on and concentrate more resources on the basics like compilers and such. Maybe if we all had a chance in Bill's chair we'd do things differently.
Who knows!
cheers,
Chris Maunde
|
|
|
|
|
Man - I cannot believe how a series on what M$ has to say about .NET and stuff has turned into a political crisis on templates.
Relax guys..
|
|
|
|
|
I won't bite on the flame bait. However...
a) I'm not a template guy. I'm a C++ guy.
b) I'm not tense. I am frustrated, and with good reason.
Do you know the number of things available to us that we can't use because of non-compliance with the language? There are a lot of extremely useful packages that either can't be ported to VC, or must be crippled in order to be used by VC. Even the STL provided with the compiler has had to cripple a LOT of things because of non-compliance. VC7 has fixed enough things that through herculean efforts the STL can be made to mostly work, but there are still numerous packages that simply won't. Want a list?
tuples (think of pairs with more than 2 parameters)
lambda/expression templates
slots (think COM events on steroids)
call traits (solves the reference to reference problem)
Even simple things like Regexp++ and BGL (graph library) have had to "dummy down" the implementation for VC++.
This isn't a political tirade. If it were you would not likely find me speaking out against MS. After all, I make a living off of their technology. I know who butters my bread. No, this is a very legitimate complaint about the compiler. There is no excuse (political, business or market driven) for a non-compliant compiler 3 years after the release of the standard
|
|
|
|
|
I stick with MS tools and Windows and recommend them to others because I find I am most productive working with them. However, I get really frustrated about the lack of concern for templates, namespaces, etc. on MS's part.
I write a lot of heavily numeric code. I use C++ because it makes it easier to write and maintain my code than working in FORTRAN, but there are some real performance hits. Some libraries such as Blitz++ claim to be able to remove a lot of the performance hits by making fancy use of templates, including a LOT of partial specialization. Many compilers such as GCC, KAI C++, Metrowerks Codewarrior, Borland C++ Builder, and IBM Visual Age C++ can work with Blitz++, but Visual C++ cannot.
Let me reiterate with emphasis: Templates do not only let you do more with less code. They can also seriously speed up your code at runtime. Anyone working with large arrays (image processing, DSP, scientific and engineering computing, statistical analysis) and who cares about run-time performance should be pushing hard for better template support.
I don't pretend to know all the ins and outs of partial template specialization, but the problem for me is that there are major libraries that would potentially help my productivity and the performance of my code, but I can't use them because of MS's lack of attention to standards compliance.
I would also note that there is a bit of a chicken-and-egg problem here. The way most programmers learn about language features is to try them out and play with them. There is a good book about templates and generic programming (Generic Programming and the Stl : Using and Extending the C++ Standard Template Library by Matthew H. Austern (Addison-Wesley, 1998)), but a poor MSVC developer can't play with the new ideas from the book and learn about where they would and would not be useful because MSVC won't compile the code.
Thus, as long as MS won't support many advanced template features, developers who need these features will buy other compilers and those who stick with MSVC are likely to be unfamiliar with the advantages they would gain from features that MS does not support.
To make matters worse, MFC is actively hostile to many pieces of best-practices C++ coding. As we get into more and more complicated designs, use of C++ namespaces becomes essential to prevent collisions between different libraries' namespaces. However I challenge anyone to derive a class from CObject within a namespace and then use any of the basic MFC features such as DECLARE_xxx/IMPLEMENT_xxx. Similarly deriving abstract classes or template classes from CObject breaks most of the nice functionality that MS put in for simple classes. The library's hostility towards advanced C++ features is pushing me away from MFC in more and more of my coding, and I am sorry because there are many nice things about that library if MS were to maintain it more actively.
|
|
|
|
|
I would like to second the comments made by Jonathan. I write engineering and scientific analysis programs for aerospace trajectory applications. The applications tend to make heavy use of numerical analysis data structures and the like.
I have been investigating porting FORTRAN codes into C++ so that they can be coupled with a Windows GUI and maintained with one complier on a microcomputer. Some of the FORTRAN is heavily numerical analysis based and having seen the claims made by Blitz++, I am eager to get highly efficient version of the code working. The problem, is as Jonathan points out, Visual C++ does not support the template features needed to make it easy (possible??) to use Blitz++.
I wonder if Microsoft really ever polls the engineering and scientific computing communities to discover their issues? Not every developer is focusing on business and e-commerce applications.
On another note about MFC, I wanted to use multiple inheritance and templates on an object I wanted to "serialize" using MFC's CObject and serialization API. I found that I could not!! I have had it with MFC and hope Microsoft will embrace WTL and move MFC features to WTL, rearchitecting along the way. Any chance an ATL/WTL version of the serialization API might make it into the next C++ compiler
|
|
|
|
|
The last I've heard about WTL is that Microsoft has abandoned it as a mistake. So, I guess, there is'nt much hope that it will become the next MFC.
Christian Anderse
|
|
|
|
|
Maybe I did read more into what you wrote than what you meant. However, I still find it baffling that anyone would except anything less than full compliance from any compiler released from this point on by any company. It sure seemed to be that you were making excuses for them claiming that most programmers don't want the features that are missing in any event.
As for the question, since it's not rhetorical, yes it is a very big issue. So long as you're only using the compiler to write GUI MFC applications this is a non-issue to you. However, even ATL coders have to be feeling the crunch here, and anyone using the compiler to write server side components (especially if such components need to be portable) is vastly concerned about such issues. Further, even if you only do GUI coding, if you use the STL to any extent at all you should care very much about this issue.
BTW, your last paragraph misses the mark! I'm not talking about "features that MS's customers need". I'm talking about language compliance. You can leave a "feature" that's required by the language out just because you believe your customers don't want it
|
|
|
|
|
Your example does not convince me. It's elegant, ok, but not more.
- The gain in understandability and number of lines relative to writing the print statement explicitly in a function is marginal.
- If you typedef the iterator for the vector, which you would do for every serious iterable type anyway, then the example rewritten without the for_each is at least as clear (and everyone understands it).
- If you want to do even a little bit more of work within the loop than in this trivial example, then the notation gets hopeless very quickly.
I've read the book "Generic Programming and the STL" and I like the concept of generic programming. However, I see no use for the advanced features in day-to-day C++ programming. Basic lists, vectors and iterators: they are great and I use them all the time. The advanced features: nice but I have yet to discover a killer app for them. The real problems of programming seem to lye elsewhere.
What irritates me is that "intellisense" does not work with iterators (members do not show up) and the noisy error messages if something is wrong with template-based code. I certainly hope these problems are fixed, they are of far higher priority to me than partial template specialisations.
So I agree with Chris. I don't think he or Microsoft is insulting us. As far as I'm concerned, they made the right kind of prioritization
|
|
|
|
|
One point which I haven't mentioned yet is the improvement in error messages for templates in the new compiler. The error messages are far less "noisy" and the variable types will be resolved back to more intelligent names, instead of the mess of angle brackets that is currently offered.
cheers,
Chris Maunde
|
|
|
|
|
We'll also point you at the instantiation with the compiler error and not the base template when appropriate.
Symbol names in the debugger and other places can be longer than 256 chars which is also a problem in our tools that was aggrivated by increasing template usage.
Later,
Walter Sullivan
Program Manager ATL/MF
|
|
|
|
|
> Your example does not convince me. It's elegant, ok, but not more.
It was the simplest of examples. I could give plenty more, but instead I'll
address your points here.
> - The gain in understandability and number of lines relative to writing the
print statement explicitly in a function is marginal.
It's not marginal when the functionality becomes more complex.
> - If you typedef the iterator for the vector, which you would do for every
serious iterable type anyway, then the example rewritten without the for_each is
at least as clear (and everyone understands it).
I'll almost buy this. However, for_each is the simplest of algorithms. An
example using merge with a complicated predicate would illustrate the
differences better. Explicitly writing this code with out the algorithm may be
understandable, but it's a lot of code to write which can lead to logic errors.
Sorry, I won't do with out algorithms even if I have to do without lambda
functions.
> - If you want to do even a little bit more of work within the loop than in this
trivial example, then the notation gets hopeless very quickly.
Evidence? I can show you very complex lambda expressions that are easier to
write and comprehend then the equivalent hand coded for loop. Lambda
expressions are similar enough to standard C++ constructs to be immediately
intuitive... more so than hand coded functors and simpler than hand coded loops.
> I've read the book "Generic Programming and the STL" and I like the concept of
generic programming. However, I see no use for the advanced features in
day-to-day C++ programming. Basic lists, vectors and iterators: they are great
and I use them all the time. The advanced features: nice but I have yet to
discover a killer app for them. The real problems of programming seem to lye
elsewhere.
You seem to lump algorithms into the advanced category. They don't fit there,
and they have every day applicability.
> What irritates me is that "intellisense" does not work with iterators (members
do not show up) and the noisy error messages if something is wrong with
template-based code. I certainly hope these problems are fixed, they are of far
higher priority to me than partial template specialisations.
Most iterators don't have members, per se, only operators. Further, a lot of
iterators are nothing but pointers so there is nothing for a debugger to show
you. Error messages are a concern, but compiler vendors (including MS in VC7)
are addressing this, and there are coding techniques that can be employed to
reduce the "noise" and produce understandable error messages. As for
priority... our priorities differ greatly... and the numbers that fall into the
two camps is near 50/50.
> So I agree with Chris. I don't think he or Microsoft is insulting us. As far as
I'm concerned, they made the right kind of prioritization.
What was insulting wasn't the prioritization (though that's frustrating for a
very large segment of coders), but the reason given for the prioritization.
|
|
|
|
|
What's "Boost"?
Link? Reference? Author name?
TIA
|
|
|
|
|
> What's "Boost"?
It's an organization that's supplying C++ libraries to enhance the standard libraries, with the hope of consideration in later standards.
> Link? Reference? Author name?
http://www.boost.org. There's no single author. Instead, libraries are submitted by developers and go through a peer review before inclusion.
If you're a C++ developer you should really check it out
|
|
|
|
|
When Visual Basic didn't have classes, there appeared an article in a VB magazine titled
"Who needs classes anyway?"
If the so-called advanced techniques are so unwelcome then perhaps we should go back to Dbase III or
even COBOL.
set talk off
set bell off
do process
set bell on
set talk on
Advanced techniques - who me?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
