Defect Report: Unclear which members of match_results should beused in comparison [re] (N2284).


Dear C++ committee, In "28.4 Header synopsis [re.syn]" of N2284, two template functions are declared here: // 28.10, class template match_results: // match_results comparisons template bool operator== (const match_results& m1, const match_results& ...
Posted On: Monday 26th of November 2012 12:50:05 AM Total Views:  397
View Complete with Replies

RELATED TOPICS OF C Language PROGRAMMING LANGUAGE




N2369 editorial/defect: New constexpr c'tors of complex are not constant expression c'tors

The incorporation of the new constexpr facility into the last recent draft has lead to some invalid c'tor definitions, because their arguments are not literal types. These are: [complex.special]: In template class complex: explicit constexpr complex(const complex&); explicit constexpr complex(const complex&); In template class complex: constexpr complex(const complex&); explicit constexpr complex(const complex&); In template class complex: constexpr complex(const complex&); constexpr complex(const complex&); Proposed resolution: Replace above mentioned c'tor declarations by the following ones: In template class complex: explicit constexpr complex(complex); explicit constexpr complex(complex); In template class complex: constexpr complex(complex); explicit constexpr complex(complex); In template class complex: constexpr complex(complex); constexpr complex(complex); Greetings from Bremen, Daniel --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
VIEWS ON THIS POST

144

Posted on:

Sunday 4th November 2012
View Replies!

N2369 library defect: Omissions in constexpr usages

1) The member function bool array::empty() const should be a constexpr because this is easily to proof and to implement following it's operational semantics defined by Table 87 (Container requirements) which says: "a.size() == 0". 2) The member function bool bitset::test() const must be a constexpr (otherwise it would violate the specification of constexpr bitset:perator[](size_t) const, because it's return clause delegates to test()). 3) I wonder how the constructor bitset::bitset(unsigned long) can be declared as a constexpr. Current implementations usually have no such bitset c'tor which would fulfill the requirements of a constexpr c'tor because they have a non-empty c'tor body that typically contains for-loops or memcpy to compute the initialisation. What have I overlooked here Proposed resolutions: 1) In the class template definition of [array]/p. 3 replace bool empty() const; by constexpr bool empty() const; 2) In the class template definition of [template.bitset]/p. 1 replace bool test(size_t pos ) const; by constexpr bool test(size_t pos ) const; and in [bitset.members] replace bool test(size_t pos ) const; by constexpr bool test(size_t pos ) const; 3) --- Greetings from Bremen Daniel Krgler --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
VIEWS ON THIS POST

144

Posted on:

Sunday 4th November 2012
View Replies!

N2369 library defect: Const-incorrect get_deleter function for shared_ptr

The following issue was raised by Alf P. Steinbach in c.l.c++.mod: According to the recent draft N2369, both the header memory synopsis of [memory] and [util.smartptr.getdeleter] declare: template D* get_deleter(shared_ptr const& p); This allows to retrieve the pointer to a mutable deleter of a const shared_ptr (if that owns one) and therefore contradicts the usual philosophy that associated functors are either read-only (e.g. key_comp or value_comp of std::map) or do at least reflect the mutability of the owner (as seen for the both overloads of unique_ptr::get_deleter). Even the next similar counter-part of get_deleter - the two overloads of function::target in the class template function synopsis [func.wrap.func] or in [func.wrap.func.targ] - do properly mirror the const-state of the owner. Proposed resolution: Replace the declarations of get_deleter in the header synopsis of [memory] and in [ util.smartptr.getdeleter] by one of the following alternatives (A), (B), or (C): (A) A pair of overloads which preserve the constness of the owning shared_ptr (This reflects the praxis existing for unique_ptr::get_deleter): template const D* get_deleter(shared_ptr const& p); template D* get_deleter(shared_ptr& p); (B) Provide *only* the immutable variant. This would reflect the current praxis of container::get_allocator(), map::key_comp(), or map::value_comp. template const D* get_deleter(shared_ptr const& p); (C) Just remove the function. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
VIEWS ON THIS POST

