Announcing a major MFC update plus TR1 support

Windows 7 - The native developer heaven

public class Alon : ISmartHome, ICPP, IHomeServer, IMediaCenter — Wed, 03 Dec 2008 03:18:19 GMT

Don't take me wrong, I do love C# and managed code, but often we need to develop in C++ and for good

re: Announcing a major MFC update plus TR1 support

Frank L. — Thu, 13 Dec 2007 04:54:41 GMT

I have to agree with Craig here. I don't really care about export myself, however, I do care that Microsoft is at least intending to conform to standards. Simply by definition, if Microsoft is not going to implement export, then they should not claim to be standards compliant. For this particular case, it makes sense to me for the community to modify the standard in the future, and that Microsoft be a part of this effort. They shouldn't sit in a corner and force everyone to do it 'their' way. Ever hear of blowback?...

With all that said, I applaud Microsoft for continually working to improve the compiler and their libraries. I've definitely seen the quality go up of the past decade. Compliance has gotten closer, which is good because in some cases, VC++ would simply be out of the running.

I wonder how Microsoft can determine what their customers want. If they look at whether or not developers buy and use their tools, then they will be misguided in believing that what they (the compiler/library people) are doing is a good thing. This is because, many times, organizations are forced into using Microsoft tools given the company's monopolistic nature. From my perspective, the development tools coming out of Microsoft are pretty much the best out there. So, obviously you guys are doing something right.

re: Announcing a major MFC update plus TR1 support

Craig — Sat, 01 Dec 2007 02:54:18 GMT

Stephan,

> I should have simply linked those articles, or Sutter's "Why We Can't Afford Export" paper, in the first place.

>Shame on me for trying to argue from first principles instead of citing authorities.

What authority? Like it or not, the simple undeniable fact is that export *is* part of the C++ standard. No matter what argument you make against it, a compiler that does not implement it is non-compliant.

Sutter and others tried to get export removed from the standard. That was rejected by the standard committee.

The only way out of implementing export is for Microsoft to declare that VC++ is not a C++ compiler and thus exempt from implementing the C++ standard.

You can claim to care about standards if you only selectively implement the parts that you like and omit the others.

re: Announcing a major MFC update plus TR1 support

Stephan T. Lavavej [MSFT] — Fri, 30 Nov 2007 23:16:48 GMT

[Phidias]

> now I understand the "... and there is export"

> comment of the blog author in a post above

I should have simply linked those articles, or Sutter's "Why We Can't Afford Export" paper, in the first place.

Shame on me for trying to argue from first principles instead of citing authorities.

> Still, can you (and CodeGear's) guys stop and work

> this out once for good? I shouldn't have to solve

> linker problems in 2007 by shuffling compilation

> order, dup(multip)licating explicit instantiations,

> regroup .obj files into smaller libraries and more

> generally rain dance around my computer. Thank you.

I'm not sure what you're talking about. It sounds like you're working with a broken library.

The inclusion model "just works" when you define templates in headers. Explicit instantiations are generally never necessary.

The linker could certainly have bugs, but I'd suspect a broken library first.

Stephan T. Lavavej

Visual C++ Libraries Developer

re: Announcing a major MFC update plus TR1 support

Phidias — Fri, 30 Nov 2007 12:37:48 GMT

Thank you very much for the link to this superb article. I was unaware of all these issues, and now I understand the "... and there is export" comment of the blog author in a post above, which without the proper explanation of Herb Sutter's article, sounded pretty much like a smartxxx remark at best, I'm sorry to say.

I realize now that my link problems are more or less poor behavior of linkers over large programs, not solvable by the use of export. So please, disregard my earlier post of Nov 21.

Still, can you (and CodeGear's) guys stop and work this out once for good? I shouldn't have to solve linker problems in 2007 by shuffling compilation order, dup(multip)licating explicit instantiations, regroup .obj files into smaller libraries and more generally rain dance around my computer. Thank you.

re: Announcing a major MFC update plus TR1 support

Craig — Thu, 29 Nov 2007 15:06:47 GMT

There are no "export restrictions".

As the article explains, that is how export was designed and standardized. Nothing more and nothing less.

I want it because it is part of the standard. It has been part of the standard for almost a decade. Other compilers (Comeau, Borland) implement it, but since VC++ does not it is difficult to compile standard-compliant code with multiple compilers. Asking for standard compliance should not be so unreasonable.

re: Announcing a major MFC update plus TR1 support

mos — Thu, 29 Nov 2007 02:43:50 GMT

For thos who still insist on an implementation of export "for completeness's sake", you should give the "Export Restrictions" articles by Herb Sutter a serious read.

Part 1: http://www.ddj.com/cpp/184401563

Part 2: http://www.ddj.com/cpp/184401584

(Apologies for resurrecting a weeks-old thread, but I just discovered this while arguing with a co-worker about the same subject.)

re: Announcing a major MFC update plus TR1 support

Phidias — Wed, 21 Nov 2007 12:51:12 GMT

I don't think I would buy a "Implement export now" T-shirt, but unlike most other posters above requesting export, I wish it was in VC++ because its absence is costing me a lot of time, daily, juggling around with code rearrangement.

Yes, you can theoretically rearrange code so that all your templates definitions can be found at link time, while keeping build time reasonable. However, my bet is that you have not been through this exercise for real, because if you did, you'd find that WITHIN a compiler, it's an easy job, but accross 2 vendors and over years of maintenance spanning several major updates, it's a nightmare.

This morning I just added into Borland 2007 the use of some tiny IO function for the F80 type... I'm still trying to link it. It worked fine with BCB6, fine also with VS8 beta 2, but I can't have it link in my current configuration. Although I agree that in this case it's a Borland problem, each vendor has their "smart template" link policy that just drives me nuts. Plus, because of VC's lack of support for export, I cannot use Borland's.

Yes, I could rearrange 13 years of code so that we stick to just one vendor. Give me better marshalling between .NET and native C++, and I'll consider using WindowsForms instead of VCL (high on my list: stress test of the new marshalling functions of VS8 once it's out of beta). Give me some really good MFC facelift and I give up VCL (it better be good... I have no idea how anything based on MFC could even get close to the productivity of VCL, but I'm willing to try).

...or give me export and I am a happy multi-vendor customer.

Note: I had template link nightmares within one vendor, when moving from BCB1 to BCB3 for example... This is not a vendor problem, just a lack of norm for template link that transforms the "rearrangement" workaround into a trial-and-error build workout.

re: Announcing a major MFC update plus TR1 support

Norman Diamond — Wed, 21 Nov 2007 03:31:38 GMT

For some programming languages, every compiler is non-conforming.

For some languages including C, every program on the face of the earth is a conforming compiler, whether or not it was intended to be a compiler. Also every program that has been exported from earth is a conforming C compiler. Some of us wish that the limits section would be debugged to change this, but meanwhile it's a fact.

Nonetheless, when we know what the standard is trying to say that we should do, and if other parts of the standard don't prohibit it, then we ought to try.

re: Announcing a major MFC update plus TR1 support

Adam G — Wed, 21 Nov 2007 03:19:03 GMT

ikk,

I agree with Derrick. A compiler is either conformant or non-conformant. The so-called "middle-ground" is moderate leeway given to compilers that fully intend to become more compliant in future versions. However, Microsoft has made it clear that they are not interested in implementing the standard (which includes export). Thus, in future versions, they will still be non-conformant. It's been nine years already without any progress, but perhaps if they would give a general target for implementing export, the situation can be reanalyzed.