--- Comment #1 from chris at bubblescope dot net 2006-05-10 11:31 ---
Can you provide a complete program which demonstrates this link? I've tried
looking at the code in question myself, and cannot observe a memory leak
myself.
--
chris at bubblescope dot net ch
--- Comment #7 from chris at bubblescope dot net 2006-06-23 15:33 ---
(In reply to comment #4)
> Subject: Re: header dependencies
>
> On Monday 19 June 2006 11:29, pcarlini at suse dot de wrote:
> > --- Comment #1 from pcarlini at suse dot de 2006-06-19 09:29
&g
--- Comment #9 from chris at bubblescope dot net 2006-06-23 16:47 ---
I just tried preprocessing vector, as an example. There isn't any obvious
low-hanging fruit. The major problem is that most of the C standard libary ends
up getting dragged in.
I think a better goal would be to
--- Comment #1 from chris at bubblescope dot net 2008-12-09 23:30 ---
I agree with you, but unfortunatly the standard doesn't allow std::swap to be
defined for std::pair. Stupid I know.
C++0x does require that.
--
chris at bubblescope dot net changed:
What|Re
--- Comment #3 from chris at bubblescope dot net 2008-12-10 12:23 ---
Sorry, I should have been clearer. the standard forbids this overload of swap
by not listing it, unlike most other standard library types, which is lists an
overload for.
Personally, I'd be happy to just ad
--- Comment #67 from chris at bubblescope dot net 2008-12-19 11:45 ---
Sorry to come back to this again. With C++0x just around the corner, is there
any chance of getting this fixed, seeing as I expect this should be the
standard way of checking if we are in conforming C++0x mode, when
--- Comment #3 from chris at bubblescope dot net 2005-11-21 16:03 ---
While it does look like there might be an error in this warning code, I also
have a feeling we are doing something bad here. I looked at the examples in
stl_set.h and we are doing reference casting from a
FIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
--- Comment #2 from chris at bubblescope dot net 2005-11-28 15:17 ---
Thats an option too, but I thought I'd see about gcc's opinion first, as I
expected a much faster reply than I would get from the C++ steering committee
:)
I find the warning helpful for constructs like:
--- Comment #5 from chris at bubblescope dot net 2005-11-28 16:28 ---
I'll make a report. Don't worry, I'm clear on the difference between tr1::array
and a C array, I just wanted to check that we agree this should produce a
warning (in which case I will go through
--- Comment #6 from chris at bubblescope dot net 2005-11-28 16:33 ---
Actually, is a report really approriate? Writing array = {1,2,3} is
perfectly valid C++, just warned about with -Wmissing-braces
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
--- Comment #17 from chris at bubblescope dot net 2006-01-04 13:53 ---
Just as a quick note, I've personally got code using the non-void return value
of generate_n (because I'm going along a list, and didn't want to have to
incremement n steps after filling the list, as
--- Comment #2 from chris at bubblescope dot net 2006-01-10 10:37 ---
I'm unclear on why it should be convertable to one of the built-in integral
types at all.. surely saying that
iterator_traits<_OutputIterator>::difference_type (where _OutputIterator is the
first param
--- Comment #4 from chris at bubblescope dot net 2006-01-10 17:00 ---
For the record, I was thinking of:
template
_OutputIterator
fill_n(_OutputIterator __first, _Size __n, const _Tp& __value)
{
iterator_traits<_OutputIterator>::difference_ty
Summary: Poor error when templating on undefined types
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris
--- Comment #1 from chris at bubblescope dot net 2006-01-11 17:21 ---
This bug is fixed in 4.1 (and possibly 4.0, I don't have a copy). Is suspect it
isn't a serious enough bug to get the fix backported to 3.4 (although others
may know better than me)
--
http://gcc.gnu.or
--- Comment #3 from chris at bubblescope dot net 2006-01-17 18:09 ---
Does that patch break other systems? (linux-x86 would seem the obvious thing to
try..)
--
chris at bubblescope dot net changed:
What|Removed |Added
--- Comment #6 from chris at bubblescope dot net 2006-07-29 10:08 ---
My natural suspision would be that your clone() function is incorrectly
implemented. Can you show us the source to the CMessage object, and
theMessageFactory.createInstance(
)?
--
http://gcc.gnu.org/bugzilla
--- Comment #8 from chris at bubblescope dot net 2006-08-03 19:48 ---
One quick piece of advice. Have you tried compiling your entire application
against the libstdc++ debug mode? It might help narrow down where the problem
is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27530
--- Comment #3 from chris at bubblescope dot net 2006-09-20 09:50 ---
Actually, I think deque could do with a better max_size.
Some tests:
vector v;
v.resize(v.max_size());
Throws bad_alloc.
deque v;
v.resize(v.max_size());
Bus errors.
This is on i686-apple-darwin8, 4.0.1 Apple&#
--- Comment #5 from chris at bubblescope dot net 2006-09-20 10:15 ---
The reason I bought this up here, is because I thought (and I could be wrong,
sorry) that the overflow was being caused by the fact that we allow the
container size to get too big, and if we pull max_size() down to a
--- Comment #8 from chris at bubblescope dot net 2006-09-20 11:10 ---
I agree also we can't do any better. On 64 bit systems it will be even harder
to give anything sensible.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
--- Comment #14 from chris at bubblescope dot net 2007-02-07 17:12 ---
Unless __value comes from the list, does the standard require
__a.address(__value) to work?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17012
t org
ReportedBy: chris at bubblescope dot net
GCC host triplet: i686-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30800
--- Comment #2 from chris at bubblescope dot net 2007-02-14 22:36 ---
Ah, sorry, you are right. I stared at this for ages trying to figure out what
it could mean. Sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30800
--- Comment #2 from chris at bubblescope dot net 2007-03-17 17:19 ---
Depending on how you read it, 24.3.1 looks to me like it might require that. It
says that iterator_traits is defined to include:
typedef typename Iterator::value_type value_type;
and that it is specialised for
--- Comment #3 from chris at bubblescope dot net 2007-03-17 17:46 ---
This is a general problem I've come across with templates. You commonly want to
try/catch around some operation, but when you have templated on a simple type,
like int, then it's easy to find out that no th
--- Comment #4 from chris at bubblescope dot net 2007-03-17 17:52 ---
The main problem I can see with changing this is that you would have to decide
if you were going to remove the same options from the iterators of all other
standard containers. To not do so would seem to be
--- Comment #4 from chris at bubblescope dot net 2007-03-17 18:07 ---
Here is a minimal code example:
#include
int* get_ptr(void* ptr)
{
return new(ptr) int();
}
Which gives (on my computer)
/usr/include/c++/4.0.0/new: In function 'int* get_ptr(void*)':
/usr/include/c++
--- Comment #1 from chris at bubblescope dot net 2007-04-12 19:37 ---
There is also a large number of other places which do "!pred" in various
functions
I believe there are other bugs of this type, relating to && and ||. If someone
really cared about this, they c
--- Comment #4 from chris at bubblescope dot net 2007-04-12 20:36 ---
Thats my understanding yes.
It might possibly at the same time be worth fixing predicates appears in && and
||, which have to be changed into nested ifs I think.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #5 from chris at bubblescope dot net 2007-04-17 16:48 ---
I've done a bit of research into this. Looks like, as Andrew says the standard
doesn't have much to say on the issue. Any method of removing this is going to
make some other things a bit more messy I th
--- Comment #2 from chris at bubblescope dot net 2007-07-26 19:41 ---
Ah, woops, many apologises. Too long since I've looked at list::size, I forgot
which way around libstdc++ differed from the rest of the world :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32907
--
chris at bubblescope dot net changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32908
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32908
libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32907
: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
--
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
--- Additional Comments From chris at bubblescope dot net 2005-03-10 16:00
---
ignore my random changing of severity..
--
What|Removed |Added
Severity|minor
--- Additional Comments From chris at bubblescope dot net 2005-03-10 16:05
---
When you say "has no effect in final code", are you talking about the problem
you noticed, or the problem as a whole?
I find for each extra X I add to the type of foo I get a line much like:
mo
nedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20411
Summary: gcov default behaviour changed
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
--- Additional Comments From chris at bubblescope dot net 2005-03-20 12:45
---
As soon as I've submitted this bug, I've found the documentation notes this
change.. I would still ask is there a way to get back the earlier behaviour?
--
http://gcc.gnu.org/bugzilla/show_
Summary: gcov default behaviour changed
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
Summary: gcov default behaviour changed
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
--- Additional Comments From chris at bubblescope dot net 2005-03-20 13:02
---
Stupid webbrowser ¬_¬
*** This bug has been marked as a duplicate of 20564 ***
--
What|Removed |Added
--- Additional Comments From chris at bubblescope dot net 2005-03-20 13:02
---
*** Bug 20565 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20564
--- Additional Comments From chris at bubblescope dot net 2005-03-20 13:03
---
Stupid webbrowser ¬_¬
*** This bug has been marked as a duplicate of 20564 ***
--
What|Removed |Added
--- Additional Comments From chris at bubblescope dot net 2005-03-20 13:03
---
*** Bug 20566 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20564
--- Additional Comments From chris at bubblescope dot net 2005-03-21 10:14
---
(Hmm.. I thought I posted this before..)
My personal problem isn't the lines beginning zero, but the ones like:
function _Z3fooIiEiT_ called 1 returned 100% blocks executed 75%
Which before I had to
--- Additional Comments From chris at bubblescope dot net 2005-03-21 19:00
---
This program may make it a bit clearer what is going on :) (the problem is your
code I'm afraid, the compiler is fine)
#include
#include
struct VAR {
VAR() {printf("VAR created\n");}
~VAR
--- Additional Comments From chris at bubblescope dot net 2005-03-29 19:19
---
A friend of mine was recently caught by this bug.. is there any chance it could
be fixed now? or is there still some problem holding it up (or just no-one
cares?). Although I am by no means certain, I imagine
--- Comment #6 from chris at bubblescope dot net 2008-03-06 17:11 ---
While I agree that this is an issue of implementation detail, I thought there
was code already there to stop this case, except it is broken :(
Looking at the svn copy of tr1/tuple, you can see operator== (and others
--- Comment #9 from chris at bubblescope dot net 2008-03-09 20:28 ---
Sorry to be pedantic, but could this be added to _GLIBCXX_DEBUG_PEDANTIC. I've
previously tended to assume that _GLIBCXX_DEBUG should change only flag code
that should fail in non-debug mode, but fails to be det
--- Comment #2 from chris at bubblescope dot net 2008-03-11 17:08 ---
This used to work (works on Apple's gcc 4.0.1).
The bug is an inconsistency between __check_sorted_set on lines 317 and 334 and
the __check_sorted_set_aux on the lines before
The 4 __check_sorted_set_aux me
--- Comment #3 from chris at bubblescope dot net 2008-03-11 17:12 ---
While I'm sure he will be along soon anyway, I shall add Paolo to the CC list
of this bug.
It looks to me like a simple typo was made while fixing 34730.
--
chris at bubblescope dot net changed:
--- Comment #2 from chris at bubblescope dot net 2008-03-18 15:02 ---
#include
#include
using namespace std;
int main(void)
{
vector > v;
}
Runs fine here, using:
Using built-in specs.
Target: i386-apple-darwin9.2.0
Configured with: ../gcc/configure --enable-languages=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56367
Bug #: 56367
Summary: unordered containers behave badly with NaN
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: minor
--- Comment #1 from chris at bubblescope dot net 2009-09-14 07:24 ---
In C++0x, this problem will go away, because move constructors will be used,
which leads to the most efficient implementation for both large and small types
(assuming they implement a move constructor at least as
--- Comment #5 from chris at bubblescope dot net 2009-09-14 17:00 ---
You cannot assume the elements you are sorting have a default constructor. You
can however certainly use a separate array of indices, and then swap at the
end, so I withdraw that comment. However, this also only
--- Comment #7 from chris at bubblescope dot net 2009-09-14 18:11 ---
Only a svn copy of stl_algo.h has the rvalue reference stuff for
stable_partition. We use a number of macros, like _GLIBCXX_MOVE, to wrap
various parts of the algorithms, so they work in both c++03 and c++0x.
It is a
--- Comment #19 from chris at bubblescope dot net 2009-09-15 14:45 ---
I think this generally looks good. The testsuite could do with some
improvement, there are quite a lot of cases for this algorithm, and it's
probably worth testing they all work properly.
I unfortunately
--- Comment #8 from chris at bubblescope dot net 2009-09-29 11:04 ---
Just to clarify, it is not a memory leak which is occurring, it is memory
corruption. Basically when std::sort is given a type which is not totally
ordered as required, it tends to corrupt the memory immediately
--- Comment #26 from chris at bubblescope dot net 2009-10-04 21:50 ---
Just to follow up on an earlier comment, I've tested this patch with a new
improved std::rotate test (to be submitted shortly) which tests all rotations
and positions up to length 20, and it passes fine. Furthe
rong.
--
Summary: Massive failures in parallel test mode
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
Rep
--- Comment #2 from chris at bubblescope dot net 2009-10-09 12:57 ---
I shall try to track it down -- it wouldn't suprise me if this is a snow
leopard bug, as there has been a few issues with the default system compiler
switching from 32-bit to 64-bit.
--
chris at bubblescop
--- Comment #4 from chris at bubblescope dot net 2009-10-09 13:21 ---
I have confirmed that after compiling with 'make check-parallel', the code:
#include
int main(void)
{ string s; s = "X"; }
Fails when compiled with:
/gccsvn/bin/g++ test.cc libtestc++.a -fop
--- Comment #6 from chris at bubblescope dot net 2009-10-09 14:16 ---
Ah yes, something I should have tried earlier.
The resulting compiler generally works fine, until I add -D_GLIBCXX_PARALLEL,
when things break.
I only seem to get a problem when I have enough optimisation to inline
--- Comment #7 from chris at bubblescope dot net 2009-10-09 14:20 ---
Further: If I add -D_GLIBCXX_FULLY_DYNAMIC_STRING, the code compiles fine!
However, if I run otool on my executable, it says it is linked with:
Load command 10
cmd LC_LOAD_DYLIB
cmdsize 64
--- Comment #10 from chris at bubblescope dot net 2009-10-09 15:10 ---
To sum up the current state, as things are getting confusing:
Compiling 'testsuite/21_strings/basic_string/inserters_extractors/char/1.cc -I
testsuite/util -O2'
using /newgccsvn/bin/g++ (recent svn compil
--- Comment #12 from chris at bubblescope dot net 2009-10-09 17:51 ---
LD_LIBRARY_PATH doesn't exist on Mac. Usually linking libraries together 'just
works', but in this case it seems to have broken.
By configuring with --enable-fully-dynamic-string, I get a working com
--- Comment #4 from chris at bubblescope dot net 2009-10-22 23:14 ---
The reason that in general changing the Point a std::multiset::iterator
refers to is forbidden is that doing so will break the invariant on which the
multiset is based, resulting in random crashes occuring later on
--
Summary: constant initializer_list not optimised
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bu
--- Comment #2 from chris at bubblescope dot net 2009-11-10 08:14 ---
Sorry, one important thing I missed off my bug report. This problem seems to
just be connected to constant lists. The following is fully optimised away
int i = 1, j = 2;
return max_val({i,j});
As is the following
ormal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chris at bubblescope dot net
The following code (notice the function takes a long long, the template takes
an int. This code is invalid)
template
struct S {};
template
void g(S);
v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
--- Comment #4 from Chris Jefferson ---
Just to say I see this, and fortunately it's not hard to keep the optimisation
and meet the complexity requirements.
Expect patch later today.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
--- Comment #6 from Chris Jefferson ---
I have a patch I believe fixes this, but trunk doesn't currently build on my
machine (Bug 58340). I'll wait for that to get fixed.
It is annoying there is still separate predicate and non-predicate copies o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
--- Comment #13 from Chris Jefferson ---
Created attachment 30767
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30767&action=edit
Bug patch
Patch attached.
This features:
1) As well as checking backwards when we find a match, check forwar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
--- Comment #14 from Chris Jefferson ---
(In reply to Marc Glisse from comment #12)
> Chris, did you consider applying this optimized code to bidirectional
> iterators and not just random access iterators? We may end up doing a few
> more ++/-- th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
--- Comment #19 from Chris Jefferson ---
(In reply to Mitsuru Kariya from comment #15)
> Created attachment 30775 [details]
> Patch
>
> For your convenience, I attached a patch for this problem.
>
> This algorithm is always scanned to reverse or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
--- Comment #22 from Chris Jefferson ---
Her are some comparisons. Just to compare, I also checked doing away with
skipping optimisations altogether. Binary sizes (-O3, stripped)
current head: 11928
my code: 12248
Mitsuru: 11384
No ski
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437
--- Comment #7 from Chris Jefferson ---
I will look at this next week. Quicksorts are always suboptimal for mostly
sorted (forwards or backwards) data, and it would be nice to fix that.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437
--- Comment #13 from Chris Jefferson ---
Created attachment 30861
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30861&action=edit
Sort patch
Wow, this an embarrassing bug to get through testing. Obviously not enough
profiling done!
This pa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437
--- Comment #16 from Chris Jefferson ---
Indeed, if std::sort had never used lower-level partitioning to get the pivot
in the correct location, we would never have had this problem in the first
place!
This is not too serious a problem performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437
--- Comment #20 from Chris Jefferson ---
Created attachment 30867
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30867&action=edit
Performance tests for sort
This is some performance tests for performance checking. Sorry for tar rather
than
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50462
Bug #: 50462
Summary: Particularly painful error message
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53046
--- Comment #6 from Chris Jefferson 2012-04-23
09:44:11 UTC ---
Yes, will check.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53046
--- Comment #7 from Chris Jefferson 2012-04-23
09:57:12 UTC ---
While I haven't yet got a recent copy of gcc trunk compiled, it does indeed
look like an out-of-bounds error, but just a 'testsuite' problem.
At the top of both mem_check tests as a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53046
--- Comment #9 from Chris Jefferson 2012-04-23
10:54:57 UTC ---
Looking at the output of -fdump-tree-all, it looks like the compiler optimises
the loop which accesses an array out of bounds to:
while(true);
Is this expected behaviour? That seem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57916
Chris Jefferson changed:
What|Removed |Added
CC||chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557
--- Comment #2 from Chris Jefferson ---
Investigating
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557
--- Comment #3 from Chris Jefferson ---
Can I just confirm I am testing this code correctly?
caj@caj-laptop ~/Downloads> g++ BVH_Example.cpp -O0
caj@caj-laptop ~/Downloads> ./a.out
Brute force distance = 0.00428018, calls = 1
BVH distance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557
--- Comment #5 from Chris Jefferson ---
Also tried with svn head, the code works (and passes using valgrind as well)
caj@caj-laptop ~/Downloads> /gcc-svn/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/gcc-svn/bin/g++
COLLECT_LTO_WRAPPER=/gcc-svn/l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557
--- Comment #6 from Chris Jefferson ---
Wait a minute, I am getting my timeline wrong, sorry.
This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58800 , which will be fixed
for 4.8.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557
--- Comment #10 from Chris Jefferson ---
It's a dup -- debian have backported the fix to 4.8.2.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183
Chris Jefferson changed:
What|Removed |Added
CC||chris at bubblescope dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183
--- Comment #10 from Chris Jefferson 2011-12-05
16:25:13 UTC ---
Oh, and one other tiny detail, I've about given up trying to understand corner
cases in the name look-up rules in C++, so I'd probably std:: qualify those
'get's, just to be on the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183
--- Comment #9 from Chris Jefferson 2011-12-05
16:19:40 UTC ---
The only difference in the version I wrote was that I passed the arguments into
the explicit constructor as non-const references, rather than by value with
std::move, which should be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183
--- Comment #13 from Chris Jefferson 2011-12-06
10:13:56 UTC ---
You can if you like, but if you haven't started yet, I plan on having a patch
ready in about... 2 hours?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183
--- Comment #16 from Chris Jefferson 2011-12-06
14:25:24 UTC ---
Created attachment 26006
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26006
Piecewise patch
Patch to make piecewise_construct work properly on std::pair.
1 - 100 of 213 matches
Mail list logo