160

Posted on:

Sunday 4th November 2012
View Replies!

N2284 defect: header synopsis misses specializations

According to [basic.fundamental] p. 5+7 the newly added character types char16_t and char32_t are distinct fundamental types. Further-on, std::numeric_limits has now finally cleaned-up it's responsibilities (see [limits]) and claims to be specialized for all *fundamental* types (p. 2), but the header synopsis does not contain the members: template class numeric_limits; template class numeric_limits; I propose to add them just before the specialization for wchar_t. Further on I would like to repeat an issue mentioned in an earlier posting on february 15th that even with these added specializations the list of [limits]/"header synopsis" is still incomplete, because according to [basic.fundamental]/2 there might exist so-called "extended integer types", which also belong to the fundamental types and which are currently not mentioned in the specialization list of [limits]. To fix this issue I propose to add one final line to the header synopsis: .. // Further specializations for each extended integer type Greetings from Bremen, Daniel Krgler --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
VIEWS ON THIS POST

145

Posted on:

Monday 5th November 2012
View Replies!

N2369 library defect: Missing [c.math] functions nanf and nanl

In the listing of [c.math], table 108: Header synopsis I miss the following C99 functions (from 7.12.11.2): float nanf(const char *tagp); long double nanl(const char *tagp); (Note: These functions cannot be overloaded and they are also not listed anywhere else) Proposed resolution: In [c.math], table 108, section "Functions", add "nanf" and "nanl" just after the existing entry "nan" Greetings from Bremen, Daniel Krgler --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
VIEWS ON THIS POST

137

Posted on:

Monday 5th November 2012
View Replies!

N2284 defect: Missing member function error_code::clear()

The current draft declares in [syserr.errcode.overview] a (modifier) function member clear of class error_code. This member is not contained in the corresponding section [syserr.errcode.modifiers] and thus lacks any member explanation. Greetings from Bremen, Daniel Krgler --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
VIEWS ON THIS POST

126

Posted on:

Monday 5th November 2012
View Replies!

Project report requirements

,.I need some help about project report requirements. Do you know how many reports or documents should be made in the process of sofeware project development .What are they
VIEWS ON THIS POST

125

Posted on:

Wednesday 7th November 2012
View Replies!

Defect report: [dcl.constexpr]/5 constexpr and templates

in the latest draft N2461, [dcl.constexpr]/5 reads: "If the instantiated template specialization of a constexpr function template would fail to satisfy the requirements for a constexpr function, the constexpr specifier is ignored and the specialization is not a constexpr function." such wording implicitly excludes member functions of class templates and member templates. However, the feature might be useful even in those cases and there is no apparent reason why they should be excluded. Proposed resolution: Replace [dcl.constexpr]/5 with: "If the instantiated template specialization of a constexpr function template, member function of a class template or member template would fail to satisfy the requirements listed in the previous paragraphs, the constexpr specifier is ignored and the specialization is not a constexpr function." HTH, Ganesh --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
VIEWS ON THIS POST

172

Posted on:

Wednesday 7th November 2012
View Replies!

comp.std.c++ report for Thu Nov 1 00:05:00 EST 2007

Subject: comp.std.c++ report for Thu Nov 1 00:05:00 EST 2007 Newsgroups: comp.std.c++ Date: Thu Nov 1 00:05:00 EST 2007 This is an automated report about activity of our newsgroup comp.std.c++. It covers period between the previous report and the current one, ending on Thu Nov 1 00:05:00 EST 2007. Reports are normally issued monthly. Approved: 225 messages (of them, 0 automatically) Rejected: 40 messages Preapproved: 0 new posters --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
VIEWS ON THIS POST

164

Posted on:

Wednesday 7th November 2012
View Replies!

Library defect: Ambiguous return clause for std::uninitialized_copy

