Welcome to MSDN Blogs Sign in | Join | Help

Just What Is This TR1 Thing?

Hi there. Rob Huyett here again. I’m an SDET on the VC Libraries team. One of the things I’ve been working on lately is the new TR1 add-on for Visual Studio 2008. When VS 2008 TR1 support was announced about a month ago, I’m sure that the reaction varied from “Woo-hoo! I can’t wait!” to “Huh? What’s TR1? Do I care about this?” and all sorts of things in between.

This post is mostly aimed at that second category of folks – the ones who hadn’t heard about TR1, and who maybe haven’t found the time or inspiration to seek out what it’s all about. I’ll talk briefly here about just what TR1 is, and I’ll describe just a few of the TR1 features that I think are particularly nifty. This isn’t going to be an in-depth discussion or how-to manual, but it will hopefully inspire someone out there to take a closer look at what’s in TR1 and see if it can help you in your projects.

So what is TR1? Well, TR1 (“Technical Report 1”) is a set of proposed additions to the C++0x standard. Most of it will likely find its way into the new standard, but in the meantime it provides a useful stepping stone toward C++0x. TR1 is full of very useful new utilities such as new types of smart pointers (called “shared_ptr” and “weak_ptr”), new containers (tuples, unordered maps, unordered sets, and a neat STL-like array), reference wrappers, regular expression support, and function wrappers. You might look at that list and think that much of it sounds familiar. Smart pointers and function wrappers, for instance, already exist. This is true, but TR1’s versions try to be easier to use and more useful than the existing stuff… sort of like the next iteration based on a few years of experience finding out what works and what doesn’t work.

Alright, on to some specifics! First, I’d like to mention the new TR1 tuple and array classes. Then I’ll talk just a bit about shared_ptr. I’ll finish up with some information about regex, TR1’s regular expression utility. Again, people who are familiar with TR1 probably won’t get much out of this, but it will hopefully whet the appetite of those who are new to TR1.

Tuple is very much like the existing pair class, except that it can hold up to ten items instead of just two. Just like you can have pair<INT, char> p;, you can have something like tuple<INT, char, int, double, char*> t;. Handy, no?

TR1’s array class is very much like a fixed-length STL vector. Vector is a very useful class, and it is probably sufficient (even preferable) for most array-type needs. However, there are some situations where the developer is absolutely positive that the array needed will always be a particular size… no more, no less. In these cases, the variable-size feature of vector is not needed and just adds extra overhead. While you could just use a regular old C-style “square-bracket” array, the TR1 array class lets you use all of the STL-type iterators and algorithms. While it lacks some of the flexibility of a vector, it opens up more options than are available with a C-style array.

Shared_ptr is a very easy-to-use tool that greatly simplifies memory management. It all but makes new/delete combinations obsolete. Shared_ptr is a smart pointer class that is pretty easy to use. The syntax is fairly simple… shared_ptr<STRING> sp(new string(“foo”)); creates a shared_ptr called sp to a string containing “foo”. This shared_ptr will act almost just like any “normal” pointer, except that you don’t need to remember to delete it when you’re done. And unlike some older smart pointers, you don’t need to modify the target class (in this case, string) to include reference counting or anything like that… nearly any class you want will work with shared_ptr as-is. Speaking of reference counting, shared_ptr takes care of that (hence the “shared” in the name). If I were to make another shared_ptr that points to the same thing (like shared_ptr<STRING> sp2 = sp;), then shared_ptr’s reference counting is smart enough to only free up the memory when BOTH sp and sp2 are gone. Of course, this barely scratches the surface of what shared_ptr is all about, but it’s a start.

Regex is a class that lets you write complex regular expressions like those commonly used in Perl. While C++ has always had some amount of support for regular expressions, TR1’s regex utilities simplify things by building in the mechanics for parsing, matching, and capture groups. The regex class holds the actual regular expression, and algorithms such as regex_search(), regex_match(), and regex_replace() make it easy to apply that expression to a string. As you can probably deduce from the algorithm names, regex_search() tells the developer if the string contains any substrings that conform to the expression, regex_match() tells if the entire string conforms to the expression, and regex_replace() provides an easy way to change the string to fit a particular format. Regex can do quite a bit more than I’ve outlined here, but this should give you an idea of what regex is all about.

Well, that’s about all I wanted to say here. If any of this kindles some new interest in TR1 in any of the vcblog readers, great! Of course, any comments or questions that you might have will be appreciated.

Rob Huyett, VC Libraries Team

Published Wednesday, December 26, 2007 5:50 PM by vcblog

Comments

Wednesday, December 26, 2007 9:41 PM by Alan

# re: Just What Is This TR1 Thing?

"Most of it will likely find its way into the new standard, but in the meantime it provides a useful stepping stone toward C++0x."

