|
|
Comments and Discussions
|
|
 |

|
Heh, the article would be 50 pages long if Chris tried to ask about ever user's gripe.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|

|
Tim Smith wrote:
Heh, the article would be 50 pages long if Chris tried to ask about ever user's gripe.
But hey! That's his job! I mean that's what we pa-
oh... yeah...
...never mind.
|
|
|
|

|
hehehehe
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|

|
It's already been stated that PTS is working, and Loki compiling at Microsoft internally. Herb may have thought it was old news - we are guarenteed PTS in the first service pack which is due mid year AFAIK.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
|
|
|
|

|
While working on a MSVC port of Loki, me and a few others before me, stumbled upon a (perhaps accidental) M$ extention of C++ templates. The M$ compilers allow you to specialize nested template classes, which can be used a work-around for the lack of PTS in many (though not all) cases.
You can implement any PTS of the 'partially-specified template paremeters' flavor; but you cannot implement the 'special behavior with this combination of parameters'. With that you turn to aggregation, MI, and overloaded functions. Very messy compared to the straight-forward PTS implementations... but it can be done.
- Magmai Kai Holmlor
|
|
|
|

|
What Herb and, in another interview, Stan are telling the C++ community about the new MS direction sounds (perhaps too) good, but how can we see if they - MS - stay on track? My evaluation criteria are mostly a consequence of my reasons for using C++ in the first place. I like to use C++ because it is "The Language of Choice" (pun intended): I) C++ allows us to "write efficient, tight, fast code" without having to choose >between< performance and other design qualities, but >among< all of them, e.g. better performance against runtime flexibility, w/o loss of abstraction (like using templates instead of inheritance in some places). II) C++ serves us well if we have to create modules/components wich can be used in totally different contexts even if they have to be closely integrated. (This is what Loki etc. is all about.) III) C++ will allow us to combine many different generic components which can closely interact without loss of performance or type safety. Now, what do I want to see in the "ultimate VC++ system": 1) I want to be able to cleanly separate code which directly uses .Net from code which doesn't. It should also be possible to port libraries like ACE and QT to .Net so some code can even use .Net functionality without knowing of it. (And, of course, without performance penalty.) Some .Net functionality must be available with standard library bindings, e.g. special IOStreams, standard conforming i18n, Iterators for data access etc. 2) I want to be able to use all this funky, cool new template metaprogramming stuff, eg. in the Loki, Blitz, MTL, FACT or FC++ libraries, so: a) VC++ must compile them flawlessly b) it must create fast code, eliminating the abstraction penalty of e.g. maybe dozens of layers of inline functions c) it must compile and link any template jungle blazingly fast d) debugger and profiler must give us easy and flexible access to template specific information, e.g profiles of >all< instantiations of a template function vs. profiles of >specific< instantiations e) error messages from template code need to became legible, IMHO we need some kind of expandable/navigable/configurable hypertext system 3) I want to use true multi-paradigm design and programming techniques productivly, so code (class) browsers, wizards etc. need to became template aware and have to support generic programming as effectively as OO 4) I want to design and program more agile, so i would need tools which allow better restructuring of project/modules/configurations and fast refactoring of source code (a refactoring browser for C++ is long overdue, and maybe integrating unit test could be made easier) These points definitly comprise a tough order, an I am aware of some of the reasons why they have not been realized yet, or may even be seen as totally unrealistic, but this is what C++ is all about: If you don't like it, write tools for "easier" languages. If you - or someone else - manages to achieve all this, we could paraphrase Winston Churchill: "Never in the field of" ... C++ programming ... "was so much owed by so many to so few." Just my 2 cents, Uwe
|
|
|
|

