[Bug libstdc++/45488] New: lower_bound iterator must be default constructible
First of all, I understand that this is a requirement imposed by the Standard.
However, the requirement, in general, is valid only for iterators that do not
refer to any container. This is not the case with iterators useful in
algorithms; the default value of such an iterator has no meaning.
Moreover, the implementation of the library has no obligation to check this
trait for every algorithm, and I suggest that this check should be removed.
The code for std::lower_bound does not use this feature in a meaningful way,
and it is straightforward to fix.
The patch below, apart from fixing the problem, also replaces iterator with
std::iterator.
templatetypename _ForwardIterator, typename _Tp
_ForwardIterator
lower_bound(_ForwardIterator __first, _ForwardIterator __last,
const _Tp __val)
{
typedef typename std:: iterator_traits_ForwardIterator::value_type
_ValueType;
typedef typename std:: iterator_traits_ForwardIterator::difference_type
_DistanceType;
// concept requirements
__glibcxx_function_requires(_ForwardIteratorConcept_ForwardIterator)
__glibcxx_function_requires(_LessThanOpConcept_ValueType, _Tp)
__glibcxx_requires_partitioned_lower(__first, __last, __val);
_DistanceType __len = std:: distance(__first, __last);
_DistanceType __half;
while (__len 0)
{
_ForwardIterator __middle ((__first));
__half = __len 1;
std::advance(__middle, __half);
if (*__middle __val)
{
__first = __middle;
++__first;
__len = __len - __half - 1;
}
else
__len = __half;
}
return __first;
}
--
Summary: lower_bound iterator must be default constructible
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: giecrilj at stegny dot 2a dot pl
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45488
[Bug c++/45490] New: Confusing error message for local type arguments
#include algorithm
void foo (void)
{
class my_iter:
public std:: iterator std:: random_access_iterator_tag, int
{ public: operator int * (void) const { return NULL; }};
std:: distance (my_iter (), my_iter ()); }
Compiling this code, you get:
error: no matching function for call to #8216;distance(foo()::my_iter,
foo()::my_iter)#8217;
This message is highly confusing.
Both Intel and Comeau give the following message:
a template argument may not reference a local type
(Microsoft groks the construct all right.)
--
Summary: Confusing error message for local type arguments
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: giecrilj at stegny dot 2a dot pl
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45490
[Bug libstdc++/45488] lower_bound iterator must be default constructible
--- Comment #4 from giecrilj at stegny dot 2a dot pl 2010-09-01 22:34
---
== Test case ==
#include cassert
#include algorithm
namespace BUG45488 {
class my_iter:
public std:: iterator std:: random_access_iterator_tag, char const
{ private: typedef my_iter ref;
private: pointer m_ptr;
public: typedef std:: less value_type compare;
public: my_iter (pointer p_ptr): m_ptr (p_ptr) {}
public: operator pointer (void) const { return this - m_ptr; }
public: ref operator ++ (void) { ++this - m_ptr; return *this; }
public:
ref operator += (difference_type p_d)
{ this - m_ptr += p_d; return *this; }};
void test (void) {
static char const sc_test [] = { 'a', 'c' };
assert
(std:: lower_bound (my_iter (sc_test), my_iter ((sc_test) [01]), 'a')
== my_iter (sc_test));
assert
(std:: lower_bound
(my_iter (sc_test), my_iter ((sc_test) [01]), 'a', my_iter:: compare ())
== my_iter (sc_test));
assert
(std:: upper_bound (my_iter (sc_test), my_iter ((sc_test) [01]), 'a')
== my_iter (sc_test) + 01);
assert
(std:: upper_bound
(my_iter (sc_test), my_iter ((sc_test) [01]), 'a', my_iter:: compare ())
== my_iter (sc_test) + 01);
}
}
== Patch ==
*** /usr/include/c++/4.4/bits/stl_algo.h2009-10-23 23:19:15.0
+0200
--- bits/stl_algo.h 2010-09-02 00:13:09.200742054 +0200
*** _GLIBCXX_BEGIN_NAMESPACE(std)
*** 2432,2443
_DistanceType __len = std::distance(__first, __last);
_DistanceType __half;
- _ForwardIterator __middle;
while (__len 0)
{
__half = __len 1;
- __middle = __first;
std::advance(__middle, __half);
if (*__middle __val)
{
--- 2432,2442
_DistanceType __len = std::distance(__first, __last);
_DistanceType __half;
while (__len 0)
{
+ _ForwardIterator __middle = __first;
__half = __len 1;
std::advance(__middle, __half);
if (*__middle __val)
{
*** _GLIBCXX_BEGIN_NAMESPACE(std)
*** 2485,2496
_DistanceType __len = std::distance(__first, __last);
_DistanceType __half;
- _ForwardIterator __middle;
while (__len 0)
{
__half = __len 1;
- __middle = __first;
std::advance(__middle, __half);
if (__comp(*__middle, __val))
{
--- 2484,2494
_DistanceType __len = std::distance(__first, __last);
_DistanceType __half;
while (__len 0)
{
+ _ForwardIterator __middle = __first;
__half = __len 1;
std::advance(__middle, __half);
if (__comp(*__middle, __val
[Bug libstdc++/45488] lower_bound iterator must be default constructible
--- Comment #6 from giecrilj at stegny dot 2a dot pl 2010-09-01 22:39 --- BTW, why is this implementation so repetitive? What would be wrong with saying lower_bound (a_, b_, c_) := lower_bound (a, b, c, less ())? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45488
[Bug libstdc++/45488] lower_bound iterator must be default constructible
--- Comment #8 from giecrilj at stegny dot 2a dot pl 2010-09-01 22:42 --- (In reply to comment #5) We are not adding testcases here, because a forward iterator must be default constructible. On the other hand, unless we are talking concepts and forcing, the standard library is not prohibited from handling correctly cases when the type passed as forward iterator is not default constructible and the requirement is bogus. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45488
[Bug c++/43453] Initialization of char array with string literal fails in mem-initializer
--- Comment #1 from giecrilj at stegny dot 2a dot pl 2010-08-27 18:06
---
(In reply to comment #0)
Fails to compile, but should work:
struct A {
char x[4];
A():x(bug) { }
};
Error i get is:
main.cpp:3: error: array used as initializer
Why do you think it should work?
For example, the following equivalent code is invalid as well:
char x [4] (bug);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43453
[Bug c++/45431] New: initializer-string for array of chars is too long: which one?
== Steps to reproduce ==
#!/bin/sh
# 1. Create the source file
cat 'bugpp.cpp' '/* EOF */'
struct personal_data
{ char name [01]; char surname [01]; }
const sc_me = {
Christopher,
Yeleighton };
/* EOF */
# 2. Compile as C++
make 'bugpp'
# 3. Compile as C
mv 'bugpp.cpp' 'bug.c'
make 'bug'
== Expected results (from gcc) ==
cc bug.c -o bug
bug.c:4: warning: initializer-string for array of chars is too long
bug.c:4: warning: (near initialization for #8216;sc_me.name#8217;)
bug.c:5: warning: initializer-string for array of chars is too long
bug.c:5: warning: (near initialization for #8216;sc_me.surname#8217;)
== Actual results (from g++) ==
g++ bugpp.cpp -o bugpp
bugpp.cpp:5: error: initializer-string for array of chars is too long
bugpp.cpp:5: error: initializer-string for array of chars is too long
== Essential differences ==
* The first line number should be 4
* g++ fails to indicate the failing data field
== Why this is important ==
Ordinary bugs in error messages should be marked as enhancement; however,
this one is particularly nasty. It is very difficult to identify the cause of
error when compiling long data initialisation statements using g++ because the
error message does not contain the line number or the position in the
structure.
== See also ==
* Bug 31158
== Version information ==
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.4
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.4
--enable-linux-futex --without-system-libunwind --with-arch-32=i586
--with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux)
--
Summary: initializer-string for array of chars is too long: which
one?
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: giecrilj at stegny dot 2a dot pl
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45431
[Bug c++/45431] initializer-string for array of chars is too long: which one?
--- Comment #2 from giecrilj at stegny dot 2a dot pl 2010-08-27 20:58 --- #9 0x00442a5e in digest_init_r (type=0x7618ac00, init=0x7617c4c0, nested=1 '\001') at ../../gcc/cp/typeck2.c:785 785 permerror (input_location, initializer-string for array of chars is too long); (gdb) l 780 /* In C it is ok to subtract 1 from the length of the string 781 because it's ok to ignore the terminating null char that is 782 counted in the length of the constant, but in C++ this would 783 be invalid. */ 784 if (size TREE_STRING_LENGTH (init)) 785 permerror (input_location, initializer-string for array of chars is too long); 786 } 787 return init; 788 } 789 } Symbol input_location is static storage. The function digest_init_r does not modify it in any way. It is an oblique index (601), to be resolved by linemap_lookup in line_table. If my investigation is correct, in this particular case it would be 1 + 601 7 == line 5 This particular value is assigned by the function cp_lexer_set_source_position_from_token, specifically from token-location. The stack: #0 cp_lexer_consume_token (lexer=0x7617c340) at ../../gcc/cp/parser.c:662 #1 0x004647f7 in cp_parser_braced_list (parser=0x77e84730, non_constant_p=0x7fffdb9e ) at ../../gcc/cp/parser.c:14692 #2 0x0046b07c in cp_parser_init_declarator (parser=0x77e84730, decl_specifiers=0x7fffdbf0, checks=value optimized out, function_definition_allowed_p=value optimized out, member_p=0 '\000', declares_class_or_enum=value optimized out, function_definition_p=0x7fffdc5f ) at ../../gcc/cp/parser.c:12893 The function cp_parser_init_declarator later calls cp_finish_decl (./../gcc/cp/parser.c:12929), which is where the error is reported. The error reporting code incorrectly assumes that the offending line is stored in the global input_location, which at the moment corresponds to the location of the closing brace. However, it seems that after the init tree has been constructed, the tokens are gone, and so is line number information. In conclusion, I think the easiest way to fix this problem (and perhaps other similar ones) would be to add line number information from the original tokens to the init tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45431
[Bug libstdc++/44014] New: no std::string in API documentation
Reading the autogenerated API documentation page [1], there are the following typedefs starting with s: * seconds : std::chrono * sregex_token_iterator : std * ssub_match : std * streambuf : std * streamoff : std * streampos : std * streamsize : std * stringbuf : std * stringstream : std * syntax_option_type : std::regex_constants Where is std::string? [1] URL:http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/namespacemembers_type.html#index_s -- Summary: no std::string in API documentation Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: giecrilj at stegny dot 2a dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44014
[Bug libstdc++/44015] New: template parameters not documented
Reading the page std::basic_string _CharT, _Traits, _Alloc Class Template Reference [1]: The template parameters are not documented; in particular, their default assignments are not mentioned. [1] URL:http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00260.html#_details -- Summary: template parameters not documented Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: giecrilj at stegny dot 2a dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44015
