|
|
Comments and Discussions
|
|
 |
|
|
And that's already OUT OF THE STANDARD! A prime advantage of the standard is portability, but never mentioned in this interview. The moment I read sentence saying MFC/ATL/WTL is not gonna be in this interview, I knew this is no more than a "commercial" interview that keep C/C++ away from GCC/LINUX.
Stanley Lippman as an experienced developer, he should not blind fold his eyes and talk. We want a language that give freedom and meta, not a language that helps promoting a product. The CRT/STL itself is built by C/C++, that's what we want.
Couldn't understand why .net couldn't be access like native GDI+. Answer: So as time goes by, more and more young developers are addicted to C#, C/C++ will doom and together with GCC/LINUX. Smart eh!?
|
|
|
|
|
It is nice that the VC++ on a medium-scale timeframe targets "to ensure that" VC++ "will compile the most popular libraries such as Boost, Blitz, Loki and a fully compliant version of STL". However, these words could be interpreted in a way that would lead to an unsufficient result.
Let us elaborate on the goal:
1)Obviously, in our context "popular" doesn't mean "in heavy use today", because people can only use these libs if their compiler permits. so I would strongly suggest to add some less known libs, e.g. for functional programming (FACT,FC++ or LL), as targets/benchmarks.
2)Libs like Boost and STLPort use a vast amount of dirty hacks to ensure that they can work with broken compilers. Your aim must be to compile the most advanced libs without them using special switches, i.e the "#ifdef VC ..." sections should be almost empty.
3)C++ programming using advanced generic libraries leads to a totally different code structure than programming with Java-style OO-frameworks. There are lots of small classes with inline functions instead of inheritance and virtual functions, and typically simple user code gets expanded to a huge maze of forwarding functions calls with many levels of indirection even to do straightforward. Unless the compiler is able to almost totally optimize away this abstraction penalty, this will never do.
AFAIK the VC++ compiler is really good at optimising C -like code, and provides a good implementation of the C++ OO features (viruals, etc.), but it will need to become much better at small object optimisation, inlining, removing unnecessary code by restructuring, etc. Programming with such libs leads to a lot of complicated code which can be "folded" at compile time into something very simple, but only if the compiler tries first to inline even very complicated looking functions, and refuse to inline only after checking that they don't "collapse" even after very sophisticated optimisation attempts.
4) Of course, all this has to be done really fast, i.e. the compiler must be able crunch lots of templates, with many parameters and many inline functions, and with many levels of indirections.
5) Providing a new level of understandible error messages as well as new tools to analyse and debug template code would even make it easier to became "the C++ implementation of choice".
Just my two cents,
|
|
|
|
|
Consider:
template
class CVTView : public CView
{
protected: // create from serialization only
CVTView();
DECLARE_DYNCREATE(CVTView)
//Blah blah blah
private:
std::list m_TPtrList;
};
This creates a ruckus with the
IMPLEMENT_DYNCREATE and MESSAGE_MAP macros,
not to mention that ClassWizard runs amok. So
its back to the typing wizard, expanding all the
macros and typing in the entries into the message
map.
Question is, are the macros and ClassWizard
going to become more sophisticated?
Satheesh
To the moderator:
BTW I should have posted this in the
main Visual C++ section, can u shift it there?
thanks
|
|
|
|
|
"Microsoft will not sacrifice code-generation quality or robustness at the cost of extreme compliance".
Dose the compiler rely on non-compliant feature to ensure quality or robustness? Or is the compiler design so less extensible that independent components are tiedly coupled? Anyway, one could hardly image this is the excuse for not including partial specialization. IMO, standard compliance should not reduce, but instead enhance, the quality of the compiler design. (BTW, I like VC++ very much. It's really a good product.)
|
|
|
|
|
The only valid argument that can be made is time required to implement such features. Development resources and time are limited. Assume that you are going to release a new version of Visual C++ 12 months from today. You pick and choose the features that can fit in that time frame. You will drop some features for the sake of others. There will be times when you will drop features which are only there to make the compiler more compliant with the C++ Standard so that you can get other features in to improve code-generation quality and robustness.
I have a real product that I ship, which currently compiles with Visual C++ 6.0. If I had to choose, I would rather have a faster compiler, that produces better optimized code, then support a Standard C++ feature that I may never use.
|
|
|
|
|
Sorry, I'm confused. Are you saying that it isn't necessary to stay 100% compatible with the accepted standard if a company has an ambitious release date to make?
Isn't the whole point of establishing a standard to have that standard be adhered to by the industry? If not, then it isn't really a standard, is it? Wouldn't it be more accurate to refer to it as a guideline?
In your example with the 12-month release date - wouldn't it be better for the company to set its release date based on the time it will take them to create a 100% compatible product than for it to arbitrarily set a 12-month deadline and the compromise the product in order to meet that deadline?
After all, if they don't, isn't there a chance that your product that was written in VC++ version x might not compile in the next version if one of the C++ features that you use gets sacrificed to make the 12-month release date.
Any thoughts?
|
|
|
|
|
>>> Sorry, I'm confused. Are you saying that it isn't necessary to stay 100% compatible with the accepted standard if a company has an ambitious release date to make? <<<
No, that's not what I said.
|
|
|
|
|
Surely 'export' would be a major feature for C++ templates.
It would allow us to write huge template class member functions and compile them once (presumable into an intermediate goo) such that the linker (or whatever) can automatically create the code for all instantiations when the final app/dll is created.
------------------------------
http://www.rcl-software.org.uk
------------------------------
|
|
|
|
|
You may compile it once with explicit template instantiation indeed right now with 12.0. It is not automatic however but the effective solution.
And IMO the automation of such process may appear to be harmful in some situations. So, I would rather agree with MS that the "export" concept needs to be more well-grounded.
With regards,
Michael Kochetkov.
|
|
|
|
|
> You may compile it once with explicit template instantiation indeed right now with 12.0.
> It is not automatic however but the effective solution.
Indeed, this is what we do now:
template class CAnyTemplateClass;
> And IMO the automation of such process may appear to be harmful in some situations.
I would be interested in seeing an example of where it could be harmful.
------------------------------
http://www.rcl-software.org.uk
------------------------------
|
|
|
|
|
> > You may compile it once with explicit template instantiation indeed right now with 12.0.
> > It is not automatic however but the effective solution.
> Indeed, this is what we do now:
> template class CAnyTemplateClass;
BTW this is ill-formed -- template argument list is missing.
> > And IMO the automation of such process may appear to be harmful in some situations.
> I would be interested in seeing an example of where it could be harmful.
Generally speaking, making template instantiation process automatic may lead to the situation when you lose the control upon the amount and the make-up of instantiated code especially in large projects.
"Export" may appear to be the useful feature. But let us consider the situation we have right now:
having template void f(...); declaration in a header file and it's definition and all the necessary explicit instantiations in a cpp file you can control all the additional instantiations in your project the following way. You get a linker error and analyze the situation if you really need this very instantiation or can reorganize your code some different way. It is sometimes the totally different way  as I have more than once found myself.
The unconscious automatization may lead to code swelling at best or you may miss some "particular" cases when you might need the an explicit template specialization.
One may consider that the problem is far-fetched. Then another reason against "export" (in respect to MS, I suppose) is that the existing "export" problem has the solution which is not that ugly and effective enough. While reading "The Design and Evolution..." by Mr. Stroustrup I was convinced by him that it is very serious reason.
With regards,
Michael Kochetkov.
P.S. To the moderator: it seems that e-mail notification does not work.
|
|
|
|
|
> > > You may compile it once with explicit template instantiation indeed right now with 12.0.
> > > It is not automatic however but the effective solution.
> > Indeed, this is what we do now:
> > template class CAnyTemplateClass;
> BTW this is ill-formed -- template argument list is missing.
O-o-ops, I have gotten why it is missing.
> ... having template void f(...);..
It shall be "...template <class T> void f(...);..."
Let us see how it looks "as-is (no HTML)"
With regards,
Michael Kochetkov.
|
|
|
|
|
With HTML on, write
< for <
and
> for >
-----------------------
www.rcl-software.org.uk
-----------------------
|
|
|
|
|
> But let us consider the situation we have right now
For templates, I put the class declaration in a .h file and the non-inline member function definitions in a .hpp file:
MightyUseful.h:
template <class T>
class MightyUseful
{
...
};
MightyUseful.hpp:
#include "MightyUseful.h"
template <class T>
MightyUseful<T>::MightyUseful()
{
}
I tend to use template classes with user defined classes, so I write something like:
MyClass.h:
#include "MightyUseful.h"
class MyClass
{
};
typedef MightyUseful<MyClass> MyClassMightyUseful;
MyClass.cpp:
#include "MightyUseful.hpp"
template class MightyUseful<MyClass>;
This works fine, but is a bit of a pain to explain when you are writing libraries for other people to use.
> The unconscious automatization may lead to code swelling at best or
> you may miss some "particular" cases when you might need an
> explicit template specialization.
I take my hat off to anyone who has implemented a C++ compiler, but surely what you are talking about is a mere implementation detail of the compiler. What I mean is, it must surely be possible for the compiler/linker to work it out automatically (and without any code duplication). I do understand that it would be a pain to implement, though.
-----------------------
www.rcl-software.org.uk
-----------------------
|
|
|
|
|
[...]
> MyClass.cpp:
> #include "MightyUseful.hpp"
> template class MightyUseful<MyClass>;
It is just a cavil but the last line requires MyClass to be complete, i.e. you shall include MyClass.h as well.
[...]
In your terms given above I prefer the folowing way:
MightyUseful.hpp --> MightyUseful.cpp:
// MightyUseful.cpp begins
#include "MightyUseful.h"
template <class T>
MightyUseful<T>::MightyUseful()
{
}
#include "MyClass.h"
typedef MightyUseful<MyClass> MyClassMightyUseful;
// MightyUseful.cpp ends
The reason is to help a compiler and a linker, to save some time and disk space.
[...]
> This works fine, but is a bit of a pain to explain when you are
> writing libraries for other people to use.
Hm... That seems to be the core feature of the language. It is not the trick or a special technology. You do not have to explain it -- just document it. But nonetheless I agree with you.
[...]
> I take my hat off to anyone who has implemented a C++ compiler,
> but surely what you are talking about is a mere implementation
> detail of the compiler. What I mean is, it must surely be possible
> for the compiler/linker to work it out automatically (and without
> any code duplication). I do understand that it would be a pain to
> implement, though.
Let us imagine that we have a C++ preprocessor that is capable to generate MightyUseful.cpp in my terms for a large project... for parameterized stuff with the export keyword ahead. It is not that hard to write such a tool (having EDG in mind), is it???
With regards,
Michael Kochetkov.
|
|
|
|
|
> It is just a cavil but the last line requires MyClass to be complete,
> i.e. you shall include MyClass.h as well.
Taken for granted.
> // MightyUseful.cpp begins
> #include "MightyUseful.h"
> template <class T>
> MightyUseful<T>::MightyUseful()
> {
> }
>
> #include "MyClass.h"
> typedef MightyUseful<MyClass> MyClassMightyUseful;
> // MightyUseful.cpp ends
>
> The reason is to help a compiler and a linker, to save some time and disk space.
Did you mean template class MightyUseful<MyClass>;
rather than typedef MightyUseful<MyClass> MyClassMightyUseful;
Either way, the problem there is that you need to modify MightyUseful.cpp every time a new class uses it. If MightyUseful.cpp were a third party class, that would mean modifying third party source code!
Perhaps a better solution would be to have MightyUseful.hpp contain the source code, and for each project to have a MightyUseful.cpp that contains all the explicit instantiations for that project.
> Let us imagine that we have a C++ preprocessor that is capable to generate MightyUseful.cpp in my
> terms for a large project... for parameterized stuff with the export keyword ahead. It is not
> that hard to write such a tool (having EDG in mind), is it???
Sounds good.
-----------------------
www.rcl-software.org.uk
-----------------------
|
|
|
|
|
> > The reason is to help a compiler and a linker, to save some time and disk space.
> Did you mean template class MightyUseful<MyClass>;
> rather than typedef MightyUseful<MyClass> MyClassMightyUseful;
No.
> Either way, the problem there is that you need to modify
> MightyUseful.cpp every time a new class uses it. If
> MightyUseful.cpp were a third party class, that would mean
> modifying third party source code!
> Perhaps a better solution would be to have MightyUseful.hpp
> contain the source code, and for each project to have a
> MightyUseful.cpp that contains all the explicit instantiations
> for that project.
I was dead sure I was talking about this thing -- one cpp file that contains all the instantiations for a project. It looks like that my English have let me down, sorry. I have ment MightyUseful.cpp to
be your that very file that contains all the instantiations. And as far as the templates definitions _are_needed_only_for_this_very_file you may put them into this file as well (but you may preffer to put them in a different file, say MightyUseful.hpp, I have just emphasized the accented assertion above). Anyway, it does not matter at all. The main idea is the single file. It may appear to be very convenient in some cases. That was my main idea. It was probably vaguely formulated and made you guess but my English is not perfect indeed
--
With regards,
Michael Kochetkov.
|
|
|
|
|
Yes, very good, I see what you are saying now.
-----------------------
www.rcl-software.org.uk
-----------------------
|
|
|
|
|
> You may compile it once with explicit template instantiation indeed right now with 12.0.
> It is not automatic however but the effective solution.
Indeed, this is what we do now:
template class CAnyTemplateClass<CAnyType>;
> And IMO the automation of such process may appear to be harmful in some situations.
I would be interested in seeing an example of where it could be harmful.
------------------------------
http://www.rcl-software.org.uk
------------------------------
|
|
|
|
|
I'm not sure what the standard explicitly says, but I suspect that an implementation of the export keyword would not necessarily allow you to compile them once into a library since you have a standards requirement to only compile things that are used (or explicitly intstatiated) - and this is crucial for alot of partial template specialisation stuff to work.
Where export is crucial though is avoiding circular include dependencies in large templatised libraries. Quite often you have to compromise a design to avoid the circular include which would not exist if the exported template definition sat in a cpp file somewhere not in the include chain.
Dave
|
|
|
|
|
I hope microsoft finally get round to implementing template within template support. This is required to compile the excellent Loki library.
See "Modern C++ Design" written by Andrei Alexandrescu. This book basically documents the Loki library, which is available at:
www.awl.com/cseng/titles/0-201-70431-5
Regards,
Simon Hughes E-mail: simon@hicrest.net Web: www.hicrest.net
|
|
|
|
|
Loki is one of several template based libraries we're look at as benchmarks or scenarios.
Walter Sullivan
Lead Program Manager, ATL/MFC
|
|
|
|
|
|
Then you will be happy to hear that this works with Visual C+ 7.0.
Ronald Laeremans
Visual C++ compiler team
|
|
|
|
|
I really don't think VC++ will have much role in .NET, much less be the power language. Why? In .NET, speed is not very much given priority. I looked at C# and think that it will be more suitable.
Anyway, I think we don't have anything to worry because .NET is just a better J2EE. Why would you program in CLR? Win32 environment is still better, unless you're doing distributed apps.
All the circus about .NET are only due to Microsoft marketing muscle.
|
|
|
|
|
>Why would you program in CLR? Win32 environment is still better
As the CLR improves, I foresee it replacing the Win32 API with something a little more object oriented. That's always been Microsoft's vision from the Cairo days and I see the CLR and the .NET framework being the first step.
Michael
|
|
|
|
|
Stormwind wrote:
Win32 environment is still better, unless you're doing distributed apps.
Yeah, like the good old days when DOS was better than Win16, and Win16 was better than Win32S an Win32S was better than Win32.
Furor fit laesa saepius patientia
|
|
|
|
|
Win32S was better than Win32.
I agree totally with your basic point, but this last bit is a stretch. I don't think win32s was ever better than anything else!!
-----------------------------
"I leave no turn un-stoned." - John Simmons, Nov 6 2001
-----------------------------
|
|
|
|
|
Win16/Win32 superseded DOS because GUI became a necessity. If services and distribution will become a necessity, surely .NET will supersede Win32 api.
Note: after more than 15 years of windows platform, there are still a lot of console programs.
"They no longer matter!" - Magneto
|
|
|
|
|
Stormwind wrote:
Why would you program in CLR? Win32 environment is still better, unless you're doing distributed apps.
All the circus about .NET are only due to Microsoft marketing muscle.
I couldn't agree more. If we wanted to use a CLR like programming language we would be using Java NOT a .NET language.
Visit Ltpb.8m.com
Looking for more tutorials? Ltpb.8m.com/Tutorial
3D Image Library: Ltpb.8m.com/Image
Surf the web faster than ever:
http://www.404Browser.com
|
|
|
|
|
"Microsoft will not simply implement features because they are specified in the standard"
Why not ? Isn't the standard what the language is supposed to do ? Period, no, ifs ands or buts.
Otherwise why have it ? It seems to me that if a language is specified to have features X, Y and Z, then any company implementing a compiler needs to implement X, Y and Z. Who is Microsoft to just arbitrarily pick and choose ? And if they feel the feature is "theoretical" then there is no way to really find out, since no one will be able to use the feature, since it is not implemented. An endless catch-22.
If the feature is incredibly difficult and impractical to implement then why not lobby to have it removed ? Lord MS spends millions and millions of dollars on R&D, they have hired some of the best and brightest in the field and they cannot make a compiler that correctly implements the C++ language ? C'mon...
I don't doubt that every member of the VC++ team works very hard, but this is a little difficult to buy into.
|
|
|
|
|
Lord MS spends millions and millions of dollars on R&D, they have hired some of the best and brightest in the field and they cannot make a compiler that correctly implements the C++ language? C'mon...
I read somewhere a comment by a Microsoftie that they are kinda tied up with the .NET / MC++ right now, so we may have to wait for a while for the full standard conformance.
However, I'd be interested to know how they pick and choose what part of standards they decide to implement and leave out for the next version. Are these based on customer feedback or what?
// Fazlul
Get RadVC today! Play RAD in VC++
http://www.capitolsoft.com
|
|
|
|
|
>I'd be interested to know how they pick and choose what part of standards
Well that's what bothers me - they shouldn't get to pick and choose. It is either C++ or it isn't. And if it isn't then it is just some subset and shouldn't be called C++ (maybe C+-... ).
Perhaps this is naive, but I am presuming that the features that make up the C++ standard are there for a reason, hopefully one that has been hashed out extensively. Isn't that the whole point of the C++ Standards commitee ?
|
|
|
|
|
Jim, make no mistake - Microsoft wants C++ to die and pass out.
They will try to drift it apart from standard as far as they can and at the same time they will pretend not to. That is typical and it's not the first time from MS side.
It seems to me that Mr. Lipman has already been polluted by the Microsft ideology so he can easily use their language - in one sentence said one thing and in the next say the opposite. I foresee his best carier because he already grasped the key to success...
|
|
|
|
|
That sounds more like a conspiracy theory. Any Microsoftie out there to defend?
// Fazlul
Get RadVC today! Play RAD in VC++
http://www.capitolsoft.com
|
|
|
|
|
No point trying to defend. George has his own view on what Microsoft are trying to do. Nothing anybody can say will change that viewpoint. There is no evidence that Microsoft want to kill off C++. Why would they try and kill off the language that most of their stuff is written in. Why would they want to alienate their developer base just when the battle against Linux is starting out. Microsoft knows they can't afford to lose good C++ developers to the open source enemy.
Michael
|
|
|
|
|
|
|
Andy Metcalfe wrote:
I sincerely hope you're winding us up and don't believe that...
I don't think I am the first to metnion such a possibility on CP. I am not sure about C# vs C++, but MS Word is not written with MFC and I doubt they are migrating it to C# either...
|
|
|
|
|
|
We've been through this before.
The codebases of Word, Excel, Powerpoint, NT and other apps often have pre-dated MFC. There haven't been significant rewrites, and some newer pieces of these apps use MFC. Publisher, Money, MMC, Encarta, Mappoint, Streets, PictureIt, and more are MFC apps...and coincidentally, are newer apps.
However, not every new app at Microsoft is written with MFC because our dev teams are free to choose the tools they think they'll be most productive with. As we all know, C++ developers often think they can write it better themselves and that certainly is true at Microsoft.
Virtually every commercial application, most mission critical applications, most of the trading apps on Wall Street, many Healthcare apps, and tons more are written in C++ and those are clearly important apps to have on Windows...we're not getting rid of our C++ tools.
There was a time when people thought Microsoft was going to get rid of everything but VB...
Walter
|
|
|
|
|
George wrote:
They want everybody to use .NET and C# and meanwhile they will make their own stuff in C++.
www.microsoft.com/backstage
cheers,
Chris Maunder (CodeProject)
|
|
|
|
|
Using Microsoft.com as an example misses the point. It seems unlikely(impossible?) that MS would develop their next OS in C# running on top
of the CLR.
The point is that there are way more uses for a general language than what MS seems to have in mind for developers.
Some assumptions are made as well, particularly, (1) that my app can afford the overhead associated w/ .net, (2) that my app would benefit from the features of .net.
In response to:
"whether those features are compelling enough that it becomes apparent that their customers want them."
It becomes apparent that their customers want them when they ask for them. Enough people have asked for standardization that it should be apparent.
The compelling aspect is that the features have made their way through the standards process.
A simple thought-experiment: if there was a switch that would turn on full compliance w/ the standard, who wouldn't use it?
Anyway, thanks for the interview.
|
|
|
|
|
Fazlul Kabir wrote:
That sounds more like a conspiracy theory.
I wish you were right, but I'm afraid that't the direction MS is going...
|
|
|
|
|
I think the article might be a bit misleading in so far as this quote was related only to the topic of implementing C99 features in the compiler, not about implementing features in the C++ standard.
Ronald Laeremans
Visual C++ compiler team
|
|
|
|
|
As a long time follower of the Boost libraries project (www.boost.org) I am very encouraged by people like Jason Shirk at Microsoft (and Howard Hinnart at Metrowerks) for actively keeping an eye on Boost and attempting to feedback problems into their respective compiler teams.
In consequence my next compiler is likely to be from one of their companies.
I am a little concerned that Jason's progress in implementing standards compliance issues seems to be scheduled for MSVC 7.1 someway off (seemingly late next year). Its a shame more can't be done to include some of this in the initial 7.0 release.
The importance of templates actually working, and other more advanced features relating to metaprogramming etc cannot be under-estimated.
Oh well there is always gcc until then
|
|
|
|
|
Actually, my understanding is that most of the standard has been implemented (export being the one exception, but no one's going to complain about that) but for quality assurance and time reasons caused by marketing and other corprate initiatives a few of them (partial template specialization, for example) won't make it in 7.0. In other words, MS tried VERY hard to get there and deserves a lot of recognition for this. It's only pressures outside of anyone's control that will prevent a few features from being included in 7.0. Knowing this, and knowing of the effort and passion the MS team is putting into this I'm quite happy to wait for 7.1. In the mean time, 7.0 is light years ahead of 6.0 and allows most of what we need.
William E. Kempf
|
|
|
|
|
I'm a little surprised that, being such a toplevel C++ programmer as you are, you haven't put more emphasis on the importance of partial template specialization and how the lack of it in 7.0 shuts off the gates of metaprogramming paradise --or at least a good portion of it.
In my opinion, PTS is the single most productive feature of the last C++ standard, and it is only now that people are realizing what a great deal of amazing things PTS allows them to do. It's a pity MS folks haven't caught up yet.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Don't get me wrong... I want PTS in VC++ as much as anybody. But there's a few reasons I'm willing to live with out it in 7.0. First, MS has this done and so I know it will be in 7.1. Second, 7.1 is likely to be out this year as well. Third, they've become compliant enough with most of the rest of the standard that some well known work arounds can be employed most (not all) of the times when you'd want PTS. Fourth, the attitude change I've had first hand experience with from MS has made me more willing to forgive the lack of PTS, especially since it's missing only for reasons out of the control of the developers.
William E. Kempf
|
|
|
|
|
|
|
 General  News  Suggestion  Question  Bug  Answer  Joke  Rant  Admin
|
Stanley Lippman talks about the future of Visual C++ .NET
| Type | Article |
| Licence | CPOL |
| First Posted | 13 Nov 2001 |
| Views | 351,354 |
| Bookmarked | 20 times |
|
|
Submit an article or tip
Post your Blog
template func instantiations to generate unique code!
They want everybody to use .NET and C# and meanwhile they will make their own stuff in C++.