Or in the "meantime", perhaps you could complete C++ 1988 (ISO/IEC 14882:1998) from almost a decade ago. Hint: export (it's one of the keywords).

Sure, I'm looking forward to future versions of the standard as well, but there are still past standards that are not fully implemented even years after their finalization.

Wednesday, December 26, 2007 10:17 PM by Stephen

# re: Just What Is This TR1 Thing?

I must agree with the above poster. Please fully implement the previous standards before working on future ones.

Last month it was clarified that Microsoft would be licensing the Dinkumware implementation of TR1. So, what exactly is the Microsoft VC Libraries team doing?

If I really needed TR1, I could always license it from Dinkumware myself. Or I even code it myself. What I absolutely can not do myself is fix / implement non-conformant language issues such as export, two-phase name lookup, or exception specifications. I growing proportion of various customer's code base can no longer be compiled with Microsoft's non-conformant compilers, often forcing me to use more conformant compilers such as those from Comeau and Borland. I really do want to use VC++, so please give me a better option.

Please fully implement existing standards before jumping on future ones.

Thursday, December 27, 2007 7:41 AM by Andre

# re: Just What Is This TR1 Thing?

I just wanted to add some notes regarding export:

IIRC it isn't a decade old and is an extension to C++98. There are only few compilers supporting this feature and AFAIK all of them are using the EDG front end. IIRC there has been only a beta of an experimental EDG front end based compiler from Borland, the current one doesn't support export - AFAIK.

It's been said that to implement export 2-3 men years of implementation is needed and I think it doesn't pay out, to invest that much time. I rather would see VC to support a C++ module concept as soon as possible, when it becomes part of the C++ standard.

IMHO export is rarely used, but this may be only my impression. I would agree to add export support to VC too, if export would be widely used by other compilers / source code.

(Please correct me if I've made some wrong statements - I'm not 100% sure about all of them)

Thursday, December 27, 2007 8:35 AM by f0dder

# re: Just What Is This TR1 Thing?

Forget about "export" - and do read http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf . Sure, please do fix other bugs etc. before adding new features, but TR1 is welcome.

And Borland compiler having better C++ conformance than Visual C++? Heh, which planet are *you* living on?

Thursday, December 27, 2007 9:21 AM by Akira

# re: Just What Is This TR1 Thing?

I look forward to TR1.

If C++0x was introduced, I am very glad.

Thursday, December 27, 2007 12:52 PM by C0

# re: Just What Is This TR1 Thing?

TR1 is nothing to make a fuss. Since boost has these libraries for years.

And yes, forget export, the better thing is setting out to implement new things introducing in C++0x, don't lag behind another compilers for years again.

More, overhaul the C compiler, it is such an antiques, till a C89 compiler.

Thursday, December 27, 2007 12:53 PM by C0

# re: Just What Is This TR1 Thing?

TR1 is nothing to make a fuss. Since boost has these libraries for years.

And yes, forget export, the better thing is setting out to implement new things introducing in C++0x, don't lag behind another compilers for years again.

More, overhaul the C compiler, it is such an antiques, still a C89 compiler.

Thursday, December 27, 2007 1:05 PM by rbiro

# re: Just What Is This TR1 Thing?

Yeah, boost has had this stuff for years.

And in the end, will Microsoft's new libraries have significantly better performance, conformance, usability than already found in the boost libraries?

Why not just sign an agreement with boost to officially incorporate them into DevStudio and get back to trying to make C++ a first class language within the DevStudio environment.  (WinForms must be the slowest GUI dialogs known to mankind!)

Thursday, December 27, 2007 3:31 PM by Vyacheslav Lanovets

# re: Just What Is This TR1 Thing?

In my opinion, export templates should not be used even if support were available. Export model doesn't add anything useful. Implementing this idiotic proposal voted for by accident will just slow down compilation speed.

boost tr1 implementation is rather poor according to www.dinkumware.com

boost is a sandbox for c++ extension, not a solid library.

Btw, boost::shared_ptr uses virtual functions inside (to implement custom deleters). This is not compatible with explicit DLL loading (and unloading). shared_ptr holds a pointer with vptr pointing to address space of the DLL where shared_ptr was created. So, shared_ptr::~shared_ptr() crashes with AV if the DLL was unloaded.

Unlike people in comp.lang.c++.moderated, I cannot imagine another way to implement custom deleters, so I won't be surprised that I won't be able to use tr1 shared_ptr

Thursday, December 27, 2007 7:15 PM by Norman Diamond

# re: Just What Is This TR1 Thing?

"IMHO export is rarely used, but this may be only my impression."

Sure it's rarely used.  If we look hard, we can find the reason.  Here's the biggest reason:

"There are only few compilers supporting this feature and AFAIK all of them are using the EDG front end."

And here's why people who have one of those compilers still can't use export:

'I growing proportion of various customer's code base can no longer be compiled with Microsoft's non-conformant compilers'

(Someone else explained that part of it better in an earlier thread.  When some of their customers use Microsoft compilers, they have to give their customers source code that can be compiled by Microsoft compilers.)

Friday, December 28, 2007 12:54 AM by Greg L.

# re: Just What Is This TR1 Thing?

"More, overhaul the C compiler, it is such an

antique, still a C89 compiler."

I second this, how about implementing C99.

Friday, December 28, 2007 5:54 AM by Andre

# re: Just What Is This TR1 Thing?

'I growing proportion of various customer's code base can no longer be compiled with Microsoft's non-conformant compilers'

Hm, which compiler supports export, so that Microsoft's compiler get's non-conformant with the source code written with this compiler ? When I take a look at boost, how many workarounds there are in this library to get it compiled with the various compilers, I doubt that there is really a 100% conforming compiler. Even if there is, then all compilers should support the standard at this level too, to get really portable code without having to implement compiler workarounds.

If export would be easy to implement or add real value, then I think it would have been adopted much faster. But it hasn't.

I'm still missing essential features in C++ more than export, e.g delegates. They are now in TR1, but unfortunately only as a library extension.

Friday, December 28, 2007 8:54 AM by ikk

# re: Just What Is This TR1 Thing?

I guess some details of the post disappeard due to  angle brackets in HTML... <>

Friday, December 28, 2007 11:48 AM by Greg

# boost TR1

It's a simple solution here, avoid the boost libraries and TR1 features until their equivalent have been in VC++ for 1+ years.  Try to keep your development tool set free of things not included in your core development tool (VC++).    MS has lacked VC++ progress since Visual Studio 6.0, not entirely due to MS, since the C++ standards committee did not progress the language much in the last 10 years.  NB: Attempting to port just about anything from the UNIX/Linux open source camp to VC++ will be difficult.  

Saturday, December 29, 2007 6:10 AM by Stephan T. Lavavej [MSFT]

# re: Just What Is This TR1 Thing?

I've addressed VC's non-implementation of export, two-phase name lookup, and exception specifications before.  However, I'd like to remind the minority of VC customers clamoring for these features that library developers/testers are not interchangeable with compiler front-end developers/testers.  If you think that these features are valuable, and aren't convinced by arguments otherwise, then you should make your concerns known - but to the relevant people. Commenting on posts by library testers like Rob (or library devs like myself) is highly unlikely to get you anywhere.

[Stephen]

> Last month it was clarified that Microsoft would be licensing the Dinkumware implementation of TR1.

Correct.

> So, what exactly is the Microsoft VC Libraries team doing?

I'll expand on this with a VCBlog post soon, but here's a summary:

1. We're integrating TR1 into VC9, so that TR1's headers live next to the STL's headers, and TR1's separately compiled components go into msvcp90[d].dll next to the STL's separately compiled components. You won't need to do anything special to access TR1 features, and you won't need to ship a whole new DLL with your programs. You'll simply need to update the version of the CRT that's distributed with your program, just like for a VC service pack (you can think of VC9 TR1 as SP0).

2. We're making TR1 play nice with /clr and /clr:pure.

3. We're ensuring that TR1 compiles warning-free at /W4, in all supported scenarios. This includes switches like /clr, /clr:pure, /Za, /Gz, and the like.

4. We're ensuring that TR1 is /analyze-clean.

5. We're identifying bugs in TR1 and working with Dinkumware to fix them. Dinkumware's code was very solid to begin with - but as ever, more eyes find more bugs. I've even found a couple of bugs in the TR1 spec itself.

6. We're striving for performance parity with Boost. In some areas, we won't get there for VC9 TR1 (hopefully, we should for VC10), but we've already made good progress.  Thanks to MS's performance testing (which Rob has been in charge of), we identified a performance problem in regex matching, which Dinkumware has sped up by 4-5x. And we've achieved performance parity for function.

7. We're identifying select C++0x features to backport into TR1 - for example, allocator support for shared_ptr and function. While not in TR1, this is important to many customers (including our own compiler).

8. Because TR1 lives alongside the STL, we can make them talk to each other in order to improve performance. For example, STL containers of TR1 types (e.g. vector<shared_ptr<T> >, vector<unordered_set<T> >) will avoid copying their elements, just as STL containers of STL containers in VC8 and VC9 avoid copying their elements.  Dinkumware's standalone TR1, and (to my knowledge) Boost don't implement this optimization, because it is nonportable.

9. We're implementing IDE debugger visualizers for TR1 types. I am secretly proud of how shared_ptr's visualizer switches between "1 strong ref" and "2 strong refs".

Adding TR1 isn't as simple as dropping new headers into VC\include and calling it a day.

> If I really needed TR1, I could always license it from Dinkumware myself.

That would cost you money and time.  The VC9 TR1 patch will be distributed free of charge, with no effort required on your part.

And you really need TR1.  Everyone does.

> Or I even code it myself.

Are you a world expert at library programming?  (If so, we're hiring!)  We've *got* some of the world experts at library programming, namely Dinkumware, working on TR1 - and it's not easy.  Take a look at TR1 mem_fn()/bind()/function's implementation when we release the TR1 beta, and then tell me that you could write that yourself.  :-)

I consider myself lucky to be able to *understand* what most of the TR1 implementation does - but I certainly don't fool myself into thinking that I could write it from scratch - well, not without dedicating several years to it and nothing else.

[Akira]

> I look forward to TR1.

> If C++0x was introduced, I am very glad.

VC9 TR1 isn't introducing any compiler changes.

[C0]

> TR1 is nothing to make a fuss. Since boost has these libraries for years.

If you are using Boost, that's great.  However, many companies are reluctant to use open-source code, even given Boost's extremely permissive license and excellent reputation.  Programmers at those companies will be really happy to have VC9 TR1.

[Vyacheslav Lanovets]

> boost is a sandbox for c++ extension, not a solid library.

I must disagree with this - I have found Boost to be extremely high quality, in terms of both correctness and performance.  This isn't too surprising, since the Boost developers are also world experts at library programming.

> Btw, boost::shared_ptr uses virtual functions inside (to implement custom deleters).

> This is not compatible with explicit DLL loading (and unloading).

I'm not sure what you're saying here.  If you create a shared_ptr with a custom deleter that lives inside a DLL that gets unloaded, of course the thing is going to blow up.  Nothing can save you from that.

Or are you saying something else?

[Andre]

> When I take a look at boost, how many workarounds there are

> in this library to get it compiled with the various compilers

Boost is special because some of its libraries still attempt to provide limited support for VC6 (the Infinite Enemy of modern C++ programming - GCC 2.x was also bad, but it apparently doesn't have eternal unlife).  This is presumably highly appreciated by those people who still use VC6 despite the fact that Microsoft no longer supports it, and presumably contributes to Boost's widespread use and reputation for working anywhere - but it certainly makes the implementation of those libraries more complex.

> I doubt that there is really a 100% conforming compiler.

There isn't - but Comeau comes close.  That's one of their main selling points, after all.

> I'm still missing essential features in C++ more than export, e.g delegates.

> They are now in TR1, but unfortunately only as a library extension.

Unlike other languages, C++ prefers to provide powerful support in the core language for library implementation, instead of providing such functionality directly in the core language. This contributes to C++'s extreme flexibility and generality.

What you call "delegates" in the managed world, I call "bound functors". TR1 binders are psychotically powerful. You just have to learn a different way of looking at things.

[Greg]

> It's a simple solution here, avoid the boost libraries and TR1

> features until their equivalent have been in VC++ for 1+ years.

I disagree - Boost is highly stable, and TR1 will be immediately usable - if not, Rob and I haven't done our jobs (and since there will be a TR1 beta, you won't either).

> Try to keep your development tool set free of things not included in your core development tool (VC++).

I'm trying to imagine how anyone could get anything done in C++ without third-party libraries, and failing.

> MS has lacked VC++ progress since Visual Studio 6.0

This is completely untrue.

VC's compiler and library conformance has increased MASSIVELY from the blighted VC6, through VC7/VC7.1, to VC8. (VC9 further improved conformance, although not nearly as much as the 6 => 7.1 and 7.1 => 8 leaps).

> Attempting to port just about anything from the UNIX/Linux open source camp to VC++ will be difficult.

Some of that, it is true, is due to VC bugs and quirks. A lot of it is due to Unixisms. Try compiling GNU tar for Windows and see how far you get.

(On the other hand, other programs are equally at home on Unixes and Windows - my usual favorite being bzip2. Portable programming pays!)

Stephan T. Lavavej

Visual C++ Libraries Developer, working on TR1

Saturday, December 29, 2007 2:53 PM by Andre

# re: Just What Is This TR1 Thing?

[Stephan - What you call "delegates" in the managed world, I call "bound functors". TR1 binders are psychotically powerful. You just have to learn a different way of looking at things]

I know. But don't you think the compiler couldn't do it more efficiently, regarding performance of the code and compilation ?

Doesn't mean that boost/TR1 implementation is bad, I only have the feeling that this is a basic feature, which should be implemented in the core language (too). The libraries are growing and growing, basically everything could be exported to a library, even a for loop. Yes, regarding compatibility libraries have true advantages, but TR1 needs highly compliant compilers anyway.

But anyways, very good work guys - keep it up. And (have) a good and happy new year.

[Just in case it happened: sorry for double posting]

Saturday, December 29, 2007 3:54 PM by Stephan T. Lavavej [MSFT]

# re: Just What Is This TR1 Thing?

[Andre]

> I know. But don't you think the compiler couldn't do it more efficiently

I do not think that the compiler could do it more efficiently. There is nothing magical about binding arguments to a functor, and TR1 should generate code which is as efficient as hand-written C++.

It so happens that the STL and TR1 are very high performance, although VC9's optimizer isn't perfect (data members frustrate the inliner).

> I only have the feeling that this is a basic

> feature, which should be implemented in the core

> language (too).

C++'s core language is already packed with features, and you want to add *more*?

There are very important things that need to be added to the core language which will improve expressiveness (variadic templates) and performance (rvalue references). Bound functors can already be implemented well in a library. C++ doesn't need first-class functions like Scheme because classes can imitate functions - in fact, C++ encapsulates modifiable state better. And C++ doesn't need delegates like managed languages because it has more powerful library support (templates, templates, and more templates).

Now, it turns out that true lambda functions can't be implemented well in a library (Boost.Lambda was a good try, demonstrating the difficulty), so I'm eager to see them be added to C++0x. Merely binding arguments to existing functions is a simpler case, though.

> The libraries are growing and growing

As they should!

Actually, C++'s standard library is small compared to those of other languages (because the C++ standard library has a different focus). It has room to grow, as TR1 demonstrates.

> basically everything could be exported to a

> library, even a for loop.

Like std::for_each().

There's a reason that I'm picky about terminology - "delegate" sounds special and fundamental, while "bound functor" sounds like a modification of a special, fundamental thing (and indeed, functors are powered by core language features - operator overloading, templates, and the like).

There *are* compromises in TR1 that really want to be part of the core language, but can't in a library-only addition. result_of is the best example.

Stephan T. Lavavej

Visual C++ Libraries Developer

Sunday, December 30, 2007 4:53 AM by vcblog

# re: Just What Is This TR1 Thing?

[Stephen]

"If you think that these features are valuable, and aren't convinced by arguments otherwise, then you should make your concerns known - but to the relevant people. Commenting on posts by library testers like Rob (or library devs like myself) is highly unlikely to get you anywhere."

Actually the Visual C++ leadership team reads all the comments on all the vcblog entries. We take these comments into account as one of the factors when we make decisions on the evolution of the product.

Ronald Laeremans, Product Unit Manager

Sunday, December 30, 2007 7:19 AM by Sys64738

# re: Just What Is This TR1 Thing?

[Stephan]

"Boost is special because some of its libraries still attempt to provide limited support for VC6 (the Infinite Enemy of modern C++ programming"

IMHO, Microsoft did a great job in improving the C++ compiler since VC6 age. I don't like very much the VC6 C++ compiler, but I do love the VC6 IDE!

I think that one of the reasons of VC6 success is that you in Microsoft developed a *great* IDE for VC6: the IDE is snappy and robust (it was so also in the old days of 64 MB of RAM and Pentium 150 MHz, it's not that VC6 became fast only with big powerful hardware of these days).

The edit-and-continue does work.

The help system integrated in VC6 does work: you find what you are looking for (it's not like the help system of VC7 or lather... that I prefer using Google to find things on MSDN :(

VC6 + Visual Assist X + WndTabs is a great development experience, IMHO.

There was a very interesting thread on Mr. Somasegar's blog about VC6 and VC++ improvements, and I believe that you already read that:

http://blogs.msdn.com/somasegar/archive/2007/08/08/visual-c-futures.aspx

So, what I just ask to VC++ Team is to continue the *great* work they have alrady done with the C++ compiler and libraries improvments, but also work like this with the IDE.

Best wishes for the new year!

Giovanni

Sunday, December 30, 2007 8:04 AM by Andre

# re: Just What Is This TR1 Thing?

[Stephan - I do not think that the compiler could do it more efficiently]

Ok. I'll take your words ;-).

Currently a simple member function call with 1 parameter in boost needs 30 assembly instructions with 3 jumps.

The same call in C++/CLI needs 5 assembly instructions and 1 single jump.

(And it's managed code)

[Stephan - it has more powerful library support (templates, templates, and more templates)]

Once I've been in love with them and I've been a hardcore C++ developer using them even for meta template programming. But since I've seen that I can be (much much) more powerful and have a higher abstraction level with code generation on a higher level I don't find them that >worthwhile< anymore.

Andre

Sunday, December 30, 2007 11:50 AM by Stephan T. Lavavej [MSFT]

# re: Just What Is This TR1 Thing?

[Ronald Laeremans]

> Actually the Visual C++ leadership team reads all

> the comments on all the vcblog entries.

Aha!  I didn't realize you read everything.  That is cool.

(For those following along at home, Ronald is my great-grandboss, the manager for all of VC.  Our org actually has a new shiny name now, but that's basically what it is.)

[Sys64738]

> IMHO, Microsoft did a great job in improving the

> C++ compiler since VC6 age. I don't like very much

> the VC6 C++ compiler, but I do love the VC6 IDE!

You and everyone else on the planet, as far as I can tell! :-)

The IDE team has definitely gotten your feedback, and they're working hard to make VC10's IDE better. We recently got T-shirts with the slogan "10 is the new 6", heh.

[Andre]

> Currently a simple member function call with 1 parameter

> in boost needs 30 assembly instructions with 3 jumps.

> The same call in C++/CLI needs 5 assembly

> instructions and 1 single jump.

Hm, that's not good.  What exactly are you doing?  Are you simply binding a member function to an object and invoking it later (this would look like bind(&foo::bar, obj, arg)), or are you introducing a boost::function into the mix?

Send me a self-contained repro at stl@microsoft.com, and I'll see how VC9 TR1 handles it. We might be able to do something on the libraries side better, or at least I'll be able to file an optimizer bug. Fundamentally, native code should never be less efficient than managed code.

I do know that the optimizer can't see through data members (e.g. the one that powers mem_fn()), and I've already got a bug open about that. This might be the same thing, or something different - either way, it'll be good to get a repro.

Stephan T. Lavavej

Visual C++ Libraries Developer

Sunday, December 30, 2007 1:43 PM by Sys64738

# re: Just What Is This TR1 Thing?

[Stephan]

"The IDE team has definitely gotten your feedback, and they're working hard to make VC10's IDE better. We recently got T-shirts with the slogan "10 is the new 6", heh."

That is *great* news! :)

And I do like that slogan!

Thanks,

G

Sunday, December 30, 2007 4:03 PM by Andre

# re: Just What Is This TR1 Thing?

[Stephan - Hm, that's not good.  What exactly are you doing?]

Sorry, my fault. I wasn't aware that boost::function has that much more overhead as direct binding. Forget one of the main performance rules, first look at the implementation ;-).

Without boost::function everything is as it should be:

The C++ optimizer even removed the call. Quite hard to write short test/reproduction code, if most of the code is removed ;-).

Thank you for the hint and sorry for the misinterpretation.

Can't (now) wait to get hands on TR1 and are much excited about the next "10 is the new 6" release *g*.

Sunday, December 30, 2007 5:39 PM by Andre

# re: Just What Is This TR1 Thing?

[Stephan - Hm, that's not good.  What exactly

[Andre - Sorry, my fault]

Sigh, forget my last post. Got myself confused and no bind was involved. I need a function object, to write a generic callback function, correct me if I'm wrong.

Sample:

class test { public: void cb(int i) {} };

test t;

boost::function<void (int)> foo = boost::bind<void>(&test::cb, t, _1);

foo(100);

This C++ code needs the 30 assembly instructions. While the comparable C++/CLI code:

ref class Test { public: void cb(int i) {} };

delegate void CB(int i);

Test^ test = gcnew Test();

CB^ foo = gcnew CB(test, &Test::cb);

foo(100);

Needs "only" 5 for the function call.

Did I got something (again) wrong, or is the managed version really more efficient ?

Monday, December 31, 2007 1:38 PM by Greg

# re: Just What Is This TR1 Thing?

Stephen and the VC++ team,

I advocated keeping your project free, when possible, of dependencies on external libraries to reduce the project's cost and risk over its life cycle.  This is shooting for a 5+ year life cycle between major upgrades or rewrites.  

This is much more true for non-GUI code than it is for GUI code.

The compiler and libraries have made significant security improvements in the CRT since 6.0.  Much more useful changes include better compiler diagnostics and run time security checks.

I appreciate MS's effort in VC++ since 6.0.

New features/libraries are not put into production use for about the first year for the same reason why our production machines do not get an OS upgrade until at least service pack 1 is released.

This works out OK because our release cycle is about 6-8 months so we can develop using new features a few months before production use.

Our environment is such that new tools, libraries, build tools, plug-ins, etc. need to get approval from our technical advisory team before being used.

This is the result of the ease of which each developer brought in his favorite set of open source/low cost tools for his application during 1996-2005.  This turned over with each developer and about every two years.  This proliferation and staff turnover led to us having tens of tools that products relied on but no-one had seriously used, were unsupported or nearly dead.  FWIW, we have C++, C#, VB6, VB.NET, .NET 1.x, 2.x, classic ASP, ASP.NET, C as languages for production systems.

Monday, December 31, 2007 2:00 PM by Stephan T. Lavavej [MSFT]

# tr1::function's purpose

[Andre]

> Sorry, my fault. I wasn't aware that boost::function

> has that much more overhead as direct binding.

This is a fundamental consequence of how boost/tr1::function works. It "forgets type" (wrapping a functor of arbitrary type with a given signature, inside a type that depends only on the signature), as if by using virtual functions, but virtual functions are incompatible with inlining. Even when virtual functions themselves aren't used because of other overheads, you're still going to incur some penalty.

> boost::function<void (int)> foo = boost::bind<void>(&test::cb, t, _1);

> Did I got something (again) wrong

Yes, you're unnecessarily using a boost::function.

(Note that you can say boost::bind(stuff) instead of boost::bind<void>(stuff) here, although it doesn't make a difference in terms of the generated code. I suggest avoiding explicit return types unless they are necessary.)

To clarify:

boost/tr1::function's purpose is to provide "insulation" by forgetting type. Ordinarily, the only way to make an algorithm accept functors of arbitrary type is to template the algorithm on the functors, but that can lead to lots of template instantations. Some things make it even more difficult - consider an object that wants to be constructed from a functor of arbitrary type. Now you'd need to template the object on that functor type, and anything taking that object needs to be a template too (if full generality is desired), etc.  (Think of boost::thread here.) Also, containers have to be homogeneous, so you can't fill a container with functors of different types.

Instead, you can insulate these functor-taking algorithms and functor-containing objects/containers from the exact types of the functors by introducing a boost/tr1::function.  Now, your algorithms and containing objects can be non-templates (or, at least, not templated on that functor type), since the type variability is handled by the boost/tr1::function.  This introduces a small overhead (after all, you're forgetting type - "dynamic" languages do this all the time so it's easy to forget about, but C++ is capable of both compile-time and run-time polymorphism, and only the latter forgets type and introduces overheads), but it can be very useful and lead to efficiency gains elsewhere (e.g. because now you have only one implementation of the algorithm, which fits into instruction cache, etc.).

boost/tr1::function has a second purpose, but this one is not fundamental. It's a convenient way to store a functor whose type is inconvenient to say. In C++03, the return types of mem_fn() and especially bind() are difficult to say. You could dig into the implementation, but you'd end up with nonportable types (boost::detail, or Dinkumware's _Bind, etc.). You could use tr1::result_of, but it would be kind of complicated (bind() is a template function, so you'd have to give it explicit template arguments). It's a lot easier to just store the return value of bind() in a boost/tr1::function.  However, that introduces overheads.

C++0x auto/decltype is the true solution for dealing with types that are inconvenient to say. Otherwise, you have a couple of choices:

1. Use result_of. However, if you're using any placeholders (i.e. you're doing incomplete binding), I don't think this will work. As far as I can tell, there's no way to say the type of _1, _2, etc. portably (without C++0x decltype). TR1 doesn't provide a placeholder_type<N> (in VC9 TR1, the types are _Ph<N>, but this is nonportable). This is a very minor oversight on the part of TR1 (and since C++0x has auto/decltype, there's no point in filing a Library Issue).

2. Hand the result of bind() to a template function.  This is easy:

template <typename F> void foo(F f) {

   // do stuff with f

}

foo(bind(stuff));

foo() will know the exact type of F, whatever it is, so you'll make the inliner happy by not introducing any yucky virtuals. You may have to take the functor by reference instead of by value in order to avoid copying (C++03 does love copying stuff).

TR1 is, of course, an intermediate step in the evolution of C++ - it makes a lot of things easier to write, but some things require the full power of C++0x. Until then, awkward workarounds will occasionally be necessary.

Stephan T. Lavavej

Visual C++ Libraries Developer

Tuesday, January 01, 2008 4:00 AM by Andre

# re: Just What Is This TR1 Thing?

[Stephan]

Thank you for the clarification and a happy new year.

My intention was it to decouple the sources and not using templates, besides for boost::function and to bind the member function.

As you already wrote, templates have a high coupling factor and they restrict other goodies to work, e.g. Intellisense.

Handing the bind result to a template function helps me not that much IMHO, because I cannot store the pointer and since I don't want to use the additional lambda goodies in this case I could also use a template function without bind:

template <typename F, typename T>

void C(F f, T& p)

{

  (p.*f)(100);

}

Auto won't perhaps help too, because it can't be used AFAIK as a class member, since it must derive the type from a return type of a function.

So, I think we agree here, for the "simple task" of storing a member function, not bound to a special class type, in an ordinary non templated class I have to use boost::function ?

Currently simply speaking the managed implementation is 6 times more efficient regarding code complexity on the assembly level as the native one.

We will see if variadic templates and other C++0x features will help to make the code more efficient.

I'm still not convinced that a core implementation of a delegate type *and* the library extension in combination couldn't be more efficient. In the managed version it obviously is. I'm only nitpicking on this, because C++ always claims to be (most) efficient in code generation.

----------------------------------------

By the way: I had a look at the preprocessor output of my sample code:

Managed: 46      lines

Native:  121000  lines

And the native output has many, many empty lines, just wondering (in case that's not only for some kind of optimization and other devs responsible for the preprocessor read this post).

Andre

Tuesday, January 01, 2008 8:03 AM by Stephan T. Lavavej [MSFT]

# re: Just What Is This TR1 Thing?

[Andre]

> As you already wrote, templates have a high coupling factor

What?

Templates *decouple* code by generalizing over types.

> and they restrict other goodies to work, e.g. Intellisense.

That's Intellisense's deficiency.

> I could also use a template function without bind

This is similar to a handwritten binder, which I suggest as another workaround.

The problem with handwritten binders is that they involve more typing (they aren't particularly brittle, just tedious). The problem with bind() in C++03 is that it's difficult to say its return type. (The absence of perfect forwarding is another problem, but not relevant here.) If you can't use bind(), fall back to handwritten binders.

> Auto won't perhaps help too

decltype will.

> So, I think we agree here, for the "simple task" of storing

> a member function, not bound to a special class type, in an

> ordinary non templated class I have to use boost::function ?

No.

> Currently simply speaking the managed implementation is 6

> times more efficient regarding code complexity on the

> assembly level as the native one.

That's because you're not performing a proper comparison.

> C++ always claims to be (most) efficient in code generation.

Only when you write efficient code to begin with.

> I had a look at the preprocessor output of my sample code

Templates go in headers, and the Standard Library has a lot of templates. Also, for ease of implementation, VC's Standard Library headers include each other more often than if they tried to avoid doing so.

(I thought about it some more, and I don't think result_of can be used to work around the absence of auto/decltype here.)

Stephan T. Lavavej

Visual C++ Libraries Developer

Tuesday, January 01, 2008 8:22 AM by peter

# re: Just What Is This TR1 Thing?

I wish compiler diagnostic and debugger support for tr1 will be also on high level. I don't want to land in the middle of some macro expansion during debugging some tr1:function/bind code.

Does the tr1 in vc9 use the same preprocessor tricks as boost does?

Tuesday, January 01, 2008 10:19 AM by Andre

# re: Just What Is This TR1 Thing?

[Stephan]

[What? Templates *decouple* code by generalizing over types]

Perhaps I've not expressed me correctly. Coupling factor - meaning if I want to store a templated type, which has a template parameter, in a class as member, I have to make the class containing this type templated too.

Since there's no real separation between declaration and implementation for templated classes I have to include the implementation too.  

Ever tried to separate template based code via pimpl or ship libraries of template classes with code and implementation separated, where the implementation code is compiled to a library / dll ?

In the sense of a template type can be everything you are right.

So let me rewrite my post:

Templated classes tend to make classes containing this classes templated too, if the template type is or cannot be specified directly.

[That's Intellisense's deficiency]

Don't think so. For Intellisense to function constraints are needed. Otherwise how should Intellisense know of which type the template paramter is, when I write the implementation code of the template ? It could be any type.

[decltype will]

Not with an ordinary non templated class. Or can you give me an illustrative example - for the code below.

[No]

So please give me an example - rewrite the following code:

class CallbackHolder

{

  boost::function<void(int)> myCallback;

};

By replacing boost::function with auto or decltype and without converting the class CallbackHolder to a templated one.

With a delegate type directly supported by the C++ core I could write:

class CallbackHolder

{

  delegate<void(int> myCallback;

};

[That's because you're not performing a proper comparison]

What would be a proper comparison ? I want to use the style boost::function allows me to use. I want to use it in a simple non templated class and perhaps export this class and ship the implementation code compiled to a dll.

[Only when you write efficient code to begin with]

And if C++ allows me to do ;-).

[Templates go in headers, and the Standard Library has a lot of templates]

Ups. Templates should decouple better ;-)

[I thought about it some more, and I don't think result_of can be used to work around the absence of

auto/decltype here]

But you could give me / us a sample for my class CallbackHolder anyways, how you would write it by using auto/decltype

*without* using templates.

Andre

Senior C++ software engineer

Tuesday, January 01, 2008 3:03 PM by Stephan T. Lavavej [MSFT]

# re: Just What Is This TR1 Thing?

[peter]

> I wish compiler diagnostic and debugger support for tr1 will be also on high level.

Diagnostics: The compiler errors you'll get from misusing TR1 will be more or less equivalent to those you'll get from misusing Boost. (In the cases where compiler errors are triggered at the TR1 interface, e.g. trying to construct a shared_ptr implicitly from a raw pointer, you'll get identical diagnostics modulo namespaces. Compiler errors that are triggered within the implementation may vary. Without concepts, there is little that can be done at the library level to make template error messages less hideous-looking.)

Debugger: VC9 TR1 will come with extensive IDE debugger visualizers for almost all TR1 types, including some new visualizers for STL types that should be helpful for TR1 users (e.g. plus<T>() will be visualized as "plus", to make bound functors easier to look at).

> I don't want to land in the middle of some macro expansion during debugging some tr1:function/bind code.

> Does the tr1 in vc9 use the same preprocessor tricks as boost does?

Without looking at the Boost implementation, I can't perform a direct comparison (you can, when the VC9 TR1 beta is released very soon). I would characterize VC9 TR1 as using "some" but not "a whole lot" of macros. Most of TR1's implementation is similar to the STL macro-wise. The exception to this is those parts of TR1 that have to simulate variadic templates; this requires lots of preprocessor machinery (the only thing worse than lots of macros here would be no macros). In particular, tuple, bind, and the other functional stuff are powered by non-idempotent headers and the like.

[Andre]

> Coupling factor - meaning if I want to store a templated type,

> which has a template parameter, in a class as member, I have

> to make the class containing this type templated too.

Only if you want to propagate the generality to the containing class. stack<T> contains a deque<T> (by default), but you can also have an Image containing a vector<unsigned char>.

This particular case is special because TR1 leaves some types unspecified. Usually, you can look at a function (even a function template) and easily figure out what it's going to return.

> Don't think so. For Intellisense to function constraints are needed.

Okay - let's call it a consequence of how Intellisense and templates interact (in the absence of concepts).

> Or can you give me an illustrative example - for the code below.

decltype allows you to say "give me the type of this expression", where the expression can be something like a + b, or a function call. This is something that C++03 can't do, and it's exactly what you're wanting to do here.

I don't have a decltype-supporting compiler, but you can read the decltype papers for more details.

auto allows you to say something similar, "give this thing the same type as its initializer".

> By replacing boost::function with auto or decltype and without converting the class CallbackHolder to a templated one.

That's asking for type forgetting without any overhead, which can't be done.  Functors in C++ can contain arbitrary state. Even pointers to member functions have to be invoked differently depending on whether the inheritance is virtual or not, etc.

According to my extremely limited understanding of managed delegates, they work by restricting themselves to binding only "pointers to member functions" (even if that's not what they call them) to "pointers to objects" (also even if that's not what they call them), and they've restricted inheritance so that you can call everything in a uniform way. That way, branches can be avoided. I might be completely wrong about that.

C++ works in a different way - it allows great diversity in functors (pointers to member functions with no inheritance, single inheritance, virtual inheritance, or pointers to data members, or pointers to functions, or full-fledged function objects, stateless or stateful), and relys on inlining being done through templates to produce efficiency equivalent to handwritten C. If you demand that something be a non-template, yet cope with so many different functors, you're going to introduce overheads.

> What would be a proper comparison ? I want to use the style boost::function allows me to use.

boost::function is extremely simple to use, and permits separate compilation in cases where it was previously difficult or impossible. It does, however, involve small overheads.  Here, you are looking at the overheads to the exclusion of everything else, which is why it appears to be a big deal.

By "handwritten binder", I mean a functor that is templated on class type, parameter types, and return type, which stores a pointer to member function, an object, and an argument (you can make the object free, or the argument free, or neither for full binding). You can't use this for type forgetting - the bound functor type depends on the class type - but it also doesn't propagate templateness (something storing a bound functor need not be a template).

Stephan T. Lavavej

Visual C++ Libraries Developer

Tuesday, January 01, 2008 4:44 PM by Andre

# re: Just What Is This TR1 Thing?

[(in the absence of concepts)]

O.k. C++ names them concepts. Sorry get always confused with C++/CLI, C# and C++.

[decltype allows you to say ...]

Well I want to express, store a member function pointer at this location to a function with the signature X.

[binding only "pointers to member functions"]

I've not discovered any restrictions of delegates yet. But anyways you are correct, managed code doesn't support multiple inheritance of classes. Only of abstract interfaces.

So they don't have the problems, introduced by C++ supporting multiple inheritance.

There are other proprietary delegate extensions of other compiler vendors, which also restrict multiple inheritance, to support delegates. VC also has extensions, though IMHO not directly comparable.

[...you're going to introduce overheads.]

Yes, at least the delegate would have to be large enough to store the largest member function pointer, which is larger as the most simple member function pointer: this + codeptr.

[of everything else, which is why it appears to be a big deal]

Yes, agreed, it's not that simple for a (C++) library - it would be rather hard to implement this for all possible cases.

And yet there are some implementations, which come quite near to an ideal C++ delegate implementation, which supports the syntax of boost::function, avoiding it's runtime overhead.

But they have to use dirty hacks, where a little compiler (C++ core) support could help. E.g. Don C. has written such an implementation and article on the codeproject web site - fast delegate.

Generally std::function will be sufficient for me most times. But, this is where the discussion started, I think with a little standard/compiler help it could be implemented more efficient.

Andre

Thursday, January 03, 2008 5:56 AM by Stephen (not MSFT)

# re: Just What Is This TR1 Thing?

Stephan T. Lavavej [MSFT],

Sorry for the late response.

I was on vacation for new years.

>> So, what exactly is the Microsoft VC

>> Libraries team doing?

> I'll expand on this with a VCBlog post soon,

> but here's a summary:

> 1. We're integrating TR1 into VC9, so that TR1's headers live next to the STL's headers, and TR1's separately compiled components go into msvcp90[d].dll next to the STL's separately compiled components. You won't need to do anything special to access TR1 features, and you won't need to ship a whole new DLL with your programs. You'll simply need to update the version of the CRT that's distributed with your program, just like for a VC service pack (you can think of VC9 TR1 as SP0).

As a developer, managing headers and libraries is one of the basic skills needed in our profession. It is not a difficult task. Hopefully you can accept that I can just as easily do that myself. Boost is just one major example.

> 2. We're making TR1 play nice with /clr and /clr:pure.

/clr is not C++ (ISO/IEC 14882:2003). Nor is it part of the forthcoming C++0x, which TR1 is being targeted for.

While I have given try implementations of C++/CLR a chance, customers continually ask me to do managed development in C#, and mixed interop is essentially non-existent (usually for reasons of portability).

> 3. We're ensuring that TR1 compiles warning-free at /W4, in all supported scenarios. This includes switches like /clr, /clr:pure, /Za, /Gz, and the like.

At least in regard to standard code (see above), that sounds like Dinkumware's job. I seriously hope that warnings are not merely being pragma-ed off.

4. We're ensuring that TR1 is /analyze-clean.

Sounds like Dinkumware's job.

> 5. We're identifying bugs in TR1 and working with Dinkumware to fix them. Dinkumware's code was very solid to begin with - but as ever, more eyes find more bugs. I've even found a couple of bugs in the TR1 spec itself.

Good, but again that sounds like Dinkumware's job.

> 7. We're identifying select C++0x features to backport into TR1 - for example, allocator support for shared_ptr and function. While not in TR1, this is important to many customers (including our own compiler).

As C++0x does not exist yet, I hope that you are limiting yourself to the currently accepted subset. However, key features such as export have existed in the standard for almost a decade now. Please implement the existing standards first.

>> If I really needed TR1, I could always

>> license it from Dinkumware myself.

> That would cost you money and time.

Yes, that is how business works.

However, while I *can* license Dinkumware's implementation as needed, no matter how many years I plead and beg for standard compliance, I can *not* get Microsoft to implement the existing C++ standard. The biggest issues for me are 1) export, 2) two-phase name lookup, and 3) exception specifications.

>> Or I even code it myself.

> Are you a world expert at library

> programming?

You make it sound so difficult to build C++ libraries... I am sufficiently confident in my skills to implement required types as necessary for jobs.

I have used VC++ for many, many years now. However, as more and more customers are beginning to use standard C++ features such as export (etc), increasingly I can no longer compiler existing code-bases with non-conformant Microsoft compilers. Perhaps we do not need some of these features, but people *are* using them (for whatever reasons), and they are part of the existing standard. Often when I try to get around this with #defines I am opposed by senior developers who point me to the ISO/IEC 14882:2003 standard and tell me to replace the compiler if it is incompatible with the standard.

I really, really want to continue using VC++. I beg and plead with you for years, but while you do not deny that it is part of the existing standard, you ignore it and implement future standards. You make it so incredibly difficult to support your products.

Thursday, January 03, 2008 10:44 AM by ikk

# re: Just What Is This TR1 Thing?

"""The biggest issues for me are 1) export, 2) two-phase name lookup, and 3) exception specifications."""

This is starting to sound like kid's quarrel[1], but i would change the order to: 1) two-phase name lookup, 2) exception specifications and 3) export. With export, one can always say: "so don't use it". Not so with two-phase name lookup (unless you avoid templates completely, it's hard to guess when it will happen, or when you forgot the keyword "typname", specially if you never use another compiler).

"""

>> If I really needed TR1, I could always

>> license it from Dinkumware myself.

> That would cost you money and time.

Yes, that is how business works.

"""

I appreciate the work that's being done for TR1, because it's the kind of library that should be included with compilers. If i were going to buy a library separately, i would forget TR1 and go directly to Qt, for example.

[1] Sorry, English is not my native language, but i think you'll get the point

Thursday, January 03, 2008 1:24 PM by Stephan T. Lavavej [MSFT]

# re: Just What Is This TR1 Thing?

[Stephen]

>> 1. We're integrating TR1 into VC9

> Hopefully you can accept that I can just as easily do that myself.

You misunderstand - adding TR1 to the Visual Studio product, right next to the Standard Library, involves more work than a standalone library (like Boost). There's the Visual Studio build system to contend with (it took us a little while to get the TR1 separately compiled components exported from msvcp90[d].dll), and then the setup system (getting the new headers and sources picked up by the installer), etc. Unglamorous work, but work nevertheless.

>> 2. We're making TR1 play nice with /clr and /clr:pure.

> /clr is not C++ (ISO/IEC 14882:2003). Nor is it part of the forthcoming C++0x, which TR1 is being targeted for.

Certainly. I am personally uninterested in /clr[:pure]; however, it is a VC feature, so TR1 must support it. And this took an unbelievable amount of work.

>> 3. We're ensuring that TR1 compiles warning-free at /W4, in all supported scenarios. This includes switches like /clr, /clr:pure, /Za, /Gz, and the like.

>> 4. We're ensuring that TR1 is /analyze-clean.

> At least in regard to standard code (see above), that sounds like Dinkumware's job.

TR1 arrived mostly /W4-clean. However, Dinkumware hadn't yet thrown (to my knowledge) exotic options like /Za and especially /clr[:pure] at TR1. Our test matrix identified these warnings so Dinkumware could fix them. Similarly, /analyze exposed several warnings.

> I seriously hope that warnings are not merely being pragma-ed off.

Generally, no - we preferred true fixes to workarounds to pragmas, in that order. And as usual, we disable warnings only in the TR1 headers, not in user code.

>> 5. We're identifying bugs in TR1 and working with Dinkumware to fix them.

> Good, but again that sounds like Dinkumware's job.

As I said, more eyes find more bugs. It's our job to find bugs, and Dinkumware's job to fix them. (Independently, they also find and fix bugs.)

>> 7. We're identifying select C++0x features to backport into TR1

> As C++0x does not exist yet, I hope that you are limiting yourself to the currently accepted subset.

Anything that has been voted into the Working Paper is almost certainly going to make it into the C++0x standard.

> You make it sound so difficult to build C++ libraries... I am sufficiently

> confident in my skills to implement required types as necessary for jobs.

The more generic the library, the more skill it takes to implement. Application and OS developers aren't library developers, and they don't have the same skills. TR1 is an extremely generic library, and extremely difficult to implement.

(Within MS, I've seen a half-dozen smart pointer implementations, all deficient in one way or another. My hope is that shared_ptr will sweep them all away.)

[ikk]

> Not so with two-phase name lookup

It's actually "pretty hard" to trigger two-phase name lookup (such that it'll make a difference), if you follow a certain style of code organization. Yes, that's rather vague.

> or when you forgot the keyword "typname"

Requiring "typename" is completely unrelated to two-phase name lookup, and VC implements the "typename" rules pretty well. I'm sure that there are bugs that aren't coming to my mind right now, but VC definitely enforces this rule in most situations where it should be enforced.

Perhaps you're thinking of unqualified name lookup reaching into dependent base classes (it shouldn't, says the Standard) - this rule is related to two-phase name lookup, although not actually part of it. VC actually enforces this rule under /Za.

Stephan T. Lavavej

Visual C++ Libraries Developer

Thursday, January 03, 2008 8:25 PM by Stephen

# re: Just What Is This TR1 Thing?

ikk,

> With export, one can always say: "so don't use it".

Only if one owns all of the code themselves. However, when I work with various customer codebases, increasingly they are already--for whatever reasons--using export. Needless to say, this will not compile with any existing VC++ compiler. When I try to either 1) rewrite it without using export or 2) make a special VC++ version with #ifdef, I am often opposed by other developers who point me to the ISO/IEC 14882:2003 standard and tell me to replace the compiler if it is incompatible with the standard rather than replace good code. And that is precisely what I have had to do. More and more I am being forced to use Comeau. Comeau is a great compiler, but I would like to continue using VC++. However, it is less and less possible.

"so don't use it" is often not an option.

Friday, January 04, 2008 12:13 PM by ikk

# re: Just What Is This TR1 Thing?

'''Requiring "typename" is completely unrelated to two-phase name lookup'''

'''Perhaps you're thinking of unqualified name lookup reaching into dependent base classes'''

(snip)

'''VC actually enforces this rule under /Za'''

Sorry, i wasn't sure and mixed a few concepts (i wasn't very clear either, mainly because i didn't feel the need to be very specific).

But i did think about "unqualified name lookup reaching into dependent base classes" too.

Last time i tried /Za (a long time ago, under VC++.NET 2002), i triggered a documented bug and never tried /Za again.

If /Za is working OK (and if standard headers compile cleanly under /Za), i will give it a try again. Thanks for the info. :-)

Friday, January 04, 2008 1:59 PM by Stephan T. Lavavej [MSFT]

# re: Just What Is This TR1 Thing?

[ikk]

> If /Za is working OK (and if standard headers compile

> cleanly under /Za), i will give it a try again.

The Standard and TR1 headers should compile cleanly under /Za. If they don't, that's a bug. (Warnings and compiler errors occasionally creep in - the unqualified-name-lookup-reaching-into-dependent-base-classes thing is really easy to forget - but we now have pretty good test coverage.)

However, /Za is an obscure option. It doesn't get a whole lot of testing (on both the compiler and library sides), doesn't do a whole lot of stuff, and isn't really being actively developed. The front-end devs I know recommend against it, as it could do more harm than good.

For portable code, I simply suggest using multiple compilers regularly. Then you'll get the union of their conformance checks (of course, you'll also have to deal with the union of their bugs).

Stephan T. Lavavej

Visual C++ Libraries Developer

Saturday, January 05, 2008 7:57 AM by Daniel

# re: Just What Is This TR1 Thing?

TR1 is a set of additions to the standard library of C++9x (not 0x as the article states) and should become part of C++0x (as the article states correctly).

TR1 is important as it brings new library features to C++ that don't require a language (and therefor a compiler) change. Thanks and kudos to Microsoft for being quick to bring TR1 to Visual C++.

However, I should like to add my voice to those clamouring for support for export. The fact that export offers an opportunity to increase separation between the definition and the declaration of code templates means that it is a valuable tool in enabling separation between compilation units and so in managing build times. Even if all the other benefits offered by export turn out to be illusory this one is worth every bit of the development effort that its implementation might require (a couple of lousy man-years is nothing to argue about, really). Yes, Daveed Vandevoorde's proposal for modules offers more, but we will have some years to wait before that is standardized, let alone available in the compilers on our desktop.

Exception specifications are another matter. The C++ syntax is such that checking of exception specifications at compile time is not possible (a pointer-to-function doesn't have an exception specification, for example, so a call through a pointer cannot be checked), and automatically checking at runtime violates the C++ convention that you should not pay for what you do not use. Exception specifications are essentially useless in C++ and should be removed from the standard.

Tuesday, January 08, 2008 5:20 AM by Pavel Minaev

# re: Just What Is This TR1 Thing?

> I'm still not convinced that a core implementation of a delegate type *and* the library extension in combination couldn't be more efficient.

"Delegates" (lambdas) will likely be in C++09, and from the looks of them they are going to be just as efficient as .NET delegates.

Tuesday, January 08, 2008 9:20 AM by Bronek Kozicki

# re: Just What Is This TR1 Thing?

Stephen and others - we really do not need "export". Please reade complete N1426 to understand why. If I had a choice, I would vote to remove it entirely from the standard. Not only does not buy us anything, but also comes with difficult to understand problems related to names visibility and makes implementation of other C++ features (present or future) needlessly expensive. Yes, it's good to have another tool to improve code separation/decoupling, IF that tool works.

Tuesday, January 08, 2008 4:18 PM by jrp

# (Un)installing beta tr1

If I install this beta, will I be able to uninstall it / update it to final without problem??

PS: I agree with those that say that improving standards conformance -- particularly for straight C -- is more important to me than other new features.  The workarounds in boost give a good indication of how far VC++ is away from standard C++.  I am not particularly interested in .NET features.

Tuesday, January 08, 2008 7:58 PM by Stephan T. Lavavej [MSFT]

# Uninstallation

[jrp]

> If I install this beta, will I be able to uninstall

> it / update it to final without problem??

I am told that uninstallation works, which will get you back to VC9 RTM so that you can apply the final patch. I would suggest NOT trying to apply the final patch over the beta patch.

Stephan T. Lavavej

Visual C++ Libraries Developer

Wednesday, January 09, 2008 10:49 AM by NightHawk

# re: Just What Is This TR1 Thing?

-----------------------

[Stephan]

> Are you a world expert at library programming?  (If so, we're hiring!)  We've *got* some of the world experts at library programming, namely Dinkumware, working on TR1 - and it's not easy.  Take a look at TR1 mem_fn()/bind()/function's implementation when we release the TR1 beta, and then tell me that you could write that yourself.  :-)

>

> I consider myself lucky to be able to *understand* what most of the TR1 implementation does -...

-----------------------

What an arrogance !!

A good indication why VC is not progressing further and letting the C# and all its peers take precedence.

Well, what if we ask the same thing? "if the world experts, namely the so called Dinkumware, are doing better things that you cannot barely even "understand" - what is Microsoft Doing? Why are you with Microsoft? Why do not you join the "World experts"??

Don't try to underestimate your readers, and in turn pull-down your own company. Remember that your company, Micrsoft, has its foundations built on top of those very people you are criticizing with questions such as "Are you a world expert at library programming"....

If we are not world experts at library programming, you are not either (because this is not "your" library) !! Let us all praise the Dinkumware !!

 So much for an arrogant. Yuck.

Hello managers - what are you doing when one of your reports is criticizing your customers and bringing down your company values in public?? May be its a time you either give him a break or train him to be respectful. Seems he has forgotten the very core values of being open and respectful.

Sunday, January 13, 2008 5:27 PM by jrp

# re: Just What Is This TR1 Thing?

Reading this list, I do wonder what MS' priorities are.

While it is nice to have a performant IDE, it would be good to deepen standards conformance (for C as well as C++). For example, libsndfile does not compile with VC++.

It would also be good to update OMP support and improve vectorisation (with the advent of multi-core cpus).  We're now on OMP 2.5 and 3.0, whereas VC++ is only 2.0.

More pertinently to this thread, the use of parallelism in the standard library would be most welcome.  See what the gcc guys are up to.

Unless the strategy is to leave the parallel field to Intel?

Sunday, January 20, 2008 4:37 PM by Noticias externas

# Support du TR1 dans Visual Studio 2008

Soma annonce sur son blog le support du TR1 dans Visual Studio 2008 . Vous pouvez télécharger la béta

Monday, February 25, 2008 4:33 PM by Visual C++ Team Blog

# Channel 9: Stephan T. Lavavej: Digging into C++ Technical Report 1 (TR1)

Hello Recently we shipped a beta of our MFC/TR1 Feature Pack that, naturally enough, included a large

Monday, February 25, 2008 5:23 PM by Noticias externas

# Channel 9: Stephan T. Lavavej: Digging into C++ Technical Report 1 (TR1)

Hello Recently we shipped a beta of our MFC/TR1 Feature Pack that, naturally enough, included a large

Monday, April 07, 2008 8:48 AM by Visual C++ Team Blog

# Visual C++ 2008 Feature Pack Released!

The final release of the Visual C++ 2008 Feature Pack is now available for download. This release provides

Monday, April 07, 2008 1:41 PM by Johan Lindfors

# Visual C++ 2008 Feature Pack

Nu finns ett s&#229; kallat Feature Pack till Visual C++ 2008 att ladda he m f&#246;r alla kunder med

Monday, April 07, 2008 2:05 PM by US ISV Developer Evangelism Team

# Visual C++ 2008 Feature Pack Released

The final release of the Visual C++ 2008 Feature Pack is now available for download. This release provides

Tuesday, April 08, 2008 3:39 AM by Ruud de Jonge

# Visual C++ 2008 Feature Pack Released

Hello all, The final release of the Visual C++ 2008 Feature Pack is now available for download.&#160;

Friday, April 11, 2008 10:08 AM by Is This Thing On?

# C++ Gets Some Love

Good news from the C++ Team!! &#160; ================== The final release of the Visual C++ 2008 Feature

Tuesday, April 29, 2008 4:05 AM by Andrew Coates ::: MSFT

# Visual C++ 2008 Feature Pack Released

During my Windows Development session at the Heroes Happen { 2008 } launch shows around the country,

New Comments to this post are disabled
 
Page view tracker