Remaining Compliance issues for VC 7.0
![Ronald Laeremans [MSFT]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Ronald Laeremans [MSFT]
and compliance issues will not be addressed or fully addressed for the
upcoming Visual C++.Net 7.0 release.
I hope this list both allows you to have an understanding of the current
scope, and be able to focus bug finding in the Beta 2 and possible RC
releases.
- 2.2 Unicode Identifiers
- 3.4.2 Full Koenig Lookup
- 8.5.1 Empty Aggregate Initialization
- 9.8 Symbol Lookup for Local Member Functions
- 11.4 Friends in Class Templates (also 14.5.3)
- 13.3.1.1.2 Implicit Invocation of ptr-to-func Conversions
- 13.3.3.2 Ranking of Derived to Base conversions
- 14 Export Keyword
- 14.1 Reference Non-Type template parameters (also 14.3.2)
- 14.5.2 User-Defined Conversion Templates
- 14.5.4 Partial Specialization of Class Templates
- 14.5.5.2 Partial Ordering of Function Templates
- 14.6 Dependent Names
- 14.7.1 Nested Classes in Class Templates
- 14.7.3 Explicit Specialization of Member Templates
- 15.4 Exception Specifications
- 15.5.2 The unexpected() function
Comments welcome either in this thread or to me in email. To be completely
explicit about this, the list for this release is close to cast in stone.
For the next release after 7.0, we intend to aggressively work on most of
the remaining issues. In that list 14 is definitely ranked at the bottom of
the heap and 15.4 somewhat higher.
Ronald Laeremans
Visual C++ compiler team
Zachary Turner
release? Even something as broad as 2003, or 2004?
"Ronald Laeremans [MSFT]" <ronl...@microsoft.com> wrote in message
news:OjjSh71qAHA.2164@tkmsftngp02...
Zachary Turner
pretty much thought to be near the bottom of the list. Hasn't the C++
community pretty much determined that exception specifications are of VERY
little (if any) use (albeit the empty specification)
"Zachary Turner" <ztu...@bindview.com> wrote in message
news:unkBXg3qAHA.1736@tkmsftngp04...
Shiv Shankar Ramakrishnan
For the above two what subcases of them will be supported in VC7? I just
want to be assured that enough of the subfeatures of the above two will be
supported for me to make trivial use of them. I mean the commonly useful
cases could be covered if possible. Could you elaborate on them?
> - 14.5.4 Partial Specialization of Class Templates
> - 14.5.5.2 Partial Ordering of Function Templates
> - 14.7.3 Explicit Specialization of Member Templates
These would be the most requested and appreciated new features I guess. I
personally care about these the most. I can live without the others.
> For the next release after 7.0, we intend to aggressively work on most of
Would that be a whole new version like 8.0 or would it be a point release? I
remember that with VC4.0 there were useful point releases (or subscription
releases) like 4.1 and 4.2. I know that you might not be at liberty to talk
about the next release. But could you at least let us know if it is a point
release? That can make quite a difference in terms of when one gets to use
it :)
Thanks,
Shiv
Bo Persson
"Shiv Shankar Ramakrishnan" <Sh...@pspl.co.in> skrev i meddelandet
news:#u#ncC6qAHA.1472@tkmsftngp03...
>
> "Ronald Laeremans [MSFT]" <ronl...@microsoft.com> wrote in message
> > - 3.4.2 Full Koenig Lookup
> > - 11.4 Friends in Class Templates (also 14.5.3)
>
> For the above two what subcases of them will be supported in VC7? I just
> want to be assured that enough of the subfeatures of the above two will be
> supported for me to make trivial use of them. I mean the commonly useful
> cases could be covered if possible. Could you elaborate on them?
>
> > - 14.5.4 Partial Specialization of Class Templates
> > - 14.5.5.2 Partial Ordering of Function Templates
> > - 14.7.3 Explicit Specialization of Member Templates
>
> These would be the most requested and appreciated new features I guess. I
> personally care about these the most. I can live without the others.
Yes, these are *very* important to allow the use of iterator_traits and the
standard template library. I would help out *a lot* if the compiler would
accept the library synopsis at 24.2!
> > For the next release after 7.0, we intend to aggressively work on most
of
>
> Would that be a whole new version like 8.0 or would it be a point release?
I
> remember that with VC4.0 there were useful point releases (or subscription
> releases) like 4.1 and 4.2. I know that you might not be at liberty to
talk
> about the next release. But could you at least let us know if it is a
point
> release? That can make quite a difference in terms of when one gets to use
> it :)
There have been point releases lately too. They are just called Service
Packs...
VC6.0 SP5
> Thanks,
> Shiv
>
Bo Persson
b...@malmo.mail.telia.com
Shiv Shankar Ramakrishnan
"Bo Persson" <b...@malmo.mail.telia.com> wrote in message
> Yes, these are *very* important to allow the use of iterator_traits and
the
> standard template library. I would help out *a lot* if the compiler would
> accept the library synopsis at 24.2!
Well I did not necessarily mean STL. STL or the Std C++ Library is much
better in VC++7. I was more thinking along the lines of other libs like
Blitz++, POOMA like libs, some boost libs etc. i.e all libs which depend on
template specialization. Mostly expression templates kind of programming
techniques.
> There have been point releases lately too. They are just called Service
> Packs... VC6.0 SP5
Not strictly true. Service packs do not necessarily add new features. They
just fix features that were supposed to work in some way or fix bugs.
Whereas what I was talking about was VC4.0 and VC4.x. New features were
added in the VC4.x point releases.
Thanks,
Shiv
Andrea Ferro
news:eArNV57qAHA.1472@tkmsftngp03......
> > There have been point releases lately too. They are just called Service
> > Packs... VC6.0 SP5
>
> Not strictly true. Service packs do not necessarily add new features. They
> just fix features that were supposed to work in some way or fix bugs.
> Whereas what I was talking about was VC4.0 and VC4.x. New features were
> added in the VC4.x point releases.
I did not track VC changes. As for "theoretical" meaning of SP I agree with
Shiv. But MS has blurred the definition of "feature". Expecially with NT SPs!!
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info http://www.brainbench.com/transcript.jsp?pid=2522556
Tomas Restrepo
> I did not track VC changes. As for "theoretical" meaning of SP I agree
with
> Shiv. But MS has blurred the definition of "feature". Expecially with NT
SPs!!
Indeed, but I understood it is [was] company policy now to *not* get new
features in service packs, only bug fixes (I remember someone from MS saying
so).
But then again, it obviously doesn't apply to all the MS team, just look at
what's coming with Exchange 2000 SP1...
--
Tomas Restrepo
tom...@mvps.org
Bo Persson
>
> "Bo Persson" <b...@malmo.mail.telia.com> wrote in message
>
> > Yes, these are *very* important to allow the use of iterator_traits and
> the
> > standard template library. I would help out *a lot* if the compiler
would
> > accept the library synopsis at 24.2!
>
> Well I did not necessarily mean STL. STL or the Std C++ Library is much
> better in VC++7. I was more thinking along the lines of other libs like
> Blitz++, POOMA like libs, some boost libs etc. i.e all libs which depend
on
> template specialization. Mostly expression templates kind of programming
> techniques.
>
Ok, but *I* would very much like to see the partial template specialization,
as this is used as a basis for the template library.
As it is now, you either have to provide an explicit specialization
iterator_traits<mytype*>, which is awkward, or rely on fuction overloading,
which *does* work, but is equally inferior to the Standard way.
> > There have been point releases lately too. They are just called Service
> > Packs... VC6.0 SP5
>
> Not strictly true. Service packs do not necessarily add new features. They
> just fix features that were supposed to work in some way or fix bugs.
> Whereas what I was talking about was VC4.0 and VC4.x. New features were
> added in the VC4.x point releases.
But they *do* provide new features in the Service Packs, just like Win NT
does. It is not just bug fixes, but new APIs as well. At least the 5.x
service packs had improvements in the compiler as well. I remember a 10%
speed improvement for each SP.
My impression is that some inportant customers complained about the
subscriptions with quarterly updates (too much work upgrading a runnign
project). So MS increased the price of the 5.0 & 6.0 upgrades and gives us
"free" Service Packs instead...
Ronald Laeremans [MSFT]
in the team feel that exception specifications as specified are not
extremely useful.
exports is one of the features supported by very few compilers and with
quite a bit of uncertainty on how it is even supposed to work.
We intend to have significantly less time between the release of VC.Net 7.0
and the next release than between 6.0 and 7.0. That's is about as precise as
I can get.
Ronald Laeremans
Visual C++ compiler team
"Zachary Turner" <ztu...@bindview.com> wrote in message
news:OLVbzj3qAHA.2140@tkmsftngp02...
Tomas Restrepo
> I don't know about the C++ community in general. However, most of the
people
> in the team feel that exception specifications as specified are not
> extremely useful.
You're not alone...
> We intend to have significantly less time between the release of VC.Net
7.0
> and the next release than between 6.0 and 7.0.
Well, that *is* good news, I think :)
--
Tomas Restrepo
tom...@mvps.org
Zachary Turner
> I don't know about the C++ community in general. However, most of the
people
> in the team feel that exception specifications as specified are not
> extremely useful.
>
> exports is one of the features supported by very few compilers and with
> quite a bit of uncertainty on how it is even supposed to work.
>
> We intend to have significantly less time between the release of VC.Net
7.0
> and the next release than between 6.0 and 7.0. That's is about as precise
as
> I can get.
>
> Ronald Laeremans
> Visual C++ compiler team
A couple of questions:
- If the team feels that exception specifications are not extremely useful,
then why is it such a priority? (and yes, most of the C++ community agrees
that they are fairly useless) I'm assuming that since you used it as a
basis for comparing features that are and are not important to get into the
next release of the compiler that it must be ranked pretty high in the list
of features to support for the next release. I'm just curious as to why the
feature is so high on the priority list if it is so widely accepted as
useless.
- How about 14.5.4, partial specialization of class templates? I think
that without a doubt PTS (and maybe export, which I can accept as being at
the bottom of the list and live without) is wanted by more developers than
any other feature.
- How many bugfixes have or will have been made to features that are
already supposed to be fully supported? I know there's been numerous times
that I've tried to use language features that VC6 claims to support, only to
get internal compiler errors and such.
- Lastly, will a list be provided of bugfixes and new features added
between Beta 1 and Beta 2?
Thanks,
Zach
Ronald Laeremans [MSFT]
ranked number 2 from the bottom.
> - How about 14.5.4, partial specialization of class templates? I think
> that without a doubt PTS (and maybe export, which I can accept as being at
> the bottom of the list and live without) is wanted by more developers than
> any other feature.
That is on the top of the list. But then so are all the features that are
needed to compile and execute Blitz, POOMA and similar libraries. We want to
have at least that level of support in the next version.
> - How many bugfixes have or will have been made to features that are
> already supposed to be fully supported? I know there's been numerous
times
> that I've tried to use language features that VC6 claims to support, only
to
> get internal compiler errors and such.
We are EXTREMELY interested in getting bug report against any dingle feature
that isn't related to functionality in the list for the current (Beta 1)
compiler and for the Beta 2 compiler when we release it. We might not fix
all or even most of those issues if reported after we ship beta 2 and not
critical, but they will be in front of the list when we start work on the
next version.
> - Lastly, will a list be provided of bugfixes and new features added
> between Beta 1 and Beta 2?
We will be updating the KB articles describing known issues for the release,
but we will not be releasing a comprehensive fixlist that contains every
single issue we fixed from Beta 1 till Beta 2 or from VC 6. Producing that
list in any reasonable fashion would take too much resources for what we
currently think is the value of such a list. For the issues directly
reported here, or to me in email I have generally tried to keep folks
informed of the resolution of the issue they reported.
For Managed Extensions, we will be providing a list of changes from Beta 1.
-Ronald-
>
> Thanks,
> Zach
>
>
Zachary Turner
> > - If the team feels that exception specifications are not extremely
> useful,
> > then why is it such a priority? (and yes, most of the C++ community
> agrees
> > that they are fairly useless) I'm assuming that since you used it as a
> > basis for comparing features that are and are not important to get into
> the
> > next release of the compiler that it must be ranked pretty high in the
> list
> > of features to support for the next release. I'm just curious as to why
> the
> > feature is so high on the priority list if it is so widely accepted as
> > useless.
> It isn't a priority. What I thought I was stating is that it currently is
> ranked number 2 from the bottom.
misunderstood, I thought you were saying it was one of the highest
priorities.
>
> > - How about 14.5.4, partial specialization of class templates? I think
> > that without a doubt PTS (and maybe export, which I can accept as being
at
> > the bottom of the list and live without) is wanted by more developers
than
> > any other feature.
> That is on the top of the list. But then so are all the features that are
> needed to compile and execute Blitz, POOMA and similar libraries. We want
to
> have at least that level of support in the next version.
Even more excellent :)
> > - Lastly, will a list be provided of bugfixes and new features added
> > between Beta 1 and Beta 2?
> We will be updating the KB articles describing known issues for the
release,
> but we will not be releasing a comprehensive fixlist that contains every
> single issue we fixed from Beta 1 till Beta 2 or from VC 6. Producing that
> list in any reasonable fashion would take too much resources for what we
> currently think is the value of such a list. For the issues directly
> reported here, or to me in email I have generally tried to keep folks
> informed of the resolution of the issue they reported.
Sounds reasonable, just curious. I know some bug tracking tools provide
functionality that would make something like that trivial so I wasn't sure
which one you guys were using.
Shiv Shankar Ramakrishnan
> > - 3.4.2 Full Koenig Lookup
> > - 11.4 Friends in Class Templates (also 14.5.3)
>
> For the above two what subcases of them will be supported in VC7? I just
> want to be assured that enough of the subfeatures of the above two will be
> supported for me to make trivial use of them. I mean the commonly useful
> cases could be covered if possible. Could you elaborate on them?
I don't mean to be pesky :) But any answers to my above question? You did
cover my other questions in replies in the same thread.
Thanks,
Shiv
Ronald Laeremans [MSFT]
those 2 clauses isn't reliable enough to use it.
I see this as quite binary, if you can't trust the feature as a whole trying
to use it will be an exercise in frustration.
-Ronald-
"Shiv Shankar Ramakrishnan" <Sh...@pspl.co.in> wrote in message
news:uqHeWlIrAHA.1924@tkmsftngp03...
Ronald Laeremans [MSFT]
"Zachary Turner" <ztu...@bindview.com> wrote in message
news:#EfTenDrAHA.1392@tkmsftngp02...
... items 1 and 2 snipped
> > > - Lastly, will a list be provided of bugfixes and new features added
> > > between Beta 1 and Beta 2?
> > We will be updating the KB articles describing known issues for the
> release,
> > but we will not be releasing a comprehensive fixlist that contains every
> > single issue we fixed from Beta 1 till Beta 2 or from VC 6. Producing
that
> > list in any reasonable fashion would take too much resources for what we
> > currently think is the value of such a list. For the issues directly
> > reported here, or to me in email I have generally tried to keep folks
> > informed of the resolution of the issue they reported.
>
> Sounds reasonable, just curious. I know some bug tracking tools provide
> functionality that would make something like that trivial so I wasn't sure
> which one you guys were using.
The issue isn't the bug tracking tool (all of MS uses a home brew system
that works fine). It is the fact that the titles if the bugs are very often
meaningless, so we can't use these. The description of the bugs and the
history contains way too much proprietary info to just release (including
confidential customer info), and lastly much of it isn't what I would call
human-readable for anyone else than compiler writers (and even then<g>).
Cleaning all of that up is what would consume too many resources. In general
we use a pull process, if several customers have a problem with an issue, or
if it is a serious one, PSS writes up a KB article and goes trough the list
of published articles to update them at every release.
-Ronald-
Jimbo
<ronl...@microsoft.com> wrote:
Sorry to butt-in like this but I was meaning to post a rant about
something but never got round to it... So here goes.
[MS Internal Bug List]
>Cleaning all of that up is what would consume too many resources. In general
>we use a pull process, if several customers have a problem with an issue, or
>if it is a serious one, PSS writes up a KB article and goes trough the list
>of published articles to update them at every release.
Have you got a process of updating the proper docs with fixes
mentioned in KB articles. Reason I ask...
I was chasing my tail to fix a bug after using CFileFind to get a list
of files from a directory. I ended-up using the API calls as I
couldn't fathom it out. The docs stated one thing, but the class
behaved in another. After fixing it and swearing a lot, I found
article "Q166505" and proceeded to swear some more.
This KB article shows an error in the docs for CFileFind and it's
behaviour under NT. What made me swear was that this dates-back to
4.2 and the error in the docs is STILL present. You've quite happily
updated the KB article to include VC6 and NT/2000 over the years, so
what's the phobia about updating the docs, so you won't need to search
KB articles again ? .. or fix the bug in CFileFind.
If you find an error, you check your code and the docs to verify
you're using something correctly. If that's all OK, you then check
any library code (I blamed MFC and found it to be a problem).
Needless to say, you may have made VC incredibly productive, but that
all goes out the window when you spend a few hours fixing a single
problem when it isn't even the coders fault.
There may be hundreds of such articles that point to documentation
errors and I don't find it fun to fight with these. Are there any
plans to trawl through them and correct the docs for up-n-coming
PlaformSDK releases (or whatever docs you happen to use) ?
Cheers,
Jim M
--
@ Derbyshire
Tomas Restrepo
> There may be hundreds of such articles that point to documentation
> errors and I don't find it fun to fight with these.
Neither does anybody else, but it's better than nothing. MS can't magincally
correct the millions of MSDN library CDs that have been given away with VS
copies. Of course, they *could* update it in the newer packages, but that
probably has associated costs we know nothing about (plus, I guess they use
it as an incentive to get people to buy an MSDN subscription).
> Are there any
> plans to trawl through them and correct the docs for up-n-coming
> PlaformSDK releases (or whatever docs you happen to use) ?
Well, I don't know much about how the VS PSS team handle their KB updates
(funny, since I'm a VC++ MVP!), but I do know that the people in charge of
the PSDK support *do* update their KB articles fairly often. It makes up for
some funny situations where you point a guy to a KB article, only to find
that it says something completely different than what you expected <g>
Anyway, if you do find any KB articles in need of updating, let MS know.
There are several aliases that can help you report them, or post them in the
newsgroups and someone will get the word out to MS (like any of the MVPs).
HTH,
--
Tomas Restrepo
tom...@mvps.org
Bo Persson
"Tomas Restrepo" <tom...@mvps.org> skrev i meddelandet
news:#7zKJABrAHA.1364@tkmsftngp05...
Yes, he just promised the next version in *less* than three years! :-)
> --
> Tomas Restrepo
> tom...@mvps.org
>
>
Bo Persson
b...@malmo.mail.telia.com
Jimbo
<ronl...@microsoft.com> wrote:
>Hi,
<much snippage>
>everyone thought it was fixed in VC 6, but then it turned out that
>it wasn't really fixed. It is now really, really fixed in VC 7.
Smashing.
>I am sorry it took this long.
I suppose I swore alot as it's the classic "check the KB articles" and
I got bitten by it when I should have known better.
>Everyone assures me this bug is an aberrant case, and several people
>immediately knew about it on sight when I forwarded this internally.
If I was working in MFC full-time, it's the sort of thing I'd have
probably known about but it was a shock :) Nay-mind.
Unlike the the SDK docs that change whenever you
change/update/enhance/break something, other library docs only get
released with major products don't they ? Twas a long boat to miss.
<more snippage>
A few more things before you *plonk* me:
* From the newsgroup posts, it seems like hh.exe is embedded in the
new ide, will it be optional to have it external ?
* Are you still using compiled html files still or will it be a change
like infoviewer was to htmlhelp ?
* Has any work been done on the resouce compiler, resouce editor and
resouce file-manager in the last few years ?
That's all really, cheers,
Tomas Restrepo
> * From the newsgroup posts, it seems like hh.exe is embedded in the
> new ide, will it be optional to have it external ?
HH:EXE is no longer used. There's a new version of the HTML Help engine. And
yes, you can run it outside of the IDE (look for dexplore.exe on your VS.NET
instalation). You can also configure how it pops out when you invoke help
from the IDE with F1, which is also nice.
>
> * Are you still using compiled html files still or will it be a change
> like infoviewer was to htmlhelp ?
There are a few changes in the format. I believe it's being called HTML Help
2.0, but I'm not sure....
> * Has any work been done on the resouce compiler, resouce editor and
> resouce file-manager in the last few years ?
Wouldn't know for sure. Some things have changed in the resource editor,
though, in as much as I can tell.
--
Tomas Restrepo [VC++ MVP]
tom...@mvps.org
http://www.mvps.org/windev/
Shiv Shankar Ramakrishnan
trying
> to use it will be an exercise in frustration.
Err ... true, but I was more worried about cases like for example something
that the std C++ library depended on for some critical operation. Case in
point operator<< of ostreams for all types being in namespace std. Now
obviously you have taken care of that and so Koenig lookup works for
operators.
All I wanted was a reassurance on such cases which might bite unwary users
badly. Of course I may not have the resources to assess the relative
importance of every such feature. Whereas I do hope and trust that the
people on the Visual C++ compiler team take a hard long look and think of
supporting certain critical sub features if possible. Thats all I meant.
Thanks,
Shiv
Andy Bolstridge
;-) Andy.
Ronald Laeremans [MSFT]
-Ronald-
"Bo Persson" <b...@malmo.mail.telia.com> wrote in message
news:eLbvKEOrAHA.2344@tkmsftngp05...
Andrea Ferro
> > 7.0
> > > and the next release than between 6.0 and 7.0.
> >
> > Well, that *is* good news, I think :)
>
> Yes, he just promised the next version in *less* than three years! :-)
If you count it from today, it is "*Intend* the next version in less then three
years + *twice* the time it will take from now to the actual VC7 release" :-)
Didn't you really think the commecial side of MS would let a techie say it
differently ;-)
Jimbo
wrote:
>Hi Jim,
P.S. I don't know if the same KB article I quoted was the same I
found. If you state that the numbers to change over time, that's a
3-year old number now ! It's there in the latest MSDN though.
>Of course, they *could* update it in the newer packages, but that
>probably has associated costs we know nothing about
Well, they do touch the SDK files, and update KB articles, but is
that's got to be semi-automated. This KB article has survived 3
generations of MFC which is going on 6 years pointing to a mis-stated
paragraph in the docs. These docs have been completely updated twice
since the bug was found (infoviewer embedded, then infoviewer embedded
but a whole load of new MFC stuff, then to hh.exe and chm's) !! That's
taking more space up than if they'd fixed it.
Say 1/4 million KB articles. 20000 MS staff world-wide. 1-a-day each
would get through the lot in nearly 2 weeks. 1-a-week each, do it in
3 months. Thats just to find something that the automated system is
obviously missing.
There you go, simple innit :-)
Ta ra,
Ronald Laeremans [MSFT]
You can rest assured that we will be shipping a balanced compiler and
libraries. We have workarounds in our STL implementation for the compliance
areas that have an impact. As long as your code doesn't exercise the feature
set of the paragraphs I posted beyond what you have working with VC 6, you
will be safe. Some more things might work in some instances, but as I said,
probing for the edges is something I would only suggest as an academic
exercise.
And BTW, if there are people here that feel they are very good about probing
for the edges, talk to me about a compiler QA job.;-)
-Ronald-
"Shiv Shankar Ramakrishnan" <Sh...@pspl.co.in> wrote in message
news:uP9U6ZTrAHA.1800@tkmsftngp02...
Bo Persson
"Ronald Laeremans [MSFT]" <ronl...@microsoft.com> skrev i meddelandet
news:#arT8xXrAHA.1800@tkmsftngp02...
> Note that I said "intend" ;-)
>
> -Ronald-
Yes, I saw that, but we all took it as a promise.
We'll get back to than in late 2004...
Bo Persson
b...@malmo.mail.telia.com
Howard Kapustein
> subscriptions with quarterly updates (too much work upgrading a runnign
> project). So MS increased the price of the 5.0 & 6.0 upgrades and gives us
> "free" Service Packs instead...
Not so.
As I've heard it (from more than 1 MS source), ~10% of the VC4 users bought the
subscription plan. Coupled with the problems of some people only want fixes and
can't bear to deal with the quirks new features bring to the table vs. others
who want new features (and are willing to pay!) but there's only so many
developers to go around...
The 3 year lag between VC6->7 is sad, but in no small part due to the VS group
spending a non-trivial chunk of their time on what became the CLR. Throw in a
little Java lawsuit to muddle planning and direction and 3 years is rather
understandable. [Sad, pathetic, and irritating as all get out, but
understandable. Just don't confuse them. Understanding != Excusing or Forgiving]
Personally, I'd rather see the "service packs = only bug fixes" and new function
= new release. You might want that nifty new widget today, but at least the
"fixes only" approach ensures a reasonably stable and understood toolset.
- Howard
--
Email: mailto:how...@kapustein.com WWW: http://www.kapustein.com/howard/
--
"I think that's how Chicago got started. A bunch of people in New York
said, 'Gee, I'm enjoying the crime and the poverty, but it just isn't
cold enough. Let's go west.' "
--Richard Jeni
Ronald Laeremans [MSFT]
I tracked down this specific issue and due to reasons I can't fathom out
after the fact this was supposed to be fixed in VC 6, everyone thought it
was fixed in VC 6, but then it turned out that it wasn't really fixed. It is
now really, really fixed in VC 7. I am sorry it took this long.
Everyone assures me this bug is an aberrant case, and several people
immediately knew about it on sight when I forwarded this internally.
-Ronald-
"Jimbo" <}Jim$m{@brit-cit.demon.co.uk> wrote in message
news:ragvatctoik4rai9s...@4ax.com...
Jimbo
wrote:
>Hi Jim,
>
>> * From the newsgroup posts, it seems like hh.exe is embedded in the
>> new ide, will it be optional to have it external ?
>
>HH:EXE is no longer used. There's a new version of the HTML Help engine. And
>yes, you can run it outside of the IDE (look for dexplore.exe on your VS.NET
>instalation). You can also configure how it pops out when you invoke help
>from the IDE with F1, which is also nice.
Nice.
When it moved from inside the IDE to stand-alone, I was really
dead-against it, but after a couple of months usage, found it to loads
better and don't want it to go back to being embedded, which is a
complete U-turn that I didn't expect. Very handy if you've got
multiple IDE's open and you don't want the help loaded into each
instance.
Cheers Tomas,
Dima Pasechnik
header, that makes a fuller use of VC7.0 compiler than that currently
is the case the with STL. (It removes the necessity of iterators being
derived from the supplied (nonstandard, for iterator is a concept, not
a standard class) iterator template).
Is there any hope that it can eventually make it into the STL you ship?
For us (http://www.cgal.org)
it would make it unnecessary to do the overloading
of some include files that we are currently forced to do via
modifying the standard order of include directories, to much confusion
of the users...
--
Dmitrii V. Pasechnik
http://ssor.twi.tudelft.nl/~dima
Ron Ruble
need to be reviewed and implemented by DinkumWare.
Dima Pasechnik wrote in message ...
Michael Viking
lack of interest in building a compiler that is compliant with the C++
standard. I for one find it appalling that in the 2-3 years since the last
version of the compiler (version 6) MS has fixed approximately 4 of their
known compliance problems. Doesn't that kind of imply that MS isn't that
interested in the standard? Rather, they are interested in their own
extensions so that people can write non-compliant code that will only
compile with their tool, and run on their OS.
Let me be the first to say SHAME ON YOU. Not everybody writes web
applications. Not everybody wants 12 new MS-only keywords added to the
language. Some people are interested in a compliant compiler that has as
few bugs as possible.
Michael Viking
"Ronald Laeremans [MSFT]" <ronl...@microsoft.com> wrote in message
news:OjjSh71qAHA.2164@tkmsftngp02...
> As I promised quite a while ago, here is an overview of what C++ features
> and compliance issues will not be addressed or fully addressed for the
> upcoming Visual C++.Net 7.0 release.
>
> I hope this list both allows you to have an understanding of the current
> scope, and be able to focus bug finding in the Beta 2 and possible RC
> releases.
>
> - 2.2 Unicode Identifiers
> - 3.4.2 Full Koenig Lookup
> - 8.5.1 Empty Aggregate Initialization
> - 9.8 Symbol Lookup for Local Member Functions
> - 11.4 Friends in Class Templates (also 14.5.3)
> - 13.3.1.1.2 Implicit Invocation of ptr-to-func Conversions
> - 13.3.3.2 Ranking of Derived to Base conversions
> - 14 Export Keyword
> - 14.1 Reference Non-Type template parameters (also 14.3.2)
> - 14.5.2 User-Defined Conversion Templates
> - 14.5.4 Partial Specialization of Class Templates
> - 14.5.5.2 Partial Ordering of Function Templates
> - 14.6 Dependent Names
> - 14.7.1 Nested Classes in Class Templates
> - 14.7.3 Explicit Specialization of Member Templates
> - 15.4 Exception Specifications
> - 15.5.2 The unexpected() function
>
> Comments welcome either in this thread or to me in email. To be completely
> explicit about this, the list for this release is close to cast in stone.
>
> For the next release after 7.0, we intend to aggressively work on most of
> the remaining issues. In that list 14 is definitely ranked at the bottom
of
> the heap and 15.4 somewhat higher.
>
Paul Mensonides
"Michael Viking" <TheV...@sweden.se> wrote in message news:#MnlPfxsAHA.1912@tkmsftngp04...
: I'm very surprised that nobody seems to be upset at Microsoft's apparent
: lack of interest in building a compiler that is compliant with the C++
: standard. I for one find it appalling that in the 2-3 years since the last
: version of the compiler (version 6) MS has fixed approximately 4 of their
: known compliance problems. Doesn't that kind of imply that MS isn't that
: interested in the standard? Rather, they are interested in their own
: extensions so that people can write non-compliant code that will only
: compile with their tool, and run on their OS.
: Let me be the first to say SHAME ON YOU. Not everybody writes web
: applications. Not everybody wants 12 new MS-only keywords added to the
: language. Some people are interested in a compliant compiler that has as
: few bugs as possible.
:
: Michael Viking
I definitely agree, Michael. It's not like MS doesn't have the resources to put together a compliant compiler--especially in three
years. I don't care if MS adds to the language; I just don't want them to take away from it. That way, if people want to use the
MS extensions they can (C++ is a tool to get a job done, after all). Those that don't can use a complete C++ language (minimizing
extensions as much as possible). Other companies--such as Comeau--which have a lot less resources to work with can do it (including
VC++ compatibility mode), so why can't MS?
Paul Mensonides
Shiv Shankar Ramakrishnan
> have a lot less resources to work with can do it (including VC++
> compatibility mode), so why can't MS?
Don't let appearances deceive you. Comeau doesn't do everything on its own.
It uses the C++ compiler front end (arguably the best in the world) from EDG
(http://www.edg.com/cpp.html). This has been worked on for close to 10
years. A lot of the other compiler vendors use this front end. Intel also
uses it for its C++ compiler. Which is why I can bet EDG has so many MS
compatibility features. While I am myself not very happy with the state of
C++ with VC++.Net I do not blame MS just for the heck of it. The last VC++
compiler (6.0) came before the std was finalized and there was some stupid
lawsuit that Dinkumware got involved in that screwed all STL/Std Lib users
of C++ for VC++ 6. Then high and mighty Sun took a holier than thou attitude
with Java which caused MS to devote resources to C#. So you know where all
the effort went. I can see why the compiler team might not have been able to
fix things even if they wanted to.
Coming back to VC++ as it stands. I can tell you that its a lot more decent
than some compilers out there. Ever tried Sun's C++ compiler? You'll come
back crying and crawling to VC++. And GCC? Though better in compliance lacks
in areas like Std lib, code gen quality, compile times (horrible), no
precompiled headers, optimizations are risky etc etc. VC++ may not be all we
want but its not that bad also okay. In fact take a look at the boost
site -http://www.boost.org/status/compiler_status.html
And you'll see that VC does pretty well.
Another thing that amazes me is that most average VC++ users don't care two
hoots about std compliance. So when a survey is done guess what the managers
must be saying? Unless people who use VC++ complain some people may not take
it seriously.
Bash VC++ for all you want but don't do it just for the heck of it. All
flames welcome.
Thanks,
Shiv
Zachary Turner
think of 4 off the top of my head, and there's probably at least 10-12 more.
"Michael Viking" <TheV...@sweden.se> wrote in message
news:#MnlPfxsAHA.1912@tkmsftngp04...
andrew queisser
work.
Andrew
"Michael Viking" <TheV...@sweden.se> wrote in message
news:#MnlPfxsAHA.1912@tkmsftngp04...
Ronald Laeremans [MSFT]
select a supportive one<g>).
I have given some background on this several months in this forum, but I
don't know what our scroll times are, so I'll have a stab at it again.
The main decision the C++ team was faced with in this release was to either
devote most of the effort to compliance issues, or to have a stab at making
sure C++ on Microsoft platforms was still a viable language to use to write
code in a managed execution environment. We chose the latter.
We have fixed several hundred minor and not so minor compliance issues
between VC 6 and VC 7 in the paragraphs of the standard that aren't in the
list of what I posted. We also made significant strides in improving
template error messages and in now shipping the STL implementation that was
very recently judged best in the C++ User Journal review. Those 2 issues are
by far the most reported stumbling blocks to get C++ development team to
start using template or increase their template usage.
Fixing compliance issues in the VC compiler is significantly complicated by
backwards compliance issues and the QA effort that that involves. By far the
number one requested "feature" of our build tools is not to break existing
code when compiled by the new compiler. And especially not to introduce
semantic changes (getting new compiler errors, is not something users are
ecstatic about either, but at least some reasonable fraction is willing to
live with that for increased compliance).
It is exactly because the Visual C++ team is very much interested in
compliance issues, that we are making an aggressive move to address this in
the next version. Realizing full well that not more than a couple thousand
developers at the outside are interested in the least.
I really feel that the C++ world is getting more and more bipolar. A quick
look at a book like Generative Programming is one shows one end of the
spectrum. Reading the survey replies of our C++ customers, talking to
customers on site visits and at conferences and yes, interviewing candidates
with C++ experience for development positions tends to show the opposite
side of the spectrum.
And yes, Microsoft is a commercial entity and Microsoft does have an agenda,
so although there are lots of customers that have no interest at all in web
development and in a managed execution environment, that is where the
overwhelming majority of users are asking us to go.
Ronald Laeremans
Visual C++ compiler team
"Shiv Shankar Ramakrishnan" <Sh...@pspl.co.in> wrote in message
news:#aJ0Mc1sAHA.1924@tkmsftngp03...
andrew queisser
is posting here. But I do have some comments (which you've undoubtedly
already heard in one form or another):
"Ronald Laeremans [MSFT]" <ronl...@microsoft.com> wrote in message
news:u5pMHb#sAHA.2124@tkmsftngp05...
> The main decision the C++ team was faced with in this release was to
either
> devote most of the effort to compliance issues, or to have a stab at
making
> sure C++ on Microsoft platforms was still a viable language to use to
write
> code in a managed execution environment. We chose the latter.
>
Which brings us back to the root question: if MS is more interested in
extending
VC++ to run in a managed execution environment (== .NET) instead of
focussing on standards compliance, wouldn't it be fair to say that MS is
more
interested in moving programmers into the next MS platform than in providing
a
standards conforming compiler?
I don't think there's anything morally wrong with that but what is happening
is that
people like me who are using VC++ as a decent C++ compiler for non-Web,
non-COM, non-XML, non-(insert favorite buzzword here) applications are now
left with hardly any improvement at all. I just want a solid C++ compiler
with
which I can use the C++ language as defined by the standard. Nothing more,
nothing less. By that definition the MS VC compiler team has next to nothing
for
me in the past few years.
Disappointed in Corvallis,
Andrew Queisser
Paul Mensonides
: I will reply this post on the thread (when I can choose which post, why not
: select a supportive one<g>).
:
: I have given some background on this several months in this forum, but I
: don't know what our scroll times are, so I'll have a stab at it again.
:
: The main decision the C++ team was faced with in this release was to either
: devote most of the effort to compliance issues, or to have a stab at making
: sure C++ on Microsoft platforms was still a viable language to use to write
: code in a managed execution environment. We chose the latter.
And by doing so, you will cause a great deal more "non-compliant" code to be created that will have to be fixed when (and if) MS
actually releases a standard compliant compiler.
: We have fixed several hundred minor and not so minor compliance issues
: between VC 6 and VC 7 in the paragraphs of the standard that aren't in the
: list of what I posted. We also made significant strides in improving
: template error messages and in now shipping the STL implementation that was
: very recently judged best in the C++ User Journal review. Those 2 issues are
: by far the most reported stumbling blocks to get C++ development team to
: start using template or increase their template usage.
:
: Fixing compliance issues in the VC compiler is significantly complicated by
: backwards compliance issues and the QA effort that that involves. By far the
: number one requested "feature" of our build tools is not to break existing
: code when compiled by the new compiler. And especially not to introduce
: semantic changes (getting new compiler errors, is not something users are
: ecstatic about either, but at least some reasonable fraction is willing to
: live with that for increased compliance).
Why don't you just have a backward compatibility pragma and make the different "types" of translation units able to link to each
other?
: It is exactly because the Visual C++ team is very much interested in
: compliance issues, that we are making an aggressive move to address this in
: the next version. Realizing full well that not more than a couple thousand
: developers at the outside are interested in the least.
That is a gross assumption. Most programmers don't respond to polls and surveys, especially in the C++ community which has a great
many UNIX programmers (I'm not one however.) who hate Microsoft for reasons just like this non-compatibility issue. Maybe if there
was a single standard-compatible compiler on the market for Win32, MS could draw more UNIX programmers, etc..
(and maybe Windows would draw more software)
: I really feel that the C++ world is getting more and more bipolar. A quick
: look at a book like Generative Programming is one shows one end of the
: spectrum. Reading the survey replies of our C++ customers, talking to
: customers on site visits and at conferences and yes, interviewing candidates
: with C++ experience for development positions tends to show the opposite
: side of the spectrum.
:
: And yes, Microsoft is a commercial entity and Microsoft does have an agenda,
: so although there are lots of customers that have no interest at all in web
: development and in a managed execution environment, that is where the
: overwhelming majority of users are asking us to go.
:
: Ronald Laeremans
: Visual C++ compiler team
This is also a gross assumption. I seriously doubt the "overwhelming majority" of users even asks you for anything. I don't have a
problem with compiler-specific language extensions as long as they are obviously extensions, so that people can avoid them if they
like. MS has done a fairly decent job in this regard with __declspec(...), __stdcall, etc.. For the most part, it is obvious that
you are using an MS extension. However, you can't extend what you don't have, and MS doesn't have a C++ compiler--only a C++ subset
compiler. I definitely appreciate the improvements that you have made so far in this regard, and I think that the VC++ IDE (and VS
in general) are among the best that I've seen so far, but, from a company with the resources that MS has, that is not good enough.
I'm not blaming you, Ronald, or the VC++ team, personally--maybe it's Microsoft in general that isn't delegating enough resources to
this specific project (we all know what managers are like also! :) ). If -- and I don't think this will happen based on MS's agenda
and past experience with MS -- VC++ 8 actually fully supports the standard (provided there is not a new one by then), I will be
happy and give you more credibility then I am now.
On a side note, why don't you send out new/corrected features through patches or service packs? Instead, just for VC++ 7 we've had
to wait years--all the while piling up bad-coded workarounds. If you did this, and you corrected or implemented one standard C++
feature that you don't have now (or don't have correct now) every 3 months or so, and you you released it as a patch or the like,
I'd quit complaining because I'd actually BELIEVE that MS gives a crap about the standard and is seriously heading towards
compliance. You are right, C++ is becoming more and more bipolar--there is the C++ committee that actually believes in the point of
C++, and there is Microsoft which is doing its best to take C++ in the complete opposite direction. C++ is supposed to be a
close-to-the-hardware, efficient, low-level programming language--not a code generator (i.e. [attributes], .NET, garbage collection,
managed execution, etc.). Microsoft should have concentrated that effort soley into a new language (like C#, for instance), and
later, after they actually had a C++ compiler, they could integrate that stuff as extensions to it.
Paul Mensonides
Dima Pasechnik
leav...@home.com op 24-03-2001 00:29:
> "Ronald Laeremans [MSFT]" <ronl...@microsoft.com> wrote in message
> news:u5pMHb#sAHA.2124@tkmsftngp05...
[...]
>
> : It is exactly because the Visual C++ team is very much interested in
> : compliance issues, that we are making an aggressive move to address this in
> : the next version. Realizing full well that not more than a couple thousand
> : developers at the outside are interested in the least.
>
> That is a gross assumption.
I agree fully, Ronald is off by a couple of orders of magnitude here...
(just count the programmers who actively use popular C++ libraries...)
> Most programmers don't respond to polls and
> surveys, especially in the C++ community which has a great
> many UNIX programmers (I'm not one however.) who hate Microsoft for reasons
> just like this non-compatibility issue.
[...]
I add that just the number of programmers who got an RSI porting C++ code to
VC++ can most probably be counted in thousands (you don't see these people,
you don't hear them online either, you don't interview them for development
positions...).
And add many thousands of man-years wasted looking for workarounds for ICEs,
etc., in VC++.
> : And yes, Microsoft is a commercial entity and Microsoft does have an agenda,
> : so although there are lots of customers that have no interest at all in web
> : development and in a managed execution environment, that is where the
> : overwhelming majority of users are asking us to go.
> :
oh yeah, as if users didn't ask you to fix all these thousands of bugs in
VC++....
[...]
</endflamemode>
Dmitrii.
Ronald Laeremans [MSFT]
"Dima Pasechnik" <d.pas...@twi.tudelft.nl> wrote in message
news:B6E1A5D8.1B17%d.pas...@twi.tudelft.nl...
> in artikel #5rmhG$sAHA.1924@tkmsftngp03 schreef Paul Mensonides op
> leav...@home.com op 24-03-2001 00:29:
>
> > "Ronald Laeremans [MSFT]" <ronl...@microsoft.com> wrote in message
> > news:u5pMHb#sAHA.2124@tkmsftngp05...
> [...]
> >
> > : It is exactly because the Visual C++ team is very much interested in
> > : compliance issues, that we are making an aggressive move to address
this in
> > : the next version. Realizing full well that not more than a couple
thousand
> > : developers at the outside are interested in the least.
> >
> > That is a gross assumption.
> I agree fully, Ronald is off by a couple of orders of magnitude here...
> (just count the programmers who actively use popular C++ libraries...)
I left out a part in my original post that I emant to include. I am only
counting the developers that actively uses the features in their own
implementation, not about the leverage you get from many more people using
libraries that need this feature to be able to work optimally.
> > Most programmers don't respond to polls and
> > surveys, especially in the C++ community which has a great
> > many UNIX programmers (I'm not one however.) who hate Microsoft for
reasons
> > just like this non-compatibility issue.
We do surveys by randomly sampling all of our users for one series, and by
randomly sampling the entire population and screening for developers for
another series. If many more of the people that are interested in compliance
refuse to answer questions and the ones that aren't, are much more eager to
do so, then there is no way to get valid results. But we try very hard to
get valid data from non self-selected groups.
There are a lot of Unix and Linux developers that hate Microsoft for all
kinds of reasons. Including the fact that we charge a license fee, that we
don't distribute source code for all our products and that we certainly
don't release it under GPL. And we do not produce a multiplatform C++
compiler, we produce a C++ compiler for the Windows platforms only.
> I add that just the number of programmers who got an RSI porting C++ code
to
> VC++ can most probably be counted in thousands (you don't see these
people,
> you don't hear them online either, you don't interview them for
development
> positions...).
>
> And add many thousands of man-years wasted looking for workarounds for
ICEs,
> etc., in VC++.
Another thing we spent effort on for this release is to make sure that you
get clear error messages instead of an ICE when trying to use an unsuported
feature.
> > : And yes, Microsoft is a commercial entity and Microsoft does have an
agenda,
> > : so although there are lots of customers that have no interest at all
in web
> > : development and in a managed execution environment, that is where the
> > : overwhelming majority of users are asking us to go.
> > :
> oh yeah, as if users didn't ask you to fix all these thousands of bugs in
> VC++....
I would have liked to have a better compliance story for VC 7.0, but I do
very firmly believe that the Visual C++ compiler, including the Visual C++
6.0 compiler is one of the most stable and reliable compilers in the
industry.
-Ronald-
Ronald Laeremans [MSFT]
Does your statement mean that you are not interested in anything besides the
command line build tools (not the IDE, debugger, project system), and of
those not even in optimizations work we did for this version. In addition it
has been getting quite hard recently to write fully fledged windows
solutions without using COM (shell integration, manageability, DirectX, all
the recent database APIs are COM).
I am just trying to understand what you find important in a development
tool, and I am not sure I have a good idea from your post quoted below.
-Ronald-
Ronald Laeremans [MSFT]
"Paul Mensonides" <leav...@home.com> wrote in message
news:#5rmhG$sAHA.1924@tkmsftngp03...
> "Ronald Laeremans [MSFT]" <ronl...@microsoft.com> wrote in message
news:u5pMHb#sAHA.2124@tkmsftngp05...
> : I will reply this post on the thread (when I can choose which post, why
not
> : select a supportive one<g>).
> :
> : I have given some background on this several months in this forum, but I
> : don't know what our scroll times are, so I'll have a stab at it again.
> :
> : The main decision the C++ team was faced with in this release was to
either
> : devote most of the effort to compliance issues, or to have a stab at
making
> : sure C++ on Microsoft platforms was still a viable language to use to
write
> : code in a managed execution environment. We chose the latter.
>
> And by doing so, you will cause a great deal more "non-compliant" code to
be created that will have to be fixed when (and if) MS
> actually releases a standard compliant compiler.
targetting .Net. The compliance work we do is completely unrelated to that.
...
> Why don't you just have a backward compatibility pragma and make the
different "types" of translation units able to link to each
> other?
Because that is one of the hard things to do, we need to make object model
changes that will have link-time effects. Working trough these issues and
making sure we catch all the corner cases is what is hard.
> ... If -- and I don't think this will happen based on MS's agenda
> and past experience with MS -- VC++ 8 actually fully supports the standard
(provided there is not a new one by then), I will be
> happy and give you more credibility then I am now.
There is no (zero, 0) compiler out there that fully support the standard.
Sicne the decision was made not to have s standards certification process,
in all likelyhood there never will be one. The fact that we (in the C++
standards comitee sense) are currently working on a defect report will make
that even more true. We do intend to be one of the compilers that is
"substantially compliant". As a very simple internal goal we have that we
will be able to compile all the libraries that use modern, completely
template-based code lie POOMA, Blitz and libraries based on Todd
Veldhuizen's expression template library. In addition we are targetting the
BOOST libraries with VC workaround removed and removal of the few
workarounds we currently have in our STL implementation. Since I don't pay
the bills here, I can't make you a promise that I can keep, but I am willing
to bet you a couple of microbrews in a bar in Seattle that we will meet that
goal for the next version.
> On a side note, why don't you send out new/corrected features through
patches or service packs? Instead, just for VC++ 7 we've had
> to wait years--all the while piling up bad-coded workarounds. If you did
this, and you corrected or implemented one standard C++
> feature that you don't have now (or don't have correct now) every 3 months
or so, and you you released it as a patch or the like,
> I'd quit complaining because I'd actually BELIEVE that MS gives a crap
about the standard and is seriously heading towards
> compliance. You are right, C++ is becoming more and more bipolar--there
is the C++ committee that actually believes in the point of
> C++, and there is Microsoft which is doing its best to take C++ in the
complete opposite direction. C++ is supposed to be a
> close-to-the-hardware, efficient, low-level programming language--not a
code generator (i.e. [attributes], .NET, garbage collection,
> managed execution, etc.). Microsoft should have concentrated that effort
soley into a new language (like C#, for instance), and
> later, after they actually had a C++ compiler, they could integrate that
stuff as extensions to it.
It is an enticing concept to try and decouple ship cycles for command-line
development tools and the big ship vehicle that Visual Studio is. Apart from
some serious issue (e.g. there are quite a few things the debugger engine
needs to be made aware of when adding features) That however is far from
simple and again I will state (and I guess again you will say I have the
numbers incorrect<g>) that the majority of the customers I talked to do not
want to go trough the hassle and use a new compiler every 6 months or so.
Most of them want critical bug fixes and no semantic changes whatsoever for
service packs. If we were to add new features into service packs a lot of
customer IT organizations would treat them as new releases and go trough a
3-12 month evaluation period before allowing their developers to use them.
Regardless, we are indeed investigating if we can do anything in this area.
-Ronald-
Shiv Shankar Ramakrishnan
> was very recently judged best in the C++ User Journal review. Those 2
In case people are wondering about this, here is the link -
http://www.cuj.com/roundup/index.htm
> I really feel that the C++ world is getting more and more bipolar. A quick
> look at a book like Generative Programming is one shows one end of the
> spectrum. Reading the survey replies of our C++ customers, talking to
Can you elaborate a little more on what you mean by this (bipolar C++
world)? Do you mean the VC++ and Windows world Vs. other C++ and *NIX world?
Or do you mean the leave C++ as is world Vs. the I want Std C++ world? Or
the conservative C++ users (for whatever reasons) Vs. the bleeding edge C++
users world? Or the Java/C#/.Net/Other GC-lang loving world Vs. the native
bare metal C/C++ world? Yeah yeah too many of those :)
And Ronald I can tell you that you have got it quite wrong as to how many
people want Std C++. Your coverage is surely flawed. Its definitely an order
of magnitude wrong. For example here in my firm I can vouch for the division
I work in that most ppl want it. You see some of them don't even realise
some things and hit walls in things like STL/Std Lib. Then I explain that
most C++ compilers aren't good enough. Then they wish they were. So some of
the desire is subtle and they don't even know it. How the heck do you
quantify that? And how come I never got to see one of those surveys by MS?
And how come none of the other ppl here who care about Std compliance have
also never seen such a thing? I openly ask you to put up a link on the VC++
home page as a survey to see how many people are interested. I can bet you
will be surprised. I remember Borland did this once on their site and found
out that the majority of people cared a lot. Then they pulled up their socks
quite a bit for std issues in BC++ 5.5.
And IMHO backwards compatibility should not hold a great product to ransom
against implementing new features. And MS has in the past introduced great
new features and still maintain backward compatibility. An excellent example
is Windows NT. So is SQL Server 7.0. They even managed to convince god knows
how many customers to convert all thier critical RDBMS data in SQL 6.5 to
the immensly improved SQL 7.0 format. (Yes I know a thing or two about SQL
Server 7.0 ;) So why is the Visual C++ team so afraid of coaxing users to
new features and educating them about some breakeages. Why, isn't that what
you are doing in VS.NET for Java with the "JUMP to .NET" program?! ;)
Thanks,
Shiv
Jimbo
<ronl...@microsoft.com> wrote:
>There are a lot of Unix and Linux developers that hate Microsoft for all
>kinds of reasons. Including the fact that we charge a license fee, that we
>don't distribute source code for all our products and that we certainly
>don't release it under GPL.
These are non-compiler issues at best, but a shame they do get added
to compiler discussions. Still wouldn't mind the version of the
windows source to re-compile for P3 only. A P3-only version of the NT
kernel would be lovely if possible, but I'm dreaming here...
>And we do not produce a multiplatform C++
>compiler, we produce a C++ compiler for the Windows platforms only.
Which is starting to be an un-truth these days. You're starting to
branch-out in other platforms, and who-knows where you'll be going
once VC7 ships. Windows CE (in very many different guises), Console
development (Dreamcast and XBox), specilised platforms(Embedded CE/NT
and OEM versions of windows like data center). Yes, they've all got a
injection of windows to some degree, but they're as cross-platform as
you're getting at the mo. Wouldn't it be a million-times better if
you could make such lines as:
#if MSC < 12
...
#endif
as obsolete as possible. This has impeeded slightly in the past, and
as time goes on, can only be made worse if the C++ compiler doesn't
move-on.
One day, when the managers of the VC team let you, you could produce a
compiler that would be stunning (6 IDE already is), and source could
be ported with the minimal of fuss, you'll get a virtual
"big-sloppy-kiss" from me and you'll also make a huge group of people
"shut-the-fuck-up" at last.
Isn't that worth anything these days ?
[Knowing managers, probably not, but they don't count :)]
Ta ra,
Tomas Restrepo
>
> Can you elaborate a little more on what you mean by this (bipolar C++
> world)?
and those who don't. And sadly, the last group is bigger than we think.
> And Ronald I can tell you that you have got it quite wrong as to how many
> people want Std C++.
Yep,many people want it. I like the idea of having the survey up on the VC++
page, it would be nice.
Frankly, I've never been asked in any of those surveys, but it's no wonder.
What are the odds?
However, I also look back at the VC++ newsgroups and see just how many of
those users don't know crapp about the standard and much less care. They are
happy with just getting their code to compile and run. It's a sad state of
affairs, but hey, who said the world was fair? :)
>
> And IMHO backwards compatibility should not hold a great product to ransom
> against implementing new features.
Agreed and that might be happening to a certain degree here. However, I also
understand why MS treads so lightly when it involves the C++ compiler:
1- The entire company depends on having that C++ compiler work. They could
make it as compliant as they want, but if it breaks up half the company's
code base they're screwed. That's gotta be a priority issue on this.
2- The whole "MS can devote all the resources they want" fallacy. MS can put
all the money it wants unto this, but the reality of it is that finding good
compiler writers is not easy, much less when it involves something as
complex as the C++ standard. And MS current public image doesn't help,
either. Just look at how many jobs have been opened on the VC++ compiler
team for the last few months (although I see they've filled at least a
couple!)
All said, I have to admit that I, for one, would love for VC++ to be more
compliant, and I'm quite happy with the improvements we have so far. I'd
love for MS to consider improving the build tools in service packs! That
would be a great help in this issue, and would probably helps MS' image on
the C++ world somewhat.
--
Tomas Restrepo [VC++ MVP]
tom...@mvps.org
http://www.mvps.org/windev/
Shiv Shankar Ramakrishnan
> windows source to re-compile for P3 only. A P3-only version of the NT
> kernel would be lovely if possible, but I'm dreaming here...
Maybe not :) Ever poked around the Whistler (Windows XP) a.k.a NT 5.1
binaries to see what they have been compiled with? Surprise surprise: VC7!
(Or so it seems) ntoskrnl.exe hal.dll and everything else seem to have been
compiled by VC7. And VC7 has explicit support for MMX/SSE/3D!NOW et al. It
has also much better code optimizations for both speed and space (from what
I've seen and this is still Beta). Plus whole program optimizations. I have
seen some benchmarks on sites where WinXP runs a lot faster than Win2K on
cpu dependent benchmarks. As it is the minimum requirements for recent
Windows are Pentium. Most definitely XP is optimized of Pentiums. Now who
knows they might have a P3 version also up their sleeve somewhere. Maybe for
the server versions of XP? :)
> once VC7 ships. Windows CE (in very many different guises), Console
> development (Dreamcast and XBox), specilised platforms(Embedded CE/NT
> and OEM versions of windows like data center). Yes, they've all got a
Any idea if the basic code gen quality of VC++ is as good on all those
platforms as of VC++ on x86? After all MS has most experience with x86 and
have also influenced the development of x86 to a degree.
> One day, when the managers of the VC team let you, you could produce a
> compiler that would be stunning (6 IDE already is), and source could
> be ported with the minimal of fuss, you'll get a virtual
> "big-sloppy-kiss" from me and you'll also make a huge group of people
> "shut-the-fuck-up" at last.
> Isn't that worth anything these days ?
Right said! I'd quite agree with you on that. Why does the VC++ team let
itself be shown in such a bad light?!
> [Knowing managers, probably not, but they don't count :)]
I hope you realise that Ronald is a program manager for VC++ ;)
Thanks,
Shiv
Jimbo
<Sh...@pspl.co.in> wrote:
>> to compiler discussions. Still wouldn't mind the version of the
>> windows source to re-compile for P3 only. A P3-only version of the NT
>> kernel would be lovely if possible, but I'm dreaming here...
>
>Maybe not :) Ever poked around the Whistler (Windows XP) a.k.a NT 5.1
>binaries to see what they have been compiled with? Surprise surprise: VC7!
Up until about 2 weeks ago, I'd have been more suprised, but
somethings came to light, and I suspect MS use VC7 internally for any
new stuff that needs the grunt of a brand-spanking new optimiser.
>(Or so it seems) ntoskrnl.exe hal.dll and everything else seem to have been
>compiled by VC7. And VC7 has explicit support for MMX/SSE/3D!NOW et al.
Nice. I'm waiting for Beta 2 or a sacrificial-goat PC to install beta
1 on. Can't wait though, but I might have a few months shell-shock
about the IDE :)
>As it is the minimum requirements for recent Windows are Pentium.
9x was a 386
NT4 was a 486
NT5 was a P1
>Most definitely XP is optimized of Pentiums.
Isn't it a 64-bit addressing system. Can't see XP being released for
a bog-standard P1 or P2, although I could be wrong. Needs a 64-bit
chip doesn't it ? ergo why compile the OS with anything less than the
chip's timings ?
>> once VC7 ships. Windows CE (in very many different guises), Console
>> development (Dreamcast and XBox), specilised platforms(Embedded CE/NT
>> and OEM versions of windows like data center). Yes, they've all got a
>
>Any idea if the basic code gen quality of VC++ is as good on all those
>platforms as of VC++ on x86 ?
I know NT embedded is x86 based, and is very similar to basic win 32.
The OS is a bit better at real-time stuff, but it could be very
differing hardware.
CE is used in many (very many) differing platforms, with/without
screens + lots of different core CPUs supported and hardware doesn't
have that many restrictions. I couldn't judge (or learn the time to..
) the code quality as I needed to get things working on 3 or 4 cpu
archetectures.
It got tricky when you want to re-use code for desktop Win32 as well
as finding differences between platforms. Granted, there are and have
been a few bugs, but they did release 3 new compilers, then another 2,
2 years after (refining the first 3). Now another year after that,
another set of compiler revisions and a core OS optimisation + a top
knotch cut/paste job of VC and VB IDE's and things seem very rosey in
CE land.
Don't know much about the other platforms.
>After all MS has most experience with x86 and
>have also influenced the development of x86 to a degree.
It's still nice to see the LIM aggreement hasn't been completely
fragmented yet :) But I would have enjoyed a LMM a lot more.
>> One day, when the managers of the VC team let you, you could produce a
>> compiler that would be stunning ... etc
>>
>> [Knowing managers, probably not, but they don't count :)]
>
>I hope you realise that Ronald is a program manager for VC++ ;)
I used the wrong words here, probably should have said the VC funding
managers, or Ronald's bosses.
Paul Mensonides
"Ronald Laeremans [MSFT]" wrote...
: Can you explain why that would be? You use the managed extensions when
: targetting .Net. The compliance work we do is completely unrelated to that.
I'm not talking about .Net extensions, I'm talking about current and VC7 standard compatibility issues.
: Because that is one of the hard things to do, we need to make object model
: changes that will have link-time effects. Working trough these issues and
: making sure we catch all the corner cases is what is hard.
Object model changes to native C++ code or .Net? The C++ object model is fairly straight forward.
: There is no (zero, 0) compiler out there that fully support the standard.
: Sicne the decision was made not to have s standards certification process,
: in all likelyhood there never will be one. The fact that we (in the C++
: standards comitee sense) are currently working on a defect report will make
: that even more true. We do intend to be one of the compilers that is
: "substantially compliant". As a very simple internal goal we have that we
: will be able to compile all the libraries that use modern, completely
: template-based code lie POOMA, Blitz and libraries based on Todd
: Veldhuizen's expression template library. In addition we are targetting the
: BOOST libraries with VC workaround removed and removal of the few
: workarounds we currently have in our STL implementation. Since I don't pay
: the bills here, I can't make you a promise that I can keep, but I am willing
: to bet you a couple of microbrews in a bar in Seattle that we will meet that
: goal for the next version.
What about the so-called stated goal of being "fully standard compliant"?
I don't doubt that you are trying hard to bring certain libraries into VC++, but if you made a standard compliant compiler
(extensions notwithstanding), people would write libraries where core operations where standard compliant and easier to port to new
systems.
: > On a side note, why don't you send out new/corrected features through
: patches or service packs? Instead, just for VC++ 7 we've had
: > to wait years--all the while piling up bad-coded workarounds. If you did
: this, and you corrected or implemented one standard C++
: > feature that you don't have now (or don't have correct now) every 3 months
: or so, and you you released it as a patch or the like,
: > I'd quit complaining because I'd actually BELIEVE that MS gives a crap
: about the standard and is seriously heading towards
: > compliance. You are right, C++ is becoming more and more bipolar--there
: is the C++ committee that actually believes in the point of
: > C++, and there is Microsoft which is doing its best to take C++ in the
: complete opposite direction. C++ is supposed to be a
: > close-to-the-hardware, efficient, low-level programming language--not a
: code generator (i.e. [attributes], .NET, garbage collection,
: > managed execution, etc.). Microsoft should have concentrated that effort
: soley into a new language (like C#, for instance), and
: > later, after they actually had a C++ compiler, they could integrate that
: stuff as extensions to it.
: It is an enticing concept to try and decouple ship cycles for command-line
: development tools and the big ship vehicle that Visual Studio is. Apart from
: some serious issue (e.g. there are quite a few things the debugger engine
: needs to be made aware of when adding features) That however is far from
: simple and again I will state (and I guess again you will say I have the
: numbers incorrect<g>) that the majority of the customers I talked to do not
: want to go trough the hassle and use a new compiler every 6 months or so.
VC++ 6 doesn't support this:
template<class T> class X {
public:
template<class T2> void func(const T2& t2) { /*...*/ }
};
I don't think this is supported in VC++7 (though I could be wrong). So say that you made a workaround:
template<class T> class X {
friend template<class T1, class T2> void func(X<T1>* _this, const T2& t2);
};
template<class T1, class T2> void func(X<T1>* _this, const T2& t2) {
// ...
}
Obviously, this is inelegant and (on a larger scale) is difficult to maintain. Say VC++8 then supports the first example. That
doesn't make the second invalid, however the second could be modified, if desired, to be more intuitive and clean.
So say instead that you release a patch after the release of VC++7 that enables this. Fix the debugger to accept this etc.
Templates are more a less a matter of parsing anyway. You could prescan the .cpp files and get rid of templates all together before
they hit the 'true' compiler--why is that so hard?
: Most of them want critical bug fixes and no semantic changes whatsoever for
: service packs. If we were to add new features into service packs a lot of
: customer IT organizations would treat them as new releases and go trough a
: 3-12 month evaluation period before allowing their developers to use them.
So? If in a organization is using VC++7 SP1 and you release VC++7 SP2 with new features, they can continue to use SP1 for as long
as they like. I think the real issue here is that MS wants to 'save up' features that you could implement so that you can extend
the sales of a new version. Give that, if you released VC++7 (and I bought it), and then one month later released VC++8 (which was
fully compliant), I turn around and spend the $500 or whatever and buy the 'new' copy again.
: Regardless, we are indeed investigating if we can do anything in this area.
:
: -Ronald-
Paul Mensonides
Dima Pasechnik
leav...@home.com op 24-03-2001 19:40:
>
> VC++ 6 doesn't support this:
>
> template<class T> class X {
> public:
> template<class T2> void func(const T2& t2) { /*...*/ }
>
> };
>
(perhaps it wasn't there in the first releases of VC6 STL, but still, this
works) and it works.
Dmitrii.
Paul Mensonides
: Hi Andrew,
:
: Does your statement mean that you are not interested in anything besides the
: command line build tools (not the IDE, debugger, project system), and of
: those not even in optimizations work we did for this version. In addition it
: has been getting quite hard recently to write fully fledged windows
: solutions without using COM (shell integration, manageability, DirectX, all
: the recent database APIs are COM).
:
: I am just trying to understand what you find important in a development
: tool, and I am not sure I have a good idea from your post quoted below.
Amazingly enough, some people have brains and don't have a big problem using COM.
Solution to the problem:
#define I_AM_A_DUMBASS // enable MS extentions to do all the COM work for you (so you'll never understand it)
[My COM Object] // <-------- managed extension
class X { /*... */ };
Seriously though, none of the following are the problem: IDE, debugger, project system, MFC, ATL, .NET, and other proprietary
extensions. The problem is lack of conformance to Standard C++, which is an ANSI/ISO world-wide standard! I hope that some day I
(accidentally) buy a car that uses non ISO standard threading on all the screws, and that some day I have to replace all of them.
That way, I can buy a new set of ~100 screws from some other manufacturer for $20,000 because the original manufactures were a bunch
of dumb-asses that went out of business because they couldn't (or wouldn't, as the case may be) conform to a GLOBAL STANDARD of
screw threading.
Paul Mensonides
Shiv Shankar Ramakrishnan
> 9x was a 386
> NT4 was a 486
> NT5 was a P1
<Nitpick>
Some corrections to the above.
For 9x it goes like this: 386 for Win95, 486 for Win98, P/150 for WinMe and
PII/300 for WinMe with multimedia razzmatazz like movie maker. </Nitpick> :)
And according to 'WinXP Beta 2' news today, MS wants PIII minimum, although
I'll wager that even a PII will work. So I guess they can now easily
optimize XP for PIII (at least for servers). They have the compiler and the
OS requirements now to do it.
> Isn't it a 64-bit addressing system. Can't see XP being released for
> a bog-standard P1 or P2, although I could be wrong. Needs a 64-bit
> chip doesn't it ? ergo why compile the OS with anything less than the
> chip's timings ?
Oh No! WinXP is going to be available in 2 flavours. Win32 and Win64. It is
the WinXP 64 bit that can take advantage of the 64 bit addressing. XP
doesn't need a 64 bit chip. WinXP 64 bit does though (obviously). Win64 runs
Win32 as another WOW (Windows on Windows) subsystem called WOW64. Basically
that takes advantage of the 32 compatibility mode of IA-64, a la the v86
mode for 16 bit in 32 bit 386+. And don't worry the NT code base is now such
that you can recompile most things easily for 32 or 64 bit. Has been so in
*NIX world for some time now.
> It's still nice to see the LIM aggreement hasn't been completely
> fragmented yet :) But I would have enjoyed a LMM a lot more.
I'm guessing the 2nd M is but of course Motorola :) x86 surviving this long
is quite amazing. And now AMD wants to extend it to 64 bit land with x86-64
and all! You know what? In the late 80's Intel was making a super duper
modern OO like CPU. Something very ambitious that took ages. When the chip
was nearing completion it was quite obvious it would be a failure. So the
8086 design was hacked up by an Intel engineer in some months. The rest is
history. And now I have an eery feeling that history repeats. Itanium is
late and is rumoured by some to have problems. And AMD extends x86 to 64 bit
and even MS is taking them seriously (So is Sun!!). Sounds familiar?! Lets
just hope as hell Itanium/IA-64 is not a dodo or well be stuck with x86 for
the rest of our lives :)
> I used the wrong words here, probably should have said the VC funding
> managers, or Ronald's bosses.
One never hears about the top brass VC or VS. Wonder who would that be?
Thanks,
Shiv
Jeff Peil
> Seriously though, none of the following are the problem: IDE, debugger,
project system, MFC, ATL, .NET, and other proprietary
> extensions. The problem is lack of conformance to Standard C++, which is
an ANSI/ISO world-wide standard!
Certainly there are implementations that are closer to conformance than VC6,
but I don't think you'll ever find a fully complaint compiler, and you
certainly won't find one today. It's also worth considering, historically,
different international standards that can come into conflict (POSIX C
library requirements that conflicted from the ISO/ANSI C requirements come
to mind as one example.)
Mere conformance to one standard over another (such as ARM C++, which
Stroustrup even once called "as close to a standard as C++ will ever come"
vs ANSI/ISO C++) is itself of little value. Instead the value for that
conformance comes with industry adoption (portability of knowledge, code,
etc.) I think you side-stepped the real question Ronald was trying to ask.
Which is closer to "what are your priorities in selecting a C++ development
tool, and why are they that way?" I'm sure it's far more useful for Ronald
to know *why* something is important to you, than to simply be told that it
is important (that way he can better judge and represent you in decisions
related to deciding development priorities.)
> I hope that some day I
> (accidentally) buy a car that uses non ISO standard threading on all the
screws, and that some day I have to replace all of them.
> That way, I can buy a new set of ~100 screws from some other manufacturer
for $20,000 because the original manufactures were a bunch
> of dumb-asses that went out of business because they couldn't (or
wouldn't, as the case may be) conform to a GLOBAL STANDARD of
> screw threading.
This analogy really falls short when you analyze the differences in the
types of standards. At this point, there are portions of the C++ standard
where the wording is such that the exact behavior requirements are unclear.
As long as there are issues where the standard's requirements are unclear
with multiple possible meanings, I don't think you can have a strictly
conforming implementation (which is why the standard's committee has defect
reports.)
It's also worth considering that even without using any proprietary
extensions, your C++ code can be depending on compiler specific details
(intentionally or unintentionally.) Consider the optimizations related to
temporary objects that are possible, the rules regarding order of execution
as they relate to sequence points, and so on.
Don't get me wrong, I think there are a lot of good reasons for VC++ to
become more standard compliant, I just don't think that conformance itself
is meaningful without more specific reasons (such needing to maintain a
cross platform codebase with isolated platform-dependent peices managing
things like UI.)
Matt Osborn
language idioms are to be effectively deployed. It is on this issue that
Microsoft's VC++ is failing its developer community. We cannot adopt
generative programming techniques because they are not sufficiently
supported.
You are asking a class of developers, who have for the most part, little or
no experience with generative programming, why they need certain language
facilities. I posit that we are not able to justify our needs because we
haven't had an opportunity to learn, work with and deploy such techniques.
This "don't break code" mantra is a relatively new phenomenon for Microsoft,
with which frankly, I'm less than satisfied. If your old complier built
that code, your new complier can too. Just add a /V60 switch or some such
for those who don't wish to progress.
In summary, by not delivering a fully compliant C++ compiler, Microsoft is
effectively capturing all those who develop for Microsoft platforms into
Microsoft developers. Those of us who are so trapped are not able to
improve our skill set.
"Ronald Laeremans [MSFT]" <ronl...@microsoft.com> wrote in message
news:OSQm1zAtAHA.2224@tkmsftngp03...
> Hi Andrew,
andrew queisser
I like the IDE and the debugger although I've been using VC almost
exclusively
for years so I don't have much comparison as to where VC stands in relation
to
its competition.
The project system seems ok even though sometimes a straight makefile would
be easier to use and quite sufficient for my purposes.
I can't comment about the optimizations - I haven't looked at the assembly
output
in a while but from what I read in comparison tests there isn't a huge
difference.
Also, the code I write benefits most from DSP-style inner loop optimization
so
it's almost unreasonable to expect a huge performance boost from the
optimizer -
it's more what the library vendors have done on their side.
Now to the MS-specific issues:
Yes, it has been getting difficult to write apps outside of the latest MS
technology
but my point is that I don't care whether the interaction with the outside
world
is through COM or whatever. As long as I don't have to code in VB I'll use
whatever is available to build the overall application. But in my world it
would be
perfectly acceptable to write the framework in a public domain environment
such
as wx or anything else.
What I DO care about is what is available to me to fill in the blank areas
in the
framework generated by Class/AppLizard. I want to be able to write my
image processing routines in standard C++ without worrying whether I need
some
ugly workaround to get it running.
Andrew
"Ronald Laeremans [MSFT]" <ronl...@microsoft.com> wrote in message
news:OSQm1zAtAHA.2224@tkmsftngp03...
Bo Persson
"Jeff Peil" <jp...@bigfoot.com> skrev i meddelandet
news:#KtIOgetAHA.1752@tkmsftngp05...
>
> "Paul Mensonides" <leav...@home.com> wrote in message
> news:OfLQCbctAHA.504@tkmsftngp05...
> > Seriously though, none of the following are the problem: IDE, debugger,
> project system, MFC, ATL, .NET, and other proprietary
> > extensions. The problem is lack of conformance to Standard C++, which
is
> an ANSI/ISO world-wide standard!
>
> Certainly there are implementations that are closer to conformance than
VC6,
> but I don't think you'll ever find a fully complaint compiler, and you
> certainly won't find one today. It's also worth considering,
historically,
> different international standards that can come into conflict (POSIX C
> library requirements that conflicted from the ISO/ANSI C requirements come
> to mind as one example.)
>
> Mere conformance to one standard over another (such as ARM C++, which
> Stroustrup even once called "as close to a standard as C++ will ever come"
> vs ANSI/ISO C++) is itself of little value.
Ok, so even Stroustrup can be wrong sometimes :-)
The ANSI/ISO standard is not *one* standard, but *the* standard. There is
only one!
> Instead the value for that
> conformance comes with industry adoption (portability of knowledge, code,
> etc.) I think you side-stepped the real question Ronald was trying to
ask.
> Which is closer to "what are your priorities in selecting a C++
development
> tool, and why are they that way?" I'm sure it's far more useful for
Ronald
> to know *why* something is important to you, than to simply be told that
it
> is important (that way he can better judge and represent you in decisions
> related to deciding development priorities.)
>
A large part of the standard document contains specifications for the
standard library. A compiler that is only *slightly* compliant should at
least be able to compile most of the header files in the library chapters.
These specifications were available already in 1997 and, after a 1 year
review period, accepted as The Standard in late 1998. So there has been
plenty of time to try to implement the following piece of code, which is the
basis of the template library:
// [lib.iterator.synopsis] 24.2 Header <iterator> synopsis
namespace std {
// 24.3, primitives:
template<class Iterator> struct iterator_traits;
template<class T> struct iterator_traits<T*>;
...
Here VC++ failes already 2 lines down in the standard header <iterator>.
Makes it kind of hard to use that part of the standard :-(((
Bo Persson
b...@malmo.mail.telia.com
Tomas Restrepo
> Just add a /V60 switch or some such
> for those who don't wish to progress.
Just for the sake of it, I have to say here that, although I fully
understand your comments and I find myself constantly wishing for better
support on the compiler side for C++ standards, what you're asking is not
completely reasonable.
Things are not so simple as just "adding a /V60" switch, it is *far* more
complicated. In fact, I think that if MS actually had to deliver on such an
issue without actually resorting to shipping multple versions of the
compiler, the schedule for the compiler development could easily double.
It's a hard thing to do, especially if you take into account all the
resources necessary for proper testing, etc, and the fact that a modern C++
compiler is copmplex enough that adding support new for C++ constructs is
likely to break older code. As a simple example, consider the impact of
changes that affect the lookup order.
Michael Viking
issues, etc. I just have such a hard time believing it. Here are some
things I believe to be true:
1. You admit that extensions were more important than standards compliance
for version 7.
2. It's been more than two years since the last version of VC.
3. The C++ User Journal review that I saw did not say good things about VC.
What I saw implied that VC stunk. Here's what MS had to say about their
stinkiness (and please not that it says standards compliance is key and that
MS sure wishes CUJ had used the VC7 beta instead of the VC6 version. MS
implies that they would have done a lot better job if CUJ would have used
the later stuff. That's surprising given that you admittedly are going to
aggressively work on the standard for next version, version 8, coming to a
place near you in when? 2003-4? and that VC7's focus was managed code
stuff.
start quote from CUJ site http://www.cuj.com/roundup/a.htm
Microsoft
At Microsoft, we take the C++ language and the ISO Standard very seriously.
Visual C++ is used daily by over 1.2 million developers worldwide, and is
the most extensively used development language within the company.
Our new C++ compiler is substantially closer to compliance with the ISO
Standard than the Visual C++ 6.0 one. Unfortunately, the terms of the review
precluded consideration of the latest version, and was based on a compiler
released three years ago. [This review was limited to shipping, or at most
late-beta, products. We're looking forward to including the new .NET version
in next year's roundup! - hps.]
The latest Visual C++ compiler in Visual Studio.NET includes
a.. covariant return types
b.. additional template support
c.. in-class initialization of static integral data members
d.. correct for-loop scoping
e.. the C Standard library in the std namespace, and
f.. function-try blocks.
These new features are available today. Please see
http://msdn.microsoft.com/vstudio/nextgen/beta.asp for more details of the
beta-1 release of Visual Studio.NET.
Our commitment to ISO compliance is underscored by our partnership with
Dinkumware, Ltd. (http://www.dinkumware.com). This will ensure that the
version of the C++ Standard Template Library in Visual Studio.NET will be an
extremely compliant and robust implementation.
It is a stated goal of the Visual C++ team to produce a fully ISO-compliant
compiler, and this goal continues to guide all current and future
development.
end quote from CUJ site
I especially like the last business about how it's your stated goal to
produce a fully ISO-compliant compiler.
Yeah RIGHT! Poppycock.
-Michael Viking
"Ronald Laeremans [MSFT]" <ronl...@microsoft.com> wrote in message
news:u5pMHb#sAHA.2124@tkmsftngp05...
Michael Viking
where their standards compliance was tested.
a.. covariant return types
b.. additional template support
c.. in-class initialization of static integral data members
d.. correct for-loop scoping
e.. the C Standard library in the std namespace, and
f.. function-try blocks.
think they've done a lot in the last few years. I bet most of the time was
spent working on getting the C standard library in the std namespace. That
seems like an overwhelming task all by itself.
-Michael Viking
"Zachary Turner" <ztu...@bindview.com> wrote in message
news:uPyGYD7sAHA.2216@tkmsftngp03...
Tomas Restrepo
> I don't know...it doesn't look like way more than 4 to me...
Yep, it doesn't sound as much, but consider for example that "additional
template support" includes template template parameters, which are a big
deal, imho, at least for my work.
Also, they actually fixed a lot of bugs in VC++ 6.0, and, although
impossible to mention one by one, it's pretty important in getting
complaince, too.
Of course, they still have a long way to go...
--
Tomas Restrepo
tom...@mvps.org
Ronald Laeremans [MSFT]
Thanks for this clarification.
That is exactly what I am offering. We will do the work to make the next
version of the compiler be able to successfully compile the kind of code
that is in the libraries I mention (including the expression template-based
ones). That is about as much as I can do. If you have other concrete
libraries that you want us to consider for testing, that is fine. or:
IF YOU WANT TO WORK WITH US ON EARLY VERSIONS OF THE NEXT COMPILER, HAVE
CODE THAT YOU THINK IS CHALLENGING, AND CARE ENOUGH, SEND ME AN EMAIL AND
I'LL WORK WITH YOU WHEN THE TIME COMES!!
But everyone asking for a "fully compliant compiler", because that is the
only thing that will do, are living in a dream world.
-Ronald-
"andrew queisser" <andrew_...@hp.com> wrote in message
news:uY$FPHhtAHA.1372@tkmsftngp04...
> No, I wasn't very clear, thanks for asking.
Ronald Laeremans [MSFT]
"Shiv Shankar Ramakrishnan" <Sh...@pspl.co.in> wrote in message
news:OK9AC2DtAHA.2216@tkmsftngp03...
> > template error messages and in now shipping the STL implementation that
> > was very recently judged best in the C++ User Journal review. Those 2
>
> In case people are wondering about this, here is the link -
> http://www.cuj.com/roundup/index.htm
>
> > I really feel that the C++ world is getting more and more bipolar. A
quick
> > look at a book like Generative Programming is one shows one end of the
> > spectrum. Reading the survey replies of our C++ customers, talking to
>
> Can you elaborate a little more on what you mean by this (bipolar C++
> world)? Do you mean the VC++ and Windows world Vs. other C++ and *NIX
world?
> Or do you mean the leave C++ as is world Vs. the I want Std C++ world? Or
> the conservative C++ users (for whatever reasons) Vs. the bleeding edge
C++
> users world? Or the Java/C#/.Net/Other GC-lang loving world Vs. the native
> bare metal C/C++ world? Yeah yeah too many of those :)
No, I mean that a small subset of people are using C++ in very exiting and
complicated ways (like generative programming). Whereas a very large
majority has extreme problem even getting the the level of understanding of
C++ as say Scott Meyers' Effective C++ and More Effective C++ books.
...
> And IMHO backwards compatibility should not hold a great product to ransom
> against implementing new features. And MS has in the past introduced great
> new features and still maintain backward compatibility. An excellent
example
> is Windows NT. So is SQL Server 7.0. They even managed to convince god
knows
> how many customers to convert all thier critical RDBMS data in SQL 6.5 to
> the immensly improved SQL 7.0 format. (Yes I know a thing or two about SQL
> Server 7.0 ;) So why is the Visual C++ team so afraid of coaxing users to
> new features and educating them about some breakeages. Why, isn't that
what
> you are doing in VS.NET for Java with the "JUMP to .NET" program?! ;)
Because that flies in the face of what our customers, including several of
our most major customers, have told us in extremely strong terms. We are
going to do the compliance work and we are going to spend a lot of effort to
absolutely minimize breaking code, certainly in silent or subtle ways. I was
only trying to illustrate that this concern is part of the reason we weren't
able to do everything we wanted for VC 7.0. BTW, did you ever see the number
of backwards compatibility flags you can give recent SQL Server versions,
getting all of that to work took quite a bit of effort. And that is without
the complexity of people needing to be able to link already compiled old
code with newly compiled code.
-Ronald-
Ronald Laeremans [MSFT]
"Michael Viking" <TheV...@sweden.se> wrote in message
news:eAVqNeitAHA.1396@tkmsftngp05...
> Thanks for the response. When you say that you're interested in
compliance
> issues, etc. I just have such a hard time believing it. Here are some
> things I believe to be true:
> 1. You admit that extensions were more important than standards
compliance
> for version 7.
Yes, not having C++ die a slow death on Microsoft platforms if .Net becomes
successful was a major deal for the C++ team. Making sure people could
leverage the investment the made in writing C++ code on the Windows platform
was another very major deal.
If you couldn't care less, that is fine by me, but I fail to see why you
don't seem to want to understand the issue.
> 2. It's been more than two years since the last version of VC.
Yes?
> 3. The C++ User Journal review that I saw did not say good things about
VC.
> What I saw implied that VC stunk. Here's what MS had to say about their
> stinkiness (and please not that it says standards compliance is key and
that
> MS sure wishes CUJ had used the VC7 beta instead of the VC6 version. MS
> implies that they would have done a lot better job if CUJ would have used
> the later stuff. That's surprising given that you admittedly are going to
> aggressively work on the standard for next version, version 8, coming to a
> place near you in when? 2003-4? and that VC7's focus was managed code
> stuff.
I don't know whether you read the review all that carefully. It clearly
stated that it was purely focussed on language compliance issues, and for
those on a narrow subset that consisted of what readers had found lacking in
the previous versions of most mainstream compilers. I feel that
extrapolating that to "VC stunk" quite extreme.
-Ronald-
Jeff Peil
"Bo Persson" <b...@malmo.mail.telia.com> wrote in message
news:#f3$o3htAHA.2156@tkmsftngp05...
> Ok, so even Stroustrup can be wrong sometimes :-)
>
> The ANSI/ISO standard is not *one* standard, but *the* standard. There is
> only one!
Hardly true. The ARM was generally considered "the standard" prior to the
C++ standardization effort. Had the industry decided that the standard
produced was far worse than the ARM, odds are good that the ARM would've
remained the defining standard for users and implementors. It is a credit
to the people on the standardization committee that they put great effort
into ensuring this sort of split did not happen.
> A large part of the standard document contains specifications for the
> standard library. A compiler that is only *slightly* compliant should at
> least be able to compile most of the header files in the library chapters.
I'm not sure I agree with you here. For example, a freestanding
implementation has very few headers it needs to include. I'd also point out
that some portions of the STL put a fair amount of stress on template
support. It's also worth noting that the standard does not strictly require
those definitions (for example it is legal for default arguments to be added
to the tail of the functions defined in those headers.)
If the issue is with support for using the STL, I'd argue that the VC7
version of the STL is quite good from a usage perspective. If the issue is
with implementing idioms similar to those described in this part of the
standard, then I suggest you say that directly.
> Here VC++ failes already 2 lines down in the standard header <iterator>.
> Makes it kind of hard to use that part of the standard :-(((
Which part do you mean? #include <iterator> or partial template
specialization? The included version of <iterator> includes workarounds and
is quite functional, even though partial template specialization support is
not available.
Paul Mensonides
:
: "Bo Persson" <b...@malmo.mail.telia.com> wrote in message
: news:#f3$o3htAHA.2156@tkmsftngp05...
: > Ok, so even Stroustrup can be wrong sometimes :-)
: >
: > The ANSI/ISO standard is not *one* standard, but *the* standard. There is
: > only one!
:
: Hardly true. The ARM was generally considered "the standard" prior to the
: C++ standardization effort. Had the industry decided that the standard
: produced was far worse than the ARM, odds are good that the ARM would've
: remained the defining standard for users and implementors. It is a credit
: to the people on the standardization committee that they put great effort
: into ensuring this sort of split did not happen.
The ARM was used as the base document for the standardization effort. The standards effort is fully supported by Bjarne Stroustrup
(the creator of C++, the co-author of the ARM, and the author of "The C++ Programming Language"). Where exactly is your logic here?
What is the purpose of a standard? To give users something to rely on...to give implementers a guideline and goal...to guarantee
that some bit of code will be platform independent...etc....etc.. MS wants users to rely ONLY on MS. MS doesn't like everything
the standard's committee has done (which a representative from MS has a vote) so the go do their own thing anyway. MS doesn't not
want code to platform independent. etc. etc. As far as a split goes...what do you think that we have now? MS C++ (with managed
extensions, attributed code, MFC, ATL, and a bunch of other 'extensions.') vs. Borland C++ (with VCL, MS copy-cat extensions) vs.
IBM C++ (who now only supports AIX (conveniently their own OS)) vs. Comeau & EDG which is actually trying hard for compliance but
they still have a huge amount of 'options' to try to make VC++ legacy code still work, etc., etc.. The split HAS happened, and MS
(being MS) doesn't give a shit about the purpose of the standard (only about what their 'supposed' users want) when they could
EASILY do both. <- and don't give me this shit that re-writing the compiler and debugger (etc) from SCRATCH could not be done
within a year given knowledgeable staff and funding (which MS has in surplus--they could stop fiddling around with crap like video
game consoles, for instance). I say 'supposed' users because MS hears only what it wants to hear: "COM is to hard for me." + "Using
APIs is to hard for me." + "We'll use whatever you give us...." Someone commented on me avoiding answering a question? Why is
standard comformance important? Because features in the standard are USEFUL but unavailable. Because there are thousands of books
on Standard C++ and thousands more on MS C++, and I don't want to buy 300 books to find the answer to a stupid question. I've said
this before over and over and over (and so have a great many people). People also want vender libraries to work without extensive
tweaking. Venders want to write platform independent code so they can target more OS's. There are MANY reasons why the standard is
important. The big difference between MS and the ISO committee: MS likes buzz words and C++ is a marketing strategy. The
committee actually CARES ABOUT C++ AND ITS FUTURE. Obviously, you can't get away from marketing issues (business is business, after
all), but you can care about the QUALITY of your product and be PROUD of what you have accomplished--not just in it ENTIRELY for the
money.
: > A large part of the standard document contains specifications for the
: > standard library. A compiler that is only *slightly* compliant should at
: > least be able to compile most of the header files in the library chapters.
:
: I'm not sure I agree with you here. For example, a freestanding
: implementation has very few headers it needs to include. I'd also point out
: that some portions of the STL put a fair amount of stress on template
: support. It's also worth noting that the standard does not strictly require
: those definitions (for example it is legal for default arguments to be added
: to the tail of the functions defined in those headers.)
So? Templates are a glorified preprocessor--they would be EXTREMELY easy to implement for anyone that is reasonably capable of
parsing text. The standard calls some things "implementation dependent." So what? Those things are defined as being
implementation dependent (though they are supposed to be well-documented).
: If the issue is with support for using the STL, I'd argue that the VC7
: version of the STL is quite good from a usage perspective. If the issue is
: with implementing idioms similar to those described in this part of the
: standard, then I suggest you say that directly.
The issue is not whether or not something can be done with VC++. The issue is whether something can be done better (in a
standardized and long term fashion). MS makes decisions based on the current buzz word. The standard committee deliberates over
things for long periods of time with test examples and representatives from all over the industry. They make sure as the possibly
can that only something GOOD is added to C++. The STL is useful, but not the end all and be all--it is only a 'standard' library.
But if the idioms, as you call it, were available in VC++, then the STL could actually be defined and implemented correctly. But
that is NOT THE ONLY THING. The whole generative programming issue/paradigm is important--especially for future reuse. Example:
class ILinkable {
public:
virtual void Previous(ILinkable* previous) = 0;
virtual void Next(ILinkable* next) = 0;
};
template<class T> class Collection {
private:
//...
public:
template<class T2> void Add(T2* element) {
// add an element of type T2 to the collection
return;
}
template<> void Add(ILinkable* linked_element) {
// specialize for linkable types
return;
}
// butt-load of other methods and code...
};
VC++ doesn't support member templates, VC++ doesn't fully support specialization, etc. What this means is I have to do something
illogical:
template<class T> class Collection {
public:
virtual void Add(T* element);
};
template<class T = ILinkable> class Linked_Collection : public Collection<T> {
public:
void Add(ILinkable* element);
};
now, if I want to avoid the virtual call:
#define ALL_SHARED_CODE \
public: \
void PerformOperation(void) { \
...; \
return; \
} \
// etc. etc.
template<class T> class Collection {
private:
//...
ALL_SHARED_CODE:
public:
void Add(T* e) {
//...
}
};
template<class T = ILinkable> class LinkedCollection {
private:
//...
ALL_SHARED_CODE:
public:
void Add(T* e) {
//...
}
};
except a fully implemented example would be A LOT OF THIS KIND OF GARBAGE.
: > Here VC++ failes already 2 lines down in the standard header <iterator>.
: > Makes it kind of hard to use that part of the standard :-(((
:
: Which part do you mean? #include <iterator> or partial template
: specialization? The included version of <iterator> includes workarounds and
: is quite functional, even though partial template specialization support is
: not available.
as above...
Paul Mensonides
Paul Mensonides
"Tomas Restrepo" <tom...@mvps.org> wrote in message news:uwihF4htAHA.1632@tkmsftngp05...
: Things are not so simple as just "adding a /V60" switch, it is *far* more
: complicated. In fact, I think that if MS actually had to deliver on such an
: issue without actually resorting to shipping multple versions of the
: compiler, the schedule for the compiler development could easily double.
: It's a hard thing to do, especially if you take into account all the
: resources necessary for proper testing, etc, and the fact that a modern C++
: compiler is copmplex enough that adding support new for C++ constructs is
: likely to break older code. As a simple example, consider the impact of
: changes that affect the lookup order.
Resources? Microsoft?
"adding support new for C++ constructs is likely to break older code" <- the purpose of a /V60 switch, obviously. The schedule
would double given the current amount of effort that MS is putting into it, yes. But, it could be done.
Paul Mensonides
Tomas Restrepo
> Resources? Microsoft?
yes, resources. Microsoft. Or do you see a line of experienced compiler
writters pounding at MS doors to get hired?
>
> "adding support new for C++ constructs is likely to break older code" <-
the purpose of a /V60 switch, obviously. The schedule
> would double given the current amount of effort that MS is putting into
it, yes. But, it could be done.
Sure, it could be done, but that wouldn't leave us in a better position than
we are now, which is waiiting for the next version to be compliant. Given
your own admision (and mine) that schedule would double, they would come out
around the same time, pretty much.
Paul Mensonides
"Ronald Laeremans [MSFT]" <ronl...@microsoft.com> wrote in message news:u0jon5jtAHA.504@tkmsftngp05...
: Hi Andrew,
:
: Thanks for this clarification.
:
: That is exactly what I am offering. We will do the work to make the next
: version of the compiler be able to successfully compile the kind of code
: that is in the libraries I mention (including the expression template-based
: ones). That is about as much as I can do. If you have other concrete
: libraries that you want us to consider for testing, that is fine. or:
:
: IF YOU WANT TO WORK WITH US ON EARLY VERSIONS OF THE NEXT COMPILER, HAVE
: CODE THAT YOU THINK IS CHALLENGING, AND CARE ENOUGH, SEND ME AN EMAIL AND
: I'LL WORK WITH YOU WHEN THE TIME COMES!!
:
: But everyone asking for a "fully compliant compiler", because that is the
: only thing that will do, are living in a dream world.
:
: -Ronald-
A "fully compliant compiler" is not the ONLY thing that will do, obviously. But a "fully compliant compiler" should be the LEAST
that we can expect. Extensions can be built onto THAT framework.
No, Microsoft is like a gigantic whining baby. If the standard doesn't go their way they throw a tantrum and then go their own way.
Paul Mensonides
Paul Mensonides
"Ronald Laeremans [MSFT]" <ronl...@microsoft.com> wrote in message news:OWXeLBktAHA.504@tkmsftngp05...
: inline.: > 3. The C++ User Journal review that I saw did not say good things about
: VC.
: > What I saw implied that VC stunk. Here's what MS had to say about their
: > stinkiness (and please not that it says standards compliance is key and
: that
: > MS sure wishes CUJ had used the VC7 beta instead of the VC6 version. MS
: > implies that they would have done a lot better job if CUJ would have used
: > the later stuff. That's surprising given that you admittedly are going to
: > aggressively work on the standard for next version, version 8, coming to a
: > place near you in when? 2003-4? and that VC7's focus was managed code
: > stuff.
:
: I don't know whether you read the review all that carefully. It clearly
: stated that it was purely focussed on language compliance issues, and for
: those on a narrow subset that consisted of what readers had found lacking in
: the previous versions of most mainstream compilers. I feel that
: extrapolating that to "VC stunk" quite extreme.
:
: -Ronald-
It wasn't based on a narrow subset. It was based on ANSI/ISO C++. Admittedly, some of the results don't necessarily say "one is
better than another," as the article makes clear. Obviously some things are more important than others (major paradigms, etc.)
which the testing did not take into account. However, that is no excuse. Legacy code is no excuse. .NET is no excuse. You could
have solved ALL of these problems.
Paul Mensonides
Jeff Peil
> The ARM was used as the base document for the standardization effort. The
standards effort is fully supported by Bjarne Stroustrup
> (the creator of C++, the co-author of the ARM, and the author of "The C++
Programming Language"). Where exactly is your logic here?
My point was that telling Ronald "I want standards compliance, just because"
is a lot less persuesive than giving specific reasons why the standard as a
whole is important to you, as well as specific reasons why specific portions
of the standard are more important than others (for example, if you believe
that support for export is more important than partial template
specialization, than you should provide reasons why that is a bigger
priority for you/your company.)
> What is the purpose of a standard? To give users something to rely
on...to give implementers a guideline and goal...to guarantee
> that some bit of code will be platform independent...etc....etc.. MS
wants users to rely ONLY on MS. MS doesn't like everything
> the standard's committee has done (which a representative from MS has a
vote) so the go do their own thing anyway. MS doesn't not
Clearly you didn't follow the standardization process closely, at least for
a time MS lost voting rights due to attendance issues (IIRC if you missed
two meetings in a row, you lost voting rights)
> want code to platform independent. etc. etc. As far as a split
goes...what do you think that we have now? MS C++ (with managed
> extensions, attributed code, MFC, ATL, and a bunch of other 'extensions.')
vs. Borland C++ (with VCL, MS copy-cat extensions) vs.
> IBM C++ (who now only supports AIX (conveniently their own OS)) vs. Comeau
& EDG which is actually trying hard for compliance but
> they still have a huge amount of 'options' to try to make VC++ legacy code
still work, etc., etc.. The split HAS happened, and MS
We clearly have differing perspectives here. I don't think a split has
really happened as no one, as of yet, has become compliant, and every vendor
(some more quickly than others) has made strides towards compliance with the
standard.
> (being MS) doesn't give a shit about the purpose of the standard (only
about what their 'supposed' users want) when they could
> EASILY do both. <- and don't give me this shit that re-writing the
compiler and debugger (etc) from SCRATCH could not be done
That's true of every vendor. If you are creating a product, you want a
product that your users will want to use. Certainly there are users with
priorities other than standards compliance, that's why *no* compiler vendor
devotes all of their resources to conformance (quality of code generation,
compiler speed, and extensions important to the target market all being
likely places where resources get spent.)
> within a year given knowledgeable staff and funding (which MS has in
surplus--they could stop fiddling around with crap like video
> game consoles, for instance). I say 'supposed' users because MS hears
only what it wants to hear: "COM is to hard for me." + "Using
Throwing an unlimited amount of resources at a problem does not necessarily
get the problem solved more quickly. You get diminishing returns as you add
people to a development project.
> APIs is to hard for me." + "We'll use whatever you give us...." Someone
commented on me avoiding answering a question? Why is
> standard comformance important? Because features in the standard are
USEFUL but unavailable. Because there are thousands of books
> on Standard C++ and thousands more on MS C++, and I don't want to buy 300
books to find the answer to a stupid question. I've said
> this before over and over and over (and so have a great many people).
People also want vender libraries to work without extensive
> tweaking. Venders want to write platform independent code so they can
target more OS's. There are MANY reasons why the standard is
> important. The big difference between MS and the ISO committee: MS likes
buzz words and C++ is a marketing strategy. The
> committee actually CARES ABOUT C++ AND ITS FUTURE. Obviously, you can't
get away from marketing issues (business is business, after
> all), but you can care about the QUALITY of your product and be PROUD of
what you have accomplished--not just in it ENTIRELY for the
> money.
Here you do provide some good reasons why standards compliance is important
to you, which was my point. If you want Ronald to present your case
effectively, you should provide reasons why conformance is important to
*you* and *your employer*
> So? Templates are a glorified preprocessor--they would be EXTREMELY easy
to implement for anyone that is reasonably capable of
> parsing text. The standard calls some things "implementation dependent."
So what? Those things are defined as being
> implementation dependent (though they are supposed to be well-documented).
You've clearly not looked at what it takes to completely implement templates
at this point. I suggest you ask some people who have. I'd also point out
that there are a lot of ambiguities around templates in the standard today
(meaning that as a vendor it isn't clear what an implementation is supposed
to do in certain cases, until the standards committee resolves the defect
reports related to these, it isn't really possible to provide a compeltely
correct template imlementation*)
* Of course it is certainly possible to get closer than what VC7 provides
> The issue is not whether or not something can be done with VC++. The
issue is whether something can be done better (in a
> standardized and long term fashion). MS makes decisions based on the
current buzz word. The standard committee deliberates over
> things for long periods of time with test examples and representatives
from all over the industry. They make sure as the possibly
> can that only something GOOD is added to C++. The STL is useful, but not
the end all and be all--it is only a 'standard' library.
> But if the idioms, as you call it, were available in VC++, then the STL
could actually be defined and implemented correctly. But
> that is NOT THE ONLY THING. The whole generative programming
issue/paradigm is important--especially for future reuse. Example:
Again Paul, I never disagreed. My point was and remains that providing
Ronald with a clear list of the issues with reasons why those issues are
important is much more likely to get action than merely saying "you aren't
standards conformant!"
> VC++ doesn't support member templates, VC++ doesn't fully support
specialization, etc. What this means is I have to do something
> illogical:
Just a minor side issue but VC++ 6 does support member templates, it does
not support definitions for them being provided outside the class
definition. For example
extern "C" void puts(const char*);
template <class T> struct S
{
template <class U> U Func(T t, U u) {puts("generic");return (U)t;}
template<> short Func<short>(T t, short u) {puts("specialized");return
(short)t;}
};
int main()
{
S<long> f;
return f.Func(3, (short)0);
}
Jeff Peil
> A "fully compliant compiler" is not the ONLY thing that will do,
obviously. But a "fully compliant compiler" should be the LEAST
> that we can expect. Extensions can be built onto THAT framework.
I doubt that there will ever be a fully compliant C++ compiler. There will
likely be compilers that reach over 99% conformance, and even pass all of
the popular compiler test suites without any failures, but that does not
ensure complete compliance. Certainly I agree with you that the closer
every vendor gets, the better, but to expect a "fully compliant compiler" is
pretty unreasonable (keep in mind that even compiler bugs that cause
crashes/bad codegen do count against compliance, so a prerequisite for a
"fully compliant compiler" is also a nearly bug-free compiler, given the
amount of code needed to implement a C++ compiler this seems pretty
unlikely.)
Paul Mensonides
"Tomas Restrepo" <tom...@mvps.org> wrote in message news:eUfb5hmtAHA.684@tkmsftngp03...
: Hi Paul,
:
: > Resources? Microsoft?
:
: yes, resources. Microsoft. Or do you see a line of experienced compiler
: writters pounding at MS doors to get hired?
Maybe there would be if MS didn't continually try to dumb down programmers with the fully documented "easy-wizard-way" and the very
sparsely documented "harder-underlying-and-principle-learning-way." Things like MFC and ATL (and managed extensions, etc) should be
a useful shortcut for those that already know the underlying principles. However, Microsoft touts these programming styles as the
BEST way for everybody (thereby tying people to the Microsoft platform). The problem lies in a bunch a programmers who are not
complete programmers--they MUST rely on MFC or ATL (etc.) to get the job done because they don't know how to do it any other way.
Compiler writers, on the other hand, are exactly the type of people that should not be platform dependent because they must know the
deep underlying architecture and hardware. MS strongly discourages this kind of knowledge through their use of documentation and
"extensions" that are the end-all-and-be-all way to go. What do you expect? You now have a bunch of idiots programming in C++
instead of VB.
: >
: > "adding support new for C++ constructs is likely to break older code" <-
: the purpose of a /V60 switch, obviously. The schedule
: > would double given the current amount of effort that MS is putting into
: it, yes. But, it could be done.
:
: Sure, it could be done, but that wouldn't leave us in a better position than
: we are now, which is waiiting for the next version to be compliant. Given
: your own admision (and mine) that schedule would double, they would come out
: around the same time, pretty much.
Not if resources were expanded, and Microsoft gave a damn. I respect what you say about making progress in the future. However,
you will likely have a new standard in 2005 (is that when it's slated for?) or so. So you had better hurry just to break even
before the next one hits and you're at day one again. I still don't see why you couldn't parse all these differences away
anyway--unless you're using some generic parser generator that you can't specialize. I do notice a big difference between what the
IDE seems to know about a type or something vs. the compiler and linker. It seems they parse completely independently (I could be
wrong of course, just guessing). However, a parser could turn this:
template<class T> class X {
private:
T* m_T;
public:
template<class T2> void DoSomething(const T2* t2);
};
void f() {
X<int> EX_A;
EX_A.DoSomething(1.0f);
EX_A.DoSomething(100u);
X<float> EX_B;
EX_B.DoSomething(3.14f);
}
// into this...
class X_INT {
private:
int* m_T_INT;
public:
void DoSomething(float t2_FLOAT);
void DoSomething(unsigned t2_UNSIGNED);
};
class X_FLOAT {
private:
float* m_T_FLOAT;
public:
void DoSomething(float t2_FLOAT);
};
void f() {
X_INT EX_A;
EX_A.DoSomething(1.0f);
EX_A.DoSomething(100u);
X_FLOAT EX_B;
EX_B.DoSomething(3.14f);
}
BOY, THAT WOULD SURE BE SOME DIFFICULT PARSING! All that is required is a relatively simple preprocessing before the whole lot is
fed to the compiler.
example 2:
void someFunction(void) throw(int) try {
// code
}
catch(...) {
throw int(0);
}
void g() {
someFunction();
return;
}
// into this:
void someFunction(void) {
// code
}
void someFunctionWrapper(void) throw(int) {
try {
someFunction();
}
catch(...) {
throw int(0);
}
}
void g() {
someFunctionWrapper();
return;
}
example 3:
// X.h
class X {
private:
static int m_integer = 0;
public:
//...
};
into...
// X.h
class X {
private:
static int m_integer;
public:
//...
};
// X.cpp
int X::m_integer = 0;
BOY, THAT'S ALMOST HALF OF THE COMMENTS IN THE CUJ COMPLIANCE TEST RESPONSE FROM MS.
Paul Mensonides
Ronald Laeremans [MSFT]
I am coming to the conclusion that you just want to argument that we are bad
and don't care about developers, just to have the argument. I have offered
you a chance at making sure we address your issues in the next release if
you have relevant knowledge and code to add to the process. I also offered
you to comment on what libraries you suggest us to test conformance and
features against. I have no idea what else I can offer you to improve the
product in the direction we want.
If you just want a compiler that is much more compliant right now and that
works on the Windows platform, you have the choice of several competing
compilers. In my point of view the total package we offer with Visual C++
7.0 is better for the large majority of our customers, and we are trying to
make it better for the remainder as well. If you don't like anything we
offer in VC, I really don't understand why you don't use one of the
alternatives. I like as many people as possible to use the product I work
on, but if what we are good at doesn't interest you at all and what we are
not as good at in the current version as some competitors, is the only thing
you care about, then I think the decision is simple.
For the rest I think your analysis in this mail thread is completely flawed.
E.g. MFC and ATL are libraries, what on earth does offering those have to do
with tying people into the platform or anything. They wrap the Win32 API and
the COM API, both of which could be argued are in practice single platform
(although we do support COM and DCOM on a lot of platforms). Or what does it
have to do with dumbing down programming. Do you argue that we should not
ship any library?
In addition features like attributed programming are NOT restricted to or
even specifically targeted at inexperienced programmers. They are very much
a productivity enhancer for very experienced COM developers as well.
BTW, I would like to point out that in your analysis, virtually every piece
of software you use is written by "idiots". In the same vain, I would also
argue that every CPU in current machines is designed by "idiots" because
these chips couldn't be designed by laying them out gate by gate.
I also think you
"Paul Mensonides" <leav...@home.com> wrote in message
news:e0WVijmtAHA.1156@tkmsftngp03...
>
Ronald Laeremans [MSFT]
participated in the process and the goal of the review was very clearly
specified from the outset.
BTW, we did fix a lot of problem apart from the items in the list I posted
between VC 6 and VC 7, which is why we would have liked to see VC 7
included.
-Ronald-
"Paul Mensonides" <leav...@home.com> wrote in message
news:ONj44mmtAHA.2380@tkmsftngp05...
Ken Alverson
>
> "Tomas Restrepo" <tom...@mvps.org> wrote in message
news:uwihF4htAHA.1632@tkmsftngp05...
>
> : Things are not so simple as just "adding a /V60" switch, it is *far*
more
> : complicated. In fact, I think that if MS actually had to deliver on such
an
> : issue without actually resorting to shipping multple versions of the
> : compiler, the schedule for the compiler development could easily double.
> : It's a hard thing to do, especially if you take into account all the
> : resources necessary for proper testing, etc, and the fact that a modern
C++
> : compiler is copmplex enough that adding support new for C++ constructs
is
> : likely to break older code. As a simple example, consider the impact of
> : changes that affect the lookup order.
>
> Resources? Microsoft?
Yeah, even Microsoft hasn't figured out how to clone the excellent
programmers, and the demand for excellent programmers far outstrips the
supply.
But there's another issue here, and that is - throwing programmers at a
product doesn't necessarily speed things up; often it's counter productive,
and it's *never* linear.
Ken
Paul Mensonides
"Ken Alverson" <K...@Alverson.com> wrote in message
news:u3fAhOotAHA.1344@tkmsftngp04...
: "Paul Mensonides" <leav...@home.com> wrote in
message
: news:eNYc5ultAHA.2344@tkmsftngp05...
: Yeah, even Microsoft hasn't figured out how to
clone the excellent
: programmers, and the demand for excellent
programmers far outstrips the
: supply.
:
: But there's another issue here, and that is -
throwing programmers at a
: product doesn't necessarily speed things up;
often it's counter productive,
: and it's *never* linear.
:
: Ken
I'm not saying that it does. I'm saying that new
'features' are not as important as old 'features'
that haven't been implemented yet or have been
implemented incorrectly. Despite that, there are
many things MS could do to achieve both of these
goals in a more timely fashion--though not
*necessarily* in a linear fashion.
Paul Mensonides
Tomas Restrepo
Funny thing about your comments is that:
a) I don't really think it's MS job to ensure that programmers learn to
program That's what schools/colleges or whatever are about. And
b) You pretty much assume that every other developer writing with MS tools
is a complete idiot. Gee, thanks for the vote of confidence.
TO be quite thruthful, That's a pretty holier-than-thou attitude for someone
who has demonstrated in several posts that he doesn't really understand much
about the complexities of implementing a C++ compiler.
And FWIW, I've seen quite a few idiots programming in C++, and you know
what? They also appear in other platforms. Wanna blame those on MS, too?
>
> Not if resources were expanded, and Microsoft gave a damn. I respect what
you say about making progress in the future. However,
> you will likely have a new standard in 2005 (is that when it's slated
for?) or so. So you had better hurry just to break even
> before the next one hits and you're at day one again. I still don't see
why you couldn't parse all these differences away
> anyway--unless you're using some generic parser generator that you can't
specialize.
The parser itself is really not the most problematic part, but rather the
semantics associated with it. For example, in the case of templates, you
might just want to look at how but-ugly things get when you consider things
like dependent-name lookups work, and see why things like "inheritance that
doesn't behave like inheritance" appear. Or just look at things like Koenig
Lookup and realize that getting them right actually implies almost
completely rewriting the compiler symbol table mechanics. Then ask yourself
if you think it really is that easy.
>
> BOY, THAT WOULD SURE BE SOME DIFFICULT PARSING! All that is required is a
relatively simple preprocessing before the whole lot is
> fed to the compiler.
Yeah? So, how does your glorified parser deal with things like:
#include <iostream>
int a;
struct A {
int a;
};
template <class T> struct Y : public T {
void f(int i) { a = i; }
};
int main()
{
Y<A> ya;
ya.a = 15;
a = 5;
ya.f(12);
std::cout << "::a=" << a << std::endl;
std::cout << "ya::a=" << ya.a << std::endl;
return 0;
}
What's the correct answer to this program? Hint: VC++ get's it wrong. Hint
2: Section 14.6.2 of the ISO STD will tell you.
Just to make things even more interesting. How would your solve-it-all
glorified parser deal with the export keyword, which virtualy no compiler
supports fully? And then ask yourself why they don't.
Dima Pasechnik
> If the issue is with support for using the STL, I'd argue that the VC7
> version of the STL is quite good from a usage perspective. If the issue is
> with implementing idioms similar to those described in this part of the
> standard, then I suggest you say that directly.
>
> > Here VC++ failes already 2 lines down in the standard header <iterator>.
> > Makes it kind of hard to use that part of the standard :-(((
>
> Which part do you mean? #include <iterator> or partial template
> specialization? The included version of <iterator> includes workarounds and
> is quite functional, even though partial template specialization support is
> not available.
>
It's better than in VC6, but still, designing your own containers is quite
painful. For instance, iterators must inherit from (highly non-standard)
template class std::iterator, otherwise STL algorithms won't really work
with them.
In fact, VC7 can do better than this is currently coded in the supplied STL,
as I pointed out some time ago here (you can also try the STL from
www.stlport.org), but then I heard that the improvement
suggested is to be evaluated by Dinkumware first, etc etc...
Sounds kinda hopeless :-(
Dmitrii.
<flame>
I imagine Dinkumware will again get sued by some Foot&MouseDiseaseware
or Quokkaware that will prevent them for years from doing anything
with the STL shipped, while permitting selling their upgrades
separately...
</flame>
Dima Pasechnik
[...]
> There are a lot of Unix and Linux developers that hate Microsoft for all
> kinds of reasons. Including the fact that we charge a license fee, that we
> don't distribute source code for all our products and that we certainly
> don't release it under GPL. And we do not produce a multiplatform C++
> compiler, we produce a C++ compiler for the Windows platforms only.
>
Well, are you sure that Windows developers love Microsoft, unconditionally? :)
[...]
> I would have liked to have a better compliance story for VC 7.0, but I do
> very firmly believe that the Visual C++ compiler, including the Visual C++
> 6.0 compiler is one of the most stable and reliable compilers in the
> industry.
In our list of supported compilers (our, means that work with CGAL,
www.cgal.org) the ranking, w.r.t. ease of coding and absense of the need
for workarounds, is more or less as follows:
1/2) g++, SGI CC
3) Borland
4) MSVC
5) SunPro (dropped lately, too buggy and non-conformant)
On Windows, this boils down to
1) g++
2) Borland
3) MSVC
MSVC (6.0) did not work for us with the supplied STL, at all.
We had to port to our purposes the STL from www.stlport.org
(this is quite a workaround, on its own, that generates iterator_traits
for pointers via macros, etc...)
Dmitrii.
Michael Viking
devil's advocate here, and I'm impressed that you monitor this newsgroup and
respond to things - Thank!. Still playing the gadfly, though, I just don't
see much standards compliance improvement coming in the VC8 version of the
compiler. After all, won't there be more extensions to add? Won't there be
some new buzzword to follow? Won't there be plenty of problems with all the
new keywords added in VC7 that need fixing? And won't all of those things
be more important than compliance with a non-MS standard?
Regarding some of the things said about wizards, and MFC, ATL etc. and dumb
programmers, I'd have to say that in my experience it does seem like every
other programmer I come across sucks rocks. I can't count how many times
I've felt embarrassed for somebody I'm interviewing and I think I should
tell them "look, you're really over-representing yourself on your résumé" or
something. I just interviewed a guy last week how claimed to be "an expert
at C++ with over 6 years of experience." This guy didn't know what const
or static was. He did understand pass by value vs. pass by reference. AND
he was the rule, not the exception of people I interview! There are very
few good programmers and all of those lizards and extensions only do one
thing: make it easier for bad programmers to write worse code more quickly
than before. They also make it harder for everybody to understand the code
when one line of code means 50 lines get inserted into the compile stream
somewhere, never to be seen.
-Michael Viking
"Ronald Laeremans [MSFT]" <ronl...@microsoft.com> wrote in message
news:#UYDOjntAHA.1224@tkmsftngp04...
Matt Osborn
Enhancing compliance before adding extensions would seem most reasonable to
me.
What's happening here is that Microsoft would just as soon let C++ go the
way of OS/2 & Java, but the MS compiler group are jumping through hoops in
an effort to keep C++ alive.
Thanks guys, I'm hoping for the best.
"Tomas Restrepo" <tom...@mvps.org> wrote in message
news:uwihF4htAHA.1632@tkmsftngp05...
Tomas Restrepo
> What's happening here is that Microsoft would just as soon let C++ go the
> way of OS/2 & Java, but the MS compiler group are jumping through hoops in
> an effort to keep C++ alive.
Well, MS is a big company, and I doubt the VC++ team was completely involved
in the decision to create .NET :) OTOH, Given MS intention of making .NET a
success in any way, not having those extensions in the C++ compiler would
have probably meant that C++ would indeed fall by the wayside (or, more
likely, the runtime itself might have never been built).
I do wish, in all honesty, for better compliant, and I'd love to help out in
any way I can to make that happen, which means reporting suggestions and
bugs as much as I can and getting other people to do the same. The more we
let MS know we want it, the better the C++ team can justify the need to
their upper-level program managers and the better chance we stand of getting
it.
--
Tomas Restrepo
tom...@mvps.org
Jeff Kohn
> Fixing compliance issues in the VC compiler is significantly complicated
by
> backwards compliance issues and the QA effort that that involves. By far
the
> number one requested "feature" of our build tools is not to break existing
> code when compiled by the new compiler. And especially not to introduce
> semantic changes (getting new compiler errors, is not something users are
> ecstatic about either, but at least some reasonable fraction is willing to
> live with that for increased compliance).
I don't understand why this is such an issue. If you release a new compiler
that is more fully standards-compliant and as a result some people's older,
non-compliant code doesn't compile anymore, SO WHAT? Either than can fix
their code to be compliant, or they can continue to compile it with an older
version of VC++. Why does non-compliant code need to be supported? As long
as VC6 is still available, why should it be a priority to make old, buggy
code compile on the latest, most-compliant compiler?
Granted, if you take this attitude there are going to be some whiner
cry-babies who will complain, but that's just tough !?@% for them .
Jeff
Jimbo
<Sh...@pspl.co.in> wrote:
>Warning: This is off topic so scram :)
I'll be orf in a minute sor !
>> 9x was a 386
>> NT4 was a 486
>> NT5 was a P1
>
><Nitpick>
>Some corrections to the above.
>For 9x it goes like this: 386 for Win95, 486 for Win98, P/150 for WinMe and
>PII/300 for WinMe with multimedia razzmatazz like movie maker. </Nitpick> :)
No, I didn't read the other readme files... :)
>And according to 'WinXP Beta 2' news today, MS wants PIII minimum, although
>I'll wager that even a PII will work.
Worth giving it a go, unless they've hard-coded the reqs...
>> Isn't it a 64-bit addressing system. Can't see XP being released for
>> a bog-standard P1 or P2, although I could be wrong. Needs a 64-bit
>> chip doesn't it ? ergo why compile the OS with anything less than the
>> chip's timings ?
>
>Oh No! WinXP is going to be available in 2 flavours. Win32 and Win64. It is
>the WinXP 64 bit that can take advantage of the 64 bit addressing. XP
>doesn't need a 64 bit chip. WinXP 64 bit does though (obviously). Win64 runs
>Win32 as another WOW (Windows on Windows) subsystem called WOW64.
Ahhh, right. See where they're going now... sort of...
>> It's still nice to see the LIM aggreement hasn't been completely
>> fragmented yet :) But I would have enjoyed a LMM a lot more.
>
>I'm guessing the 2nd M is but of course Motorola :)
Yes. More of a "personal taste" thing, and as you say...
>x86 surviving this long is quite amazing.
Is longer than I'd have imagined it... Probably longer than some
Intel engineers would have imagined it too :)
<snipped loads of goodies that could be appearing over then next few
years>
Cheers chap,
Jim M
--
@ Derbyshire
Ronald Laeremans [MSFT]
"Dima Pasechnik" <d.pas...@twi.tudelft.nl> wrote in message
news:uhf0ff...@twi.tudelft.nl...
[...]
> In our list of supported compilers (our, means that work with CGAL,
> www.cgal.org) the ranking, w.r.t. ease of coding and absense of the need
> for workarounds, is more or less as follows:
>
> 1/2) g++, SGI CC
> 3) Borland
> 4) MSVC
> 5) SunPro (dropped lately, too buggy and non-conformant)
>
> On Windows, this boils down to
>
> 1) g++
> 2) Borland
> 3) MSVC
>
> MSVC (6.0) did not work for us with the supplied STL, at all.
> We had to port to our purposes the STL from www.stlport.org
> (this is quite a workaround, on its own, that generates iterator_traits
> for pointers via macros, etc...)
As you probably know, we still have issues with iterator_traits due to lack
of PTS. Most of the other STL workarounds have for a large part gone away.
As I have offered before to people here, if you want to work with us to make
sure your library is supported without workaround, please send me an email
with contact information, and I'll make sure you get on this list.
-Ronald-
Ronald Laeremans [MSFT]
the chain between me and Steve Balmer, every one of which could decide to
not have us work on compliance or even rip support out of the compiler till
the day the CDs are in the warehouses. I can only tell you what our current
plans are and that I consider it my job to keep them intact. I try very hard
to not overpromise or overrepresent.
As far as dumb programmer's are concerned, what is your suggestion here,
that we make it much harder to develop windows applications in C++ so "bad
developers" crash and burn trying to write them? I feel that we are already
relatively successful there compared to say VB or Perl. ;-)
If you are arguing that the Visual C++ tam has traditionally invested more
in making C++ Windows development more easily learnable or more accessible
and less in increasing productivity for the high-end developer, I would even
tend to agree. If you have any good suggestions on what features you (or
anyone else in this forum) would like in the product in that respect, I
would be very glad to hear them. (Apart from compliance, we know about that,
that is why it is on the schedule.)
Ronald Laeremans
Visual C++ compiler team
"Michael Viking" <TheV...@sweden.se> wrote in message
news:#av0DJutAHA.1972@tkmsftngp04...
Michael Viking
Thanks for the response. Some of things I'd find useful would be, not in
any particular order(I could order them if you like):
1. Multiple cut and paste buffers (more like VI, not the useless office
thing where it's impossible to tell what icon represents what buffer) - not
a week goes by without me missing this
2. IDE support for search and replace in multiple files - not a week goes
by without me missing this
3. Better VSS integration. It's disgusting how hard it is if you use
multiple VSS DBs or if you move a project, or share a project, the list goes
on and on. There's the Tools | Options | Source Control | Advanced |
Integration | Choose Source Safe Database button, but in all my life I've
never seen that work. I've spent many 10s of hours in my career trying to
re-synch up projects that have moved, branched, changed databases, etc.
This bugs me about every few months, but I'm practiced enough that I can
usually get it fixed pretty fast. It still eats out my substance, though.
4. Intellisense that works! - not a day goes by without this bugging me.
Some examples
4a) it often just quits working even after deleting ncb file and
restarting
4b) it doesn't work with namespaces
4c) it should know about filling in enums in function parameter lists
(like VB)
4d) when typing in a class member definition, intellisense often shows
exactly what you'd like to type, but there's no way of making it type it for
you
4e) I'm sure you know all the problems, let's move on
5. Fix the bug where cut and paste quits working! happens about every 2
weeks.
6. More and better compiler warnings. Just yesterday a Java guy here
learning C++ had a problem with something like this:
for(...);
{
///
}
The for loop was empty because of the semicolon and he spent 45 minutes
trying to figure out what was wrong. It's an obvious candidate for a
warning! How can that be after all these years? No doubt every day I could
be helped by more and better warnings. I imagine it's the same for while
loops. At least it warns about if statements. This is a shameful omission.
7. The dependency management doesn't work correctly. As the number and
location of projects in a workspace increases, the more likely one will have
trouble. Most of our projects suffer from this problem and need to be built
on the command line.
8. Export makefile and write dependencies don't work at all in my
experience. We'd like to use this feature, but it's so broken as to be
useless. It doesn't always happen, but it seems to be related to the
complexity of the workspace. One of the problems is that it starts putting
in wacky {{SOURCE}} strings or something.
9. The watch window, for example, does not know how to access variables in
a namespace. Annoying every other day.
10. The class wizard does not understand namespaces. Don't even look there
anymore. Adjusted to the annoyment.
11. Edit and continue needs improvement. It often says that I've changed
some structure or something when I haven't done anything. Adding a comment
for example in some situations can give the "doesn't support changes" error.
This is a big problem.
12. Edit and continue has some sort of memory leak or something. If one
uses it enough (hard to define enough) without stopping the debugging
instance, it gets slower and slower and eventually locks up or crashes.
This happens a lot. This is a big problem. At least freaking save the file
before going into the edit and continue routine.
13. VSS integration speed is too slow. Try doing something over a modem or
DSL....wow, the tedium.
14. Allow a comment to be associated with each string in a string table (RC
editor)
15. The RC editor often thinks something has changed when nothing has
changed, and then it wants to save it. Often the file is read only and
can't be saved due to VSS. There's no way to "undo changes" or make it
smart enough to know that nothing changed. Happens all the time when I'm
actively editing resources.
16. How about better support for TRACE mechanisms? Making it possible to
see them in release mode, making it possible to filter them somehow so that
Joe Blow's TRACES don't clutter up my traces.
17. A "Last Position" menu item like VB has. Complements the browse info,
among other things. All the time I miss this.
18. Are you familiar with John Robbin's crash finder tool that takes an
address and finds the line number etc. in the source code? It would be nice
if the IDE natively supported that.
19. List properties, constants etc. like VB can with a right click..
The list could go on. I suggest that others post their lists of things
they'd like that have nothing to do with the latest buzzword as well. I
believe intellisense is probably a lot better in VC7 but how about the other
things? Am I going to die waiting for them?
-Michael Viking
"Ronald Laeremans [MSFT]" <ronl...@microsoft.com> wrote in message
news:O71FYOwtAHA.1372@tkmsftngp04...
Zachary Turner
I think you're being a bit unrealistic. A fully standard compiler doesn't
even exist, and probably never will. Even if you had a fully standard
compiler, would you use every single feature from the standard? I seriously
doubt it.
Bill Wagner
Ronald started this by saying:
> > If you have any good suggestions on what features you (or
> > anyone else in this forum) would like in the product in that respect, I
> > would be very glad to hear them. (Apart from compliance, we know about
> > that, that is why it is on the schedule.)
> >
> > Ronald Laeremans
> > Visual C++ compiler team
> >
Okay, here are some features I would love to see:
1. Better control over expanding nodes in class view.
As projects get bigger and bigger, I would like to be able to expand class
view selectively:
o Only show me the public interfaces from a class.
o Only show me the public and protected interfaces from a base class.
o Only expand some classes from a project.
Basically, the projects I work on are getting bigger and bigger. My screen
isn't.
2. Generate our own attributes.
There are quite a few programming problems I have solved more often than I
would like to have. The existing attributes hit the biggies (COM, ODBC), but
it would be great if I could write my own attributes for those idioms I end
up using over and over and over....
3. Replace wizard generated code with attributes.
I has used VC xx since version 1.0. The number of times I have had to take
an old project and figure out how to add the new features to it is
innumerable. If the bulk of the code that AppWizard created made attributes
instead of injecting all the source, this task would be much simpler.
4. Some way for the IDE to handle multiple .rc files in a project.
With large projects, the "ownership" of the UI is shared between numerous
people. resource.h and <projname>.rc become scarce resources for
developers. (They also get *way* too many versions because they are so
centralized.) If these files could be broken up in some way to let multiple
developers each add features to the interface at once, it would be a big
savings.
5. Automatic build generation numbers.
I have written scripts that automatically check out the .rc file, increment
the version number, and check it back in as part of an automated build
process. This would be a cool thing to add to the IDE.
6. A better way for the debugger to look at elements in collections (either
STL, or MFC)
I would die a happy programmer if I could enter this in the watch window:
m_Collection [ 5 ]
and see what it was. Finding the address of the nth object in a vector is
no picnic. Following the pointers in a list is even more painful. I can't
even think of the last program I wrote that did not use some collection.
This feature alone would save me hours, days, maybe even weeks.
I have some comments on Michael's list as well:
"Michael Viking" <TheV...@sweden.se> wrote in message
news:uxKJlJytAHA.1704@tkmsftngp04...
> Ronald,
> Thanks for the response. Some of things I'd find useful would be, not in
> any particular order(I could order them if you like):
> 2. IDE support for search and replace in multiple files - not a week goes
> by without me missing this
That's there in 7. Edit -> Find and Replace -> Replace in Files.
> 4. Intellisense that works! - not a day goes by without this bugging me.
> Some examples
> 4a) it often just quits working even after deleting ncb file and
> restarting
> 4b) it doesn't work with namespaces
> 4c) it should know about filling in enums in function parameter lists
> (like VB)
> 4d) when typing in a class member definition, intellisense often shows
> exactly what you'd like to type, but there's no way of making it type it
for
> you
> 4e) I'm sure you know all the problems, let's move on
All good ideas. This is better in 7, but could still improve.
> 5. Fix the bug where cut and paste quits working! happens about every 2
> weeks.
Can't say I've seen this one.
> 6. More and better compiler warnings. Just yesterday a Java guy here
> learning C++ had a problem with something like this:
> for(...);
> {
> ///
> }
> The for loop was empty because of the semicolon and he spent 45 minutes
> trying to figure out what was wrong. It's an obvious candidate for a
> warning! How can that be after all these years? No doubt every day I
could
> be helped by more and better warnings. I imagine it's the same for while
> loops. At least it warns about if statements. This is a shameful
omission.
While that example is evil, I would prefer more improvement to warnings and
errors with template based code. It has gotten much better, but many of my
clients still view it as a black art to figure out what caused a particular
compiler error. The trace is great, but the messages are still pretty
indecipherable. How about messages like
"No assignment operator for CFoo, used as template arg in ....."
Michael Viking
errors in the current state. He'd much rather hear about how much we
appreciate the new extensions he's added. Notice how he doesn't respond on
this topic?
Here is another thing I come across that I find extremely annoying:
"One or more breakpoints cannot be set and have been disabled. Execution
will stop at the beginning of the program" Man, I hate that behavior. Does
anybody like it? Give me a choice on whether I want to stop at the first
line. In all my career I don't think stopping at the beginning of the app
is the behavior I wanted. I might want to ignore and keep running, I might
want to immediately quit debugging and change what I'm doing. But I do not
want to look at the beginning of the program. Hateful.
Michael Viking
"Bill Wagner" <wwa...@midwestseas.com> wrote in message
news:uDce2UHuAHA.2000@tkmsftngp04...
Jimbo
<wwa...@midwestseas.com> wrote:
<snip>
>4. Some way for the IDE to handle multiple .rc files in a project.
>
>With large projects, the "ownership" of the UI is shared between numerous
>people. resource.h and <projname>.rc become scarce resources for
>developers. (They also get *way* too many versions because they are so
>centralized.) If these files could be broken up in some way to let multiple
>developers each add features to the interface at once, it would be a big
>savings.
Count me in on this one too.
The resource editor/file manager seems like it's not been touched over
the years, compared to the other huge advances.
The Class View can handle multiple .h/.c/.cpp/.anything files very
well, but the poor old resource editor/manager is a limited.
Trouble is Beta 2 is reported as being "feature locked" and nothing
new will be added for the release. Could be too late suggesting this
:(
>> 2. IDE support for search and replace in multiple files - not a week goes
>> by without me missing this
>
>That's there in 7. Edit -> Find and Replace -> Replace in Files.
That and folding code :) Nice.
>> 5. Fix the bug where cut and paste quits working! happens about every 2
>> weeks.
>
>Can't say I've seen this one.
Is this where the editor behaves like shift is constantly depressed ?
Still don't know how/why this happens. Anyone ?
Tomas Restrepo
> I don't think ol' Ron seems interested now that people are pointing out
the
> errors in the current state. He'd much rather hear about how much we
> appreciate the new extensions he's added. Notice how he doesn't respond
on
> this topic?
No surprise there. After all, this thread is pretty much devoted to IDE
issues, and Ronald doesn't handle the IDE. Really, this post would be more
on-topic on the microsoft.public.vsnet.ide group.
>
> Here is another thing I come across that I find extremely annoying:
> "One or more breakpoints cannot be set and have been disabled. Execution
> will stop at the beginning of the program" Man, I hate that behavior.
Does
> anybody like it? Give me a choice on whether I want to stop at the first
> line. In all my career I don't think stopping at the beginning of the app
> is the behavior I wanted. I might want to ignore and keep running, I
might
> want to immediately quit debugging and change what I'm doing. But I do
not
> want to look at the beginning of the program. Hateful.
Perhaps it is, perhaps somebody likes it. The point is: Have you ever told
this to microsoft? Have you actually send suggestions and your wishes to
aliases such as mswish? If not, how the hell do you expect them to know
about it? Read your mind?
I don't mean to pick on you, but I've seen too much people go about asking
that kind of stuff and they somehow imagine that the MS guys can guess what
they want. You want something? Be proactive and tell them so in no uncertain
terms!
Ronald Laeremans [MSFT]
the issues are not in areas I work on every day. So I am trying to get the
more clued in people for these to address the issues. And no, I wasn't
looking for praise on what we were doing, I am very much looking for
feedback on what we are missing.
I was expecting a bit more aggressive suggestions for further out things,
but a list of bugs you find really annoying, or very day to day features we
are missing are great input as well. I had just expected other stuff because
Paul and maybe one or 2 other people on the thread said we spent way too
much effort on (paraphrased) "fluffy stuff for idiot programmers" instead of
things that really mattered. It seems that most of the issues in this list
are some of the "fluffy" things that don't work quite as well as people
would like.
And lastly, I would like to say that I can't guarantee any level of
responsiveness in this forum (or on the dotnet mailing list). I am not in
marketing, nor a full time manager, so solving technical problems so we ship
out a better product to you guys will always take precedence to my presence
here. And in the next two weeks time, so will be the fact that my kids are
visiting.
-Ronald-
"Michael Viking" <TheV...@sweden.se> wrote in message
news:#c0Re7HuAHA.1924@tkmsftngp03...
Ronald Laeremans [MSFT]
> 2. IDE support for search and replace in multiple files - not a week goes
> by without me missing this
This is in VC 7.
> 4. Intellisense that works! - not a day goes by without this bugging me.
> Some examples
> 4a) it often just quits working even after deleting ncb file and
> restarting
> 4b) it doesn't work with namespaces
> 4c) it should know about filling in enums in function parameter lists
> (like VB)
> 4d) when typing in a class member definition, intellisense often shows
> exactly what you'd like to type, but there's no way of making it type it
for
> you
> 4e) I'm sure you know all the problems, let's move on
Very significant improvements have been made in 7. Please take a lok at the
Beta and let me know what still doesn't work.
> 5. Fix the bug where cut and paste quits working! happens about every 2
> weeks.
For this and other bugs of this kind, getting good repro cases is very
important. I never experienced this myself, but maybe it is a well known
issues and one of my co-workers can update you on the status.
> 6. More and better compiler warnings. Just yesterday a Java guy here
> learning C++ had a problem with something like this:
> for(...);
> {
> ///
> }
> The for loop was empty because of the semicolon and he spent 45 minutes
> trying to figure out what was wrong. It's an obvious candidate for a
> warning! How can that be after all these years? No doubt every day I
could
> be helped by more and better warnings. I imagine it's the same for while
> loops. At least it warns about if statements. This is a shameful
omission.
Compiler warnings are an issue where customers significantly disagree. In VC
7 we have added a decent number of warnings that are off by default, even at
warning level 4. If we were to add one for this, it would be certainly in
that category, for loops with empty bodies are a very often used paradigm in
C/C++.
> 8. Export makefile and write dependencies don't work at all in my
> experience. We'd like to use this feature, but it's so broken as to be
> useless. It doesn't always happen, but it seems to be related to the
> complexity of the workspace. One of the problems is that it starts
putting
> in wacky {{SOURCE}} strings or something.
The entire feature has been cut in VC 7. The build-in project system is now
good enough to use as a build-engine from the command line.
> 11. Edit and continue needs improvement. It often says that I've changed
> some structure or something when I haven't done anything. Adding a
comment
> for example in some situations can give the "doesn't support changes"
error.
> This is a big problem.
Edit and continue has also been improved significantly. Sometimes the
mechanism is conservative, but we reduced the number of "rude edits" where
the engine gave up and you needed to restart. But then if you just add a
comment, the do not apply changes will work perfectly. I can't really see
how that specific case could be a big problem.
> 12. Edit and continue has some sort of memory leak or something. If one
> uses it enough (hard to define enough) without stopping the debugging
> instance, it gets slower and slower and eventually locks up or crashes.
> This happens a lot. This is a big problem. At least freaking save the
file
> before going into the edit and continue routine.
I hope that you did report this issue with a good repro. I'll ask one of the
debugger/editor people to comment on saving the files.
> 13. VSS integration speed is too slow. Try doing something over a modem
or
> DSL....wow, the tedium.
Visual SourceSafe has some issues with running over a high-latency link. I
don't think this is being addressed in VS.Net 7.0.
> 16. How about better support for TRACE mechanisms? Making it possible to
> see them in release mode, making it possible to filter them somehow so
that
> Joe Blow's TRACES don't clutter up my traces.
There are several third party products that do this. And Microsoft is also
working on system level trace support. I don't think much of that will be
ready for 7.0 though.
> 17. A "Last Position" menu item like VB has. Complements the browse
info,
> among other things. All the time I miss this.
I don't know what this is, could you explain? Browse does have "pop
context".
Ken Alverson
> 4d) when typing in a class member definition, intellisense often shows
> exactly what you'd like to type, but there's no way of making it type it
for
> you
Try TAB.
Ken
Ken Alverson
> > 6. More and better compiler warnings. Just yesterday a Java guy here
> > learning C++ had a problem with something like this:
> > for(...);
> > {
> > ///
> > }
> Compiler warnings are an issue where customers significantly disagree. In
VC
> 7 we have added a decent number of warnings that are off by default, even
at
> warning level 4. If we were to add one for this, it would be certainly in
> that category, for loops with empty bodies are a very often used paradigm
in
> C/C++.
This is true, however loops without side effects are not an often used
paradigm, they're almost certainly an error or an attempt at a benchmark.
That is, while:
{
char *src=a,*dst=b;
while (*dst++ = *src++);
}
may be valid (some would argue its readability/maintainability, but few
would argue its validity)
{
char *src=a,*dst=b;
while (*dst++ == *src++);
}
is nigh useless. Now, VC6 is smart enough to tell me that
foo == bar;
is probably wrong (warning C4553), it's only an extension of that same logic
that would let it tell me that the second while loop is also wrong (it would
have to follow src and dst and make sure their results aren't subsequently
used to determine if the loop was free of observable side effects). The
same could be done for "for" loops (again, the loop variable would have to
be watched to make sure its result is never used in order to determine if it
was free of observable side effects. Properly scoped loop variables would
aid this greatly, since they have a shorter lifetime). VC already tracks
when variables are read and written, because it can warn of possible use
before initialization, so I imagine 80% of the necessary code is written.
Ken
Martyn Lovell
In article <uxKJlJytAHA.1704@tkmsftngp04>, TheV...@sweden.se (Michael Viking) wrote:
> 13. VSS integration speed is too slow. Try doing something over a
> modem or DSL....wow, the tedium.
Generally, VSSafe isn't designed to be used over a very slow link. VSSafe Explorer also has performance issues over
a ver slow link. VSSafe 6.0 did a bunch of work to improve this situation, and the VSSafe 6 service packs have
added further perf improvements. It's worth getting these.
If you really need to use VSSafe over a slow link, you might prefer to use one of the third-party products, such as
Source OffSite.
VS.NET Beta 1 had some significant perf issues with the source control integration. I'm pleased to say that we've
addressed these for the next beta. In fact, VS.NET is now substantially /faster/ to open source controlled
solutions from disk than VC6 was. In particular, we've addressed the annoying 'updating source control status' that
would take ages during opening a VC6 project.
Martyn Lovell
Development Lead
Visual Studio Enterprise
email: lny...@tfosorcim.moc
[Spam-avoidance: reverse each word in the email address before use]