new features

  • Thread starter Thread starter Servé Lau
  • Start date Start date
S

Servé Lau

I've read the new features that are coming to the next VC and they all sound
fine.
But I was missing new standard C++ features, will the features like export
still not be implemented?

What about C features like designated initializers?
struct X { int x; int y; };

X x = { .x = 2, .y = 3 };
 
Servé Lau said:
I've read the new features that are coming to the next VC and they
all sound fine.
But I was missing new standard C++ features, will the features like
export still not be implemented?
Click to expand...

export won't be implemented in Whidbey (aka "VC8"). The only other major
standards compliance features that VC is missing are two-phase lookup of
dependent names in templates and full support for exception specifications.
AFIAK, neither of these will be implemented in Whidbey either.
What about C features like designated initializers?
struct X { int x; int y; };

X x = { .x = 2, .y = 3 };
Click to expand...

AFIAK, no C99 features are planned for Whidbey.

-cd
 
Carl said:
export won't be implemented in Whidbey (aka "VC8"). The only other
major standards compliance features that VC is missing are two-phase
lookup of dependent names in templates and full support for exception
specifications. AFIAK, neither of these will be implemented in
Whidbey either.
Click to expand...

Not implementing two-phase lookup of dependent names is poor. It is by far
more important than 'export' or 'exception specifications', both of the
which may very well be re-worked in the next reiteration of C++. But the
former is essential for template programming ( see "C++ Templates" by
Josuttis and Vandevoorde ), and VC++ not doing it will continue to lead to
template programming problems in certain areas.
 
Carl Daniel said:
export won't be implemented in Whidbey (aka "VC8"). The only other major
standards compliance features that VC is missing are two-phase lookup of
dependent names in templates and full support for exception specifications.
AFIAK, neither of these will be implemented in Whidbey either.
Click to expand...

two-phase lookup would be something invisible to us developers right?
AFIAK, no C99 features are planned for Whidbey.
Click to expand...

That's a shame :)
I can understand that VLA's aren't implemented, we've seen enough buffer
overflows.
But designated initializers let you write safer code and the safer C99
functions like snprintf would also be in the best interest of us developers.
And stdint.h and inttypes.h with its macro's like PRId64 would be great now
that the world is ready for 64-bit. They are very easy to implement also.

But the .NET features are nice. No more double underscore keywords,
generics, destructors, sounds good.
 
Servé Lau said:
"Carl Daniel [VC++ MVP]"
export won't be implemented in Whidbey (aka "VC8"). The only other
major standards compliance features that VC is missing are two-phase
lookup of dependent names in templates and full support for
exception specifications. AFIAK, neither of these will be
implemented in Whidbey either.
Click to expand...

two-phase lookup would be something invisible to us developers right?
Click to expand...

Not if you are writing template classes. Without two-phase lookup, certain
template construct and usages can lead to instantiation errors.
 
Servé Lau said:
two-phase lookup would be something invisible to us developers right?
Click to expand...

Because two-phase lookup is really the technique that enables dependent
names, it's dependent names that you would get. Enabling dependent names on
a code base that does not already make use of them is highly likely to
break.

I've heard experiences from other compiler implementors who had implemented
dependent names for code bases that did not use them to begin with. None of
the code compiled. The breakage was severe. These code bases ended up
requiring compiler modes that did not use dependent names. Our
investigations showed this was a common scenario.

The majority of existing code does not use dependent names, and enabling it
would likely break the code in very subtle ways. When such breaks occur, we
like to have diagnostics that help alert the programmer. Due to both of
these facts, we did not have enough time to work on this feature in Whidbey.

Cheerio!
 
Carl said:
export won't be implemented in Whidbey (aka "VC8"). The only other major
standards compliance features that VC is missing are two-phase lookup of
dependent names in templates and full support for exception
specifications. AFIAK, neither of these will be implemented in Whidbey
either.
Click to expand...

That's all correct. We are adding support for a number of Unicode features
from the standard, so we are making progress on standards conformance a bit.
Granted it would be nice to do more, but we had to choose which standard
feature was the most important -- it was Unicode.
AFIAK, no C99 features are planned for Whidbey.
Click to expand...

Actually, we are doing some C99 features like floating-point models. Some of
the more extravagent language features we are not doing until the C++
standards committee has time to digest them.

Cheerio!
 
Brandon Bray said:
Servé Lau said:
two-phase lookup would be something invisible to us developers right?
Click to expand...

Because two-phase lookup is really the technique that enables dependent
names, it's dependent names that you would get. Enabling dependent names on
a code base that does not already make use of them is highly likely to
break.
[...]
Click to expand...

OTOH without two-phase lookup you get into
all kinds of trouble if some user out there
for the first time tries to instanciate your
template for the very first time. _That_ is
my concern about your decision to delay the
implementation of this feature.
For old code, this could be turned off. But
I want my code to be compatible with the
future, not with the past.
Cheerio!
Click to expand...

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers
 
Brandon Bray said:
[...]
That's all correct. We are adding support for a number of Unicode features
from the standard, so we are making progress on standards conformance a bit.
Granted it would be nice to do more, but we had to choose which standard
feature was the most important -- it was Unicode.
Click to expand...

But that's only because you assigned std
conformance such a low priority.
[...]
Cheerio!
Click to expand...

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers
 
Back
Top