14882-2003, [lib.uninitialized.copy] is currently written as follows: "template ForwardIterator uninitialized_copy(InputIterator first, InputIterator last, ForwardIterator result); 1 Effects: for (; first != last; ++result, ++first) new (static_cast(&*result)) typename iterator_traits::value_type(*first); 2 Returns: result" similarily for N2369, and its corresponding section [uninitialized.copy]. It's not clear to me what the return clause is supposed to mean, I see two possible interpretations: (a) The notion of "result" is supposed to mean the value given by the function parameter result [Note to the issue editor: Please use italics for 'result']. This seems somewhat implied by recognizing that both the function parameter and the name used in the clause do have the same italic font. (b) The notion of "result" is supposed to mean the value of result after the preceding effects clause. This is in fact what all implementations I checked do (and which is probably it's intend, because it matches the specification of std::copy). The problem is: I see nothing in the standard which grants that this interpretation is correct, specifically [lib.structure.specifications] or [structure.specifications] resp. do not clarify which "look-up" rules apply for names found in the elements of the detailed specifications - Do they relate to the corresponding synopsis or to the effects clause (or possibly other elements) Fortunately most detailed descriptions are unambigious in this regard, e.g. this problem does not apply for std::copy. Proposed resolution: Change the wording of the return clause to say: Returns: The value of result after effects have taken place. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
VIEWS ON THIS POST

112

Posted on:

Wednesday 7th November 2012
View Replies!

comp.std.c++ report for Mon Oct 1 00:05:00 EST 2007

Subject: comp.std.c++ report for Mon Oct 1 00:05:00 EST 2007 Newsgroups: comp.std.c++ Date: Mon Oct 1 00:05:00 EST 2007 This is an automated report about activity of our newsgroup comp.std.c++. It covers period between the previous report and the current one, ending on Mon Oct 1 00:05:00 EST 2007. Reports are normally issued monthly. Approved: 67 messages (of them, 0 automatically) Rejected: 17 messages Preapproved: 0 new posters --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
VIEWS ON THIS POST

106

Posted on:

Wednesday 7th November 2012
View Replies!

comp.std.c++ report for Sat Sep 1 00:05:00 EST 2007

Subject: comp.std.c++ report for Sat Sep 1 00:05:00 EST 2007 Newsgroups: comp.std.c++ Date: Sat Sep 1 00:05:00 EST 2007 This is an automated report about activity of our newsgroup comp.std.c++. It covers period between the previous report and the current one, ending on Sat Sep 1 00:05:00 EST 2007. Reports are normally issued monthly. Approved: 198 messages (of them, 0 automatically) Rejected: 25 messages Preapproved: 0 new posters --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
VIEWS ON THIS POST

117

Posted on:

Wednesday 7th November 2012
View Replies!

Defect report: [lex.key] and [lex.operators] contradict each other

[lex.key] and [lex.operators] give contradictory information as to the status of new and delete: in [lex.key], they are keywords, but in [lex.operators], they are listed as preprocessing-op-or-punc. This affects the legality of programs such as: #define new 0 int main() { return new ; } If new is a keyword, the above is a legal C++ program; if new is a preprocessing-op-or-punc, it is not. FWIW: g++ treats new as a keyword, which seems like the more reasonable solution (not that it really matters which way we choose). Following this, I would recommend simply removing new and delete from the list of preprocessing-op-or-punc in [lex.operators]. (Note that other keywords, such as the new style casts or typeid, are operators, but don't appear in this table, they don't become operators until phase 7 of translation. I seems reasonable to me to treat new and delete like this as well---I can't quite see anything the preprocessor will do with them.) -- James Kanze (GABI Software) email:james.kanze Conseils en informatique oriente objet/ Beratung in objektorientierter Datenverarbeitung 9 place Smard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34 --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
VIEWS ON THIS POST

132

Posted on:

Wednesday 7th November 2012
View Replies!

comp.std.c++ report for Sun Jul 1 00:05:00 EST 2007

Subject: comp.std.c++ report for Sun Jul 1 00:05:00 EST 2007 Newsgroups: comp.std.c++ Date: Sun Jul 1 00:05:00 EST 2007 This is an automated report about activity of our newsgroup comp.std.c++. It covers period between the previous report and the current one, ending on Sun Jul 1 00:05:00 EST 2007. Reports are normally issued monthly. Approved: 148 messages (of them, 0 automatically) Rejected: 20 messages Preapproved: 0 new posters --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
VIEWS ON THIS POST

128

Posted on:

Wednesday 7th November 2012
View Replies!

Defect report|editorial: Unwanted error in 14.8.2.5/12 example

, both the current 14882-2003 standard as well as the draft N2134 provide the following example in 14.8.2.4/12 and 14.8.2.5/12, resp. template void f(double a[10][i]); int v[10][20]; f(v); //error: argument for template-parameter T cannot be deduced The problem is that additional to the error which is explained here there exists another one, namely that f has a parameter that is an array of double, but the invocation provides an array of int. Proposed resolution: Fix the mentioned example as follows: template void f(int a[10][i]); int v[10][20]; f(v); //error: argument for template-parameter T cannot be deduced P.S.: I could not decide whether this is only editorial or not. Greetings from Bremen, Daniel Krgler --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
VIEWS ON THIS POST

120

Posted on:

Wednesday 7th November 2012
View Replies!

comp.std.c++ report for Sun Apr 1 00:05:00 EST 2007

Subject: comp.std.c++ report for Sun Apr 1 00:05:00 EST 2007 Newsgroups: comp.std.c++ Date: Sun Apr 1 00:05:00 EST 2007 This is an automated report about activity of our newsgroup comp.std.c++. It covers period between the previous report and the current one, ending on Sun Apr 1 00:05:00 EST 2007. Reports are normally issued monthly. Approved: 470 messages (of them, 0 automatically) Rejected: 66 messages Preapproved: 0 new posters --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
VIEWS ON THIS POST

124

Posted on:

Wednesday 7th November 2012
View Replies!

comp.std.c++ report for Thu Mar 1 00:05:00 EST 2007

Subject: comp.std.c++ report for Thu Mar 1 00:05:00 EST 2007 Newsgroups: comp.std.c++ Date: Thu Mar 1 00:05:00 EST 2007 This is an automated report about activity of our newsgroup comp.std.c++. It covers period between the previous report and the current one, ending on Thu Mar 1 00:05:00 EST 2007. Reports are normally issued monthly. Approved: 233 messages (of them, 0 automatically) Rejected: 44 messages Preapproved: 0 new posters --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
VIEWS ON THIS POST

110

Posted on:

Wednesday 7th November 2012
View Replies!

comp.std.c++ report for Tue May 1 00:05:00 EST 2007

Subject: comp.std.c++ report for Tue May 1 00:05:00 EST 2007 Newsgroups: comp.std.c++ Date: Tue May 1 00:05:00 EST 2007 This is an automated report about activity of our newsgroup comp.std.c++. It covers period between the previous report and the current one, ending on Tue May 1 00:05:00 EST 2007. Reports are normally issued monthly. Approved: 262 messages (of them, 0 automatically) Rejected: 34 messages Preapproved: 0 new posters --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
VIEWS ON THIS POST

106

Posted on:

Wednesday 7th November 2012
View Replies!

ifstream eof not reporting eof?

I just did a loop ifstream i(myfile, ios::binary); while (!i.eof()) { i.read(buff, 2); } Well it should have come out of the loop but it tried to do the read operation again... Now... I know I should have checked the ...
VIEWS ON THIS POST

107

Posted on:

Monday 12th November 2012
View Replies!

Defect report / some comments on [rand] and N2391

In the following I comment on several issues in the current [rand] proposal and N2391. Furthermore, it might be of interest to you that I implemented (from scratch) a library that is essentially a superset of [rand], with the exception ...
VIEWS ON THIS POST

95

Posted on:

Sunday 25th November 2012
View Replies!