C/C++ and Fortran

The View (or trip report) from the July 2009 C++ Standard meeting (Part 2)

By Archive User posted Mon July 20, 2009 03:55 AM

  

Originally posted by: Michael_Wong


One of the issue we were concerned about at this meeting was the intent to deprecate trigraphs. We wrote a paper indicating why we oppose this. This was reviewed in the Evolution Committee and many delegates accepted our position and need to support existing customers. This is good for existing trigraph users.

However, discussion in committee indicate that if we can find an alternate way to support these users then we should explore that with the blessing of the committee. I will be looking at alternatives in future postings.

The C++ Standard Library Working Group also ratified four proposals into the C++0x draft.

C++0x Stream Positioning

C/C++ I/O files predates modern file sizes, and are usually based on int or long. This proposal allows them to work better with the new long long type in C++0x.

Specifying the complexity of size() (Revision 1)

This paper addresses the issue of testing size() and not knowing their complexity constraint. This makes it difficult to use containers where testing size is a frequent operation.

Thread Unsafe Standard Functions

This paper does not make C++ Standard functions thread unsafe, despite the name. Its intention is to clearly identify functions adopted from the C standard that need explicit exemption from the general prohibition on data races.

For example, these are already exempt:
asctime, ctime, gmtime, localtime, strerror, strtok, rand,

The following functions may have previously been thread unsafe, but must be thread safe to enable effective programming. By failng to mention these functions, the standard implicitly requires them to be thread safe.

atexit, at_quick_exit, exit, fclose, free, quick_exit, malloc, signal

Furthermore, C++ locale objects are already adequate for thread-safe locales; setlocale() is thread-unsafe.

Fixing freestanding: iteration 2.2

A freestanding platform is one that has an Operating System. This proposal aims to:
· enable the intent of the freestanding specification compliance to be preserved, by adding only two headers to it relative to its C++98/C++03 contents, namely <initializer_list> and
<type_traits>
· maintain the historically low dependency of the C++ language, and of C++ compilers, on a corresponding library

The benefits of this proposal are:
· it enables current users of the freestanding specification to continue using that specification
· it enables compiler implementers to work fairly independently of library supply
· it enables library implementers to work fairly independently of compiler supply
0 comments
0 views

Permalink