|
Uwe Schnitker wrote:
Loki, Blitz, MTL, FACT or FC++ libraries, so:
An interin compiler release at MS$ already compiles fully this libraries, expect this on sp1.
Uwe Schnitker wrote:
ACE and QT to .Net
What ! QT sucks! Any library that uses a proprietary sistem of Event Dispatching que must pass for their custom (moc) compiler is totally idiot,c++ is the most powerfull language, and they're much more cleaner solutions to this kind of GUI dispatch. AFAIK Delphi 6 and Kylix uses QT, but Borland replaced this evil Event dispatching for a their own,so it doesn't need to be compiled every time we add a Event/Signal Slot to the class
I'm currently studying ACE, it's a very powerfull framework, also a complex one, and will be interesting if the C++ and pattern gurus that designed it, ported it to .NET .
In all other aspects I tend to agree with you on a 100% margin.
Cheers,
Joao Vaz
|
|
|
|

|
>Joao Vaz wrote: >>Uwe Schnitker wrote: >>Loki, Blitz, MTL, FACT or FC++ libraries, so: >An interin compiler release at MS$ already compiles fully this libraries, expect this on sp1. That's really nice, great, formidable, whatever ... >>ACE and QT to .Net >What ! QT sucks! IMHO, it has a nice architecture and a sound OO design. It is powerfull, versatile, flexible and yet very easy to use. Quite a feat. >Any library that uses a proprietary sistem of Event Dispatching que must pass for their custom (moc) compiler is totally idiot, No! It's a pain in the neck, and it's definitely a wrong idea according to the principles and philosophy of modern C++. But it was/is a viable way to support broken compilers, and it was a quite sensible design solution in the context of "classic" (pre-modern) C++, which is where most C++ programming is done today, whether we like it or not. >c++ is the most powerfull language, You're so right ... > and they're much more cleaner solutions to this kind of GUI dispatch. Definitely! The "signal/slot" approach should be integrated into a generic, policy-based callback system, working with generic functors, both of them also supporting non-intrusive use. ("Andrei ...") I'd suggest - and I'll try it in my own, future work - to encapsulate all this unholy QT stuff in a small part of the application, just like other legacy stuff. (Definition: Legacy code is code written in a way you don't happen to like.) And I'll wait and hope for the future - unfortunately, working on a full-blown portable GUI framework isn't something I'll get into in the near future. >In all other aspects I tend to agree with you on a 100% margin. ("blush") Have fun, Uwe
|
|
|
|

|
Uwe schnitker wrote:
The "signal/slot" approach should be integrated into a generic, policy-based callback system, working with generic functors, both of them also supporting non-intrusive use. ("Andrei ...")
Quite a nice idea, it the trolltech guys listen to you ... Perhaps in QT4 ?
Uwe schnitker wrote:
full-blown portable GUI framework isn't something I'll get into in the near future.
I don't want to have anything with that ! Portable Gui frameworks means too much work ...
Uwe schnitker wrote:
yet very easy to use
QT it's not a modern frawework , it's not templatized , but also it's not bad either, it's the pain in the neck that I refuse to take.
When they change the design of it, perhaps I'll the first to use it, if not ... well perhaps wxwindows or gtk--(templatized framework) using gtk+
Cheers,
Joao Vaz
|
|
|
|

|
Totally unexpected.
R.
ps: Herb,
I hope you will have time to keep working on www.gotw.ca, the conversations column and "Even More Exceptional C++", "Yet Some more Exceptional C++" and "I do still have some Exceptional C++ so you mere mortals realize those subtle details about C++ and say 'I though I was proficient with C++ sigh'"
pps: Who's next? Bjarne Stroustroup? Scott Meyers? Andrei Alexandrescu? :p
|
|
|
|
 |
|
|
General News Suggestion Question Bug Answer Joke Rant Admin
|
Herb Sutter has just joined Microsoft as their new Visual C++ .NET community guy. Read about who he is, what he does, and what is happening with our beloved Visual C++.
| Type | Article |
| Licence | CPOL |
| First Posted | 12 Mar 2002 |
| Views | 354,579 |
| Bookmarked | 18 times |
|
|