https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101268
--- Comment #4 from Christopher Yeleighton ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Christopher Yeleighton from comment #0)
> > (I mean patches are not welcome)
>
> Have you actually tried submitting any? I only see bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51539
--- Comment #5 from Christopher Yeleighton ---
Created attachment 51106
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51106=edit
Add Doxygen documentation to items in stl_function.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57840
--- Comment #9 from Christopher Yeleighton ---
(In reply to Jonathan Wakely from comment #8)
> Already fixed in r12-1964
>
> You know doxygen output isn't the only way to look at the code, right?
I thought merged commits refresh the published
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101306
Christopher Yeleighton changed:
What|Removed |Added
Resolution|--- |MOVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97001
--- Comment #3 from Christopher Yeleighton ---
The problem with a module-level @since is that std:: symbols are easiest to
locate in the std namespace (which provides a huge index of everything). Items
that are undocumented (there is a lot of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101268
--- Comment #3 from Christopher Yeleighton ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Christopher Yeleighton from comment #0)
> > (I mean patches are not welcome)
>
> Have you actually tried submitting any? I only see bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101307
--- Comment #1 from Christopher Yeleighton ---
(In reply to Christopher Yeleighton from comment #0)
> 1. Please remove the trailing comma from the title: Variable templates for
> type traits.
The trailing full stop, of course.
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
Target Milestone: ---
1. Please remove the trailing comma from the title: Variable templates for type
traits.
2. The general description (is_foovalue) should be (is_foo ::value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57840
--- Comment #6 from Christopher Yeleighton ---
(In reply to Jonathan Wakely from comment #3)
> I'm not sure why the comment on the primary template doesn't show up (maybe
> doxygen is only interested in a definition) and adding comments to the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57840
--- Comment #5 from Christopher Yeleighton ---
(In reply to Jonathan Wakely from comment #4)
> It shows up in the latest docs:
> https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-api.20210701.html/a03925.
> html
>
> But several other classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101306
--- Comment #2 from Christopher Yeleighton ---
(In reply to Christopher Yeleighton from comment #1)
> Interestingly enough, the problem does not affect https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-api.20210701.html/
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101306
--- Comment #1 from Christopher Yeleighton ---
Interestingly enough, the problem does not affect https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-api.20210701.html/a00209_source.html#l00060
>. It may be a timing issue—the latter document is
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
Target Milestone: ---
When I navigate to a line anchor like #l02373, the following things happen:
1. The source file opens.
2. The source file scrolls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101258
--- Comment #14 from Christopher Yeleighton ---
Will you accept an improvement regarding an issue RESOLVED WONTFIX?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101258
--- Comment #12 from Christopher Yeleighton ---
(In reply to Jonathan Wakely from comment #10)
> Lots of things in our API docs are not in the standard, and lots of things
> in the standard are not in our API docs. If you're trying to use it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101258
--- Comment #8 from Christopher Yeleighton ---
(In reply to Jonathan Wakely from comment #6)
> While it would be nice if the libstdc++ API docs were 100% complete and
> described every piece of the library, that is never going to happen. If you
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
Target Milestone: ---
Since we have given up on documenting all standard library features we have
implemented (I mean patches are not welcome), we should add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101258
--- Comment #7 from Christopher Yeleighton ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Christopher Yeleighton from comment #3)
> > It should at least be present on the API page. The standard is not for
> > developers.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101258
--- Comment #4 from Christopher Yeleighton ---
(In reply to Jonathan Wakely from comment #1)
> It does exactly what the standard says it does. And it's self explanatory.
What is self-explanatory in is_integral_v? It could be "is integral
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101258
--- Comment #3 from Christopher Yeleighton ---
It should at least be present on the API page. The standard is not for
developers.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99909
Christopher Yeleighton changed:
What|Removed |Added
CC||giecrilj at stegny dot 2a.pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96995
--- Comment #6 from Christopher Yeleighton ---
Why wouldn’t locally installed documentation have the API book at the same
relative location?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96995
--- Comment #4 from Christopher Yeleighton ---
Why wouldn’t it work for local documentation?
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
Target Milestone: ---
For example, the documentation for std::cbegin[1] should say:
> Minimum dialect: c++14
___
[1] https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a01544.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96995
--- Comment #2 from Christopher Yeleighton ---
https://gcc.gnu.org/onlinedocs/gcc-10.2.0/libstdc++/manual/manual/../../api/namespaces.html
> would do the trick.
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
Target Milestone: ---
Reading the section "Available Namespaces" [1]:
Actual:
> A complete list of implementation namespaces (including namespace contents)
&
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59687
Christopher Yeleighton giecrilj at stegny dot 2a.pl changed:
What|Removed |Added
Status|RESOLVED
++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
This flag, combined with out or append should have the effect of (fopen (path,
wx)). Now that the syntax (fopen (path, wx)) is standard, there is no
excuse for denying the equivalent functionality
++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
The section Implementation Specific Behavior of The GNU C++ Library Manual
Has:
[18.1]/4 The type of NULL is described here.
Let:
[18.1]/4 The type of NULL is described in Chapter 4.
Has
++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
Chapter Support of The GNU C++ Library Manual
Has:
URL: http://www.awprofessional.com/titles/0-201-92488-9/
Let:
URL:
http://www.informit.com/store/effective-c-plus-plus-55-specific-ways-to-improve-your
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59699
--- Comment #1 from Christopher Yeleighton giecrilj at stegny dot 2a.pl ---
Also, anchor Effective C++ CD only, since the anchor does not link to the
example.
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
The page Backwards Compatibility [1] says:
For output streams, “nocreate” is probably the default, unless you specify
std::ios::trunc ?
Probably??? Could you please estimate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59687
--- Comment #1 from Christopher Yeleighton giecrilj at stegny dot 2a.pl ---
(In reply to Christopher Yeleighton from comment #0)
Also inconsistent with the table at filebuf::open that does not mention x
mode to be actually used.
Oops, scratch
#ad72dc61561f4420b36f9e626b4426433
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
Is:
Table 92, adapted here, gives the relation between openmode
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: giecrilj at stegny dot 2a.pl
Declared at line 00172 .
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52442
Bug #: 52442
Summary: temporary_buffer does not swap
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52442
--- Comment #2 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2012-02-29 23:23:34 UTC ---
(In reply to comment #1)
You're right, it can't be used like that, but it's not meant to be.
By design temporary_buffer is not copyable, so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52442
--- Comment #3 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2012-02-29 23:25:19 UTC ---
(In reply to comment #1)
You're right, it can't be used like that, but it's not meant to be.
By design temporary_buffer is not copyable, so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317
Bug #: 52317
Summary: incorrect FSF address
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: trivial
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52317
--- Comment #6 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2012-02-20 21:54:11 UTC ---
Created attachment 26707
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26707
updates the FSF address in boilerplate comments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51657
Bug #: 51657
Summary: bind1st multiplies a pointer
Classification: Unclassified
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51657
--- Comment #2 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-12-22 21:46:58 UTC ---
The standard is obviously wrong.
URL:
http://groups.google.com/group/comp.std.c++/browse_thread/thread/de856e5116876ff3/b34116c5e51b1d07?lnk=gstq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51657
--- Comment #5 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-12-23 00:45:28 UTC ---
Well, I am astonished at the carelessness of the LWG. If something is plainly
wrong, it should be fixed (which would be trivial in this case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51540
--- Comment #17 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-12-17 17:05:58 UTC ---
The SGI documentation clarifies all issues well enough indeed. I wonder
whether it would be a good thing to put a reference to SGI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51540
--- Comment #12 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-12-16 18:59:31 UTC ---
Additionally, and also for the default operator form, it is unclear what the
result is when the operator is noncommutative. That is, whether y[n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51540
--- Comment #14 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-12-16 20:31:24 UTC ---
I would rather prefer to be able to use gcc (as a software developer) while not
having the ISO standard, which is 1) unreadable with an unarmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51540
Christopher Yeleighton giecrilj at stegny dot 2a.pl changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51539
Bug #: 51539
Summary: multiplies ::operator () undocumented
Classification: Unclassified
Product: gcc
Version: 4.5.1
URL: http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51540
Bug #: 51540
Summary: partial_sum (int *, int *, int *, multiplies int )
does not use operator +(complex, complex)
Classification: Unclassified
Product: gcc
Version: 4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51539
--- Comment #2 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-12-13 23:30:49 UTC ---
(In reply to comment #1)
It returns x*y, which may or may not be the product, the binary operator*
could
be overloaded for Tp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51540
Christopher Yeleighton giecrilj at stegny dot 2a.pl changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50961
Christopher Yeleighton giecrilj at stegny dot 2a.pl changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #8 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-09-27 22:23:34 UTC ---
I agree that this would be an improvement, even without clang's selective
typedef unwrapping. But I have some doubts such a patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50501
Bug #: 50501
Summary: Insertion of complex into a stream may fail without
invalidating the stream
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Christopher Yeleighton giecrilj at stegny dot 2a.pl changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #2 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-09-21 20:06:42 UTC ---
== Code ==
struct X { int x; };
void trigger (X x []) { x [01] = 0; }
== Result (v4.6) ==
doit.cpp:2:34: error: no match for ‘operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #22 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-08-30 13:10:38 UTC ---
(In reply to comment #21)
(In reply to comment #20)
Please publish your result (just one page will do).
I've deleted it now, you can see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #25 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-08-30 13:51:39 UTC ---
Well, the original documentation now shows up in Konqueror after a little
delay, so the original failure might have been due do a network problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #19 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-08-22 19:03:13 UTC ---
(In reply to comment #16)
HTML5 specifies exactly how invalid documents must be parsed (to avoid
security issues with different user-agents
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #20 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-08-22 19:04:50 UTC ---
(In reply to comment #18)
the konqueror rendering problem is NOT caused by the invalid XHTML.
Using the source code and doxygen config in my
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
Bug #: 50143
Summary: Doxygen API documentation is invalid
Classification: Unclassified
Product: gcc
Version: 4.5.1
URL: http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #2 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-08-21 19:33:07 UTC ---
Please tell me if you find the following argument invalid:
1.
It is the responsibility of the library to provide API documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #5 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-08-21 20:41:56 UTC ---
Created attachment 25069
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25069
documentation screen shot
The documentation window contains two
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #6 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-08-21 20:45:29 UTC ---
(In reply to comment #3)
Of course building gcc isn't necessary to run doxygen.
I unpacked gcc and I said { make make doc-html-doxygen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #7 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-08-21 20:49:10 UTC ---
(In reply to comment #4)
Bah, in my opinion, if Doxygen otherwise suits our needs we should just keep
using it and ask users interested in HTML
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #9 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-08-21 20:54:33 UTC ---
(In reply to comment #8)
I don't know which browser you are using, but with Firefox 6 the documentation
is definitely readable.
Konqueror 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #13 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-08-21 21:05:11 UTC ---
(In reply to comment #11)
Doesn't happen here. Anyway, I still believe that a sensible way to go is
filing a Bug Report with Doxygen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49754
Summary: Let gcc warn about all uninitialized variables
Product: gcc
Version: 4.5.1
URL: https://bugzilla.novell.com/show_bug.cgi?id=705160#c1
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49754
--- Comment #2 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-07-15 09:35:42 UTC ---
(In reply to comment #1)
(In reply to comment #0)
== Expected Results ==
foo.c: In function ‘foo’:
foo.c:2:?: warning: ‘x’ is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49754
--- Comment #5 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-07-15 11:00:28 UTC ---
(In reply to comment #3)
(In reply to comment #2)
Since (x) is uninitialized, so is (x.i).
But what if x.i gets initialized, is x still
71 matches
Mail list logo
