--- Comment #66 from hhinnant at apple dot com 2008-11-20 17:40 ---
(In reply to comment #65)
> Subject: Re: exception_defines.h #defines try/catch
>
> No, it doesn't make any sense to use try/catch in a program that you're
> planning to build with -fno-excepti
--- Comment #37 from hhinnant at apple dot com 2007-04-27 14:15 ---
Thanks for looking at this issue.
Also consider Andrew's point about useful diagnostics, for example from comment
#4. And the followup to that point in #33 which includes field experience on
how other compilers
--- Comment #16 from hhinnant at apple dot com 2007-04-15 16:13 ---
(In reply to comment #15)
This makes clean up / rethrow during cancellation awkward. Code would have to
check for two (or more) different kinds of cancellation: Am I executing in an
OS thread, or in a thread pool
--- Comment #5 from hhinnant at apple dot com 2007-02-21 20:17 ---
Russell Yanofsky has submitted a patch implementing N2118:
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01760.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939
--- Comment #15 from hhinnant at apple dot com 2007-02-07 17:22 ---
(In reply to comment #14)
> Unless __value comes from the list, does the standard require
> __a.address(__value) to work?
>
That's a good question Chris. The way I read the current draft, I believe th
--- Comment #13 from hhinnant at apple dot com 2007-02-07 16:59 ---
(In reply to comment #12)
> If we have a utility similar to boost::address_of, that might be better than
> using operator& to get the address of the value_type (to accommodate types
> which overload oper
--- Comment #12 from hhinnant at apple dot com 2007-02-07 16:46 ---
At the ad-hoc LWG meeting in Batavia, Jan 22-24, 2007, the LWG decided that
self referencing code in list::remove must work. Here is a preview of the
issue which is currently set to become official at the Spring &#x
--- Comment #3 from hhinnant at apple dot com 2006-11-29 18:36 ---
Recent work:
http://mndfck.org/~pedro.lamarao/projects/c++0x/
http://home.twcny.rr.com/hinnant/cpp_extensions/rvalue_ref_test/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939
--- Comment #2 from hhinnant at apple dot com 2006-11-22 16:21 ---
If there is a plan, I don't know about it.
Russell Yanofsky has a prototype implementation here:
http://russ.yanofsky.org/rref/
I haven't looked at it enough to know how complete it is. It was done a coupl
--- Comment #14 from hhinnant at apple dot com 2006-11-01 23:33 ---
So swallowing a cancel-exception (in C++) is sometimes the right thing to do.
Imagine a thread pool executing a queue of tasks. These tasks can well have
handles so that clients can wait/join with results in the
To: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29224
Language linkage not part of function type
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
--- Comment #10 from hhinnant at apple dot com 2006-06-19 18:11 ---
It turns out this still isn't quite right. Looks like we need:
#define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) && (DECL_COMMON (decl) \
|| DECL_O
--- Comment #9 from hhinnant at apple dot com 2006-06-13 22:02 ---
(In reply to comment #8)
Thanks. That not only makes sense to me now, but it passes the test. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28017
--- Comment #7 from hhinnant at apple dot com 2006-06-13 21:41 ---
(In reply to comment #6)
> Subject: Re: lack of guard variables for explicitly instantiated template
> static data
>
> > #define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) &&
--- Comment #5 from hhinnant at apple dot com 2006-06-13 21:23 ---
(In reply to comment #4)
>For Darwin we do not want explicit instantiations to be
>linkonce. */
>
>
> This is why this testcase fails on darwin.
> We should instead of just adding DECL_EXPL
ON (decl)))
--
Summary: lack of guard variables for explicitly instantiated
template static data
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assi
return __ret;
}
--
Summary: __basic_file::xsgetn does not deal well with pipes
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
GCC host triplet: Mac OS 10.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27168
.
--
Summary: incorrect codegen for conditional
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinna
--- Comment #13 from hhinnant at apple dot com 2006-01-25 03:24 ---
(In reply to comment #11)
> | Did you read comment 3?
>
> Yes. Is your claim that whether the copy constructor is converting or
> not does not matter?
No. My suspicion is that there is a 99.99% chance
--- Comment #9 from hhinnant at apple dot com 2006-01-25 02:54 ---
(In reply to comment #8)
> Changing to request for enhancement. The requested behaviour is a change
> in th working paper. Existing behaviour is what is required by the standard
> (even when it can be ar
--- Comment #6 from hhinnant at apple dot com 2006-01-25 02:05 ---
At the risk of continuing off-topic...
Thank you Andrew for your continuing prompt and high quality work. It is a
very valuable service and I've never had any complaints with the way you
provide it. Good Job and
--- Comment #3 from hhinnant at apple dot com 2006-01-24 22:51 ---
More information:
I now believe I unknowingly misled when I surmized that EDG had implemented cwg
391. If you declare the copy ctor private in the example, EDG rejects g(X())
based on accessibility. Rather I am now
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25950
--- Comment #4 from hhinnant at apple dot com 2006-01-22 20:49 ---
(In reply to comment #3)
> (3) even when isnormal is enable-if hacked, you still potentially
> run into the same problem.
For example?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25913
--- Comment #2 from hhinnant at apple dot com 2006-01-22 20:25 ---
(In reply to comment #1)
>
> Does the problem exist if you configure with --disable-c99?
I haven't tried that configuration. The docs say that setting may change
libstdc++'s ABI.
So this is expected
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25913
ssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25894
--- Comment #33 from hhinnant at apple dot com 2006-01-12 02:49 ---
(In reply to comment #32)
> As I said before, there is still a diagnostic issue and now it is worse
> with
> doing that in the front-end since people don't read docs that well so
> we will
> be
--- Comment #29 from hhinnant at apple dot com 2006-01-12 00:59 ---
(In reply to comment #28)
> Subject: Re: exception_defines.h #defines try/catch
>
> | No, "try" in this context is not a keyword.
>
> I did not say it was a keyword. I know what it is in t
--- Comment #26 from hhinnant at apple dot com 2006-01-11 18:02 ---
(In reply to comment #25)
> Subject: Re: exception_defines.h #defines try/catch
> | The demo program does not play tricks with try/catch.
>
> It does, with xlgue(try, ).
No, "try" in this co
--- Comment #24 from hhinnant at apple dot com 2006-01-11 16:10 ---
(In reply to comment #23)
> You forgot to mentin that -fno-exceptions is neither mandated, nor
> required to work with programs that play tricks with try/catch.
> So, your assertion is unfounded.
The demo pro
--- Comment #22 from hhinnant at apple dot com 2006-01-11 15:30 ---
Conforming C++ programs exist that work correctly with -fno-exceptions as long
as they don't include any libstdc++ header. These same programs can fail (at
either compile time or run time) if they also include
--- Comment #4 from hhinnant at apple dot com 2005-12-17 22:01 ---
Agreed, (that's brutal ;-) ).
Sorry about the duplicate. My clumsy fingers hit refresh on my browser and
that generated the duplicate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466
ity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25467
ity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466
--- Comment #19 from hhinnant at apple dot com 2005-12-06 01:19 ---
(In reply to comment #17)
> Subject: Re: exception_defines.h #defines try/catch
>
> "hhinnant at apple dot com" <[EMAIL PROTECTED]> writes:
>
> | I don't know what that means. Or
--- Comment #18 from hhinnant at apple dot com 2005-12-04 15:55 ---
(In reply to comment #15)
> Subject: Re: exception_defines.h #defines try/catch
> It is also a simple fact
> that GCC documents what happens with -fno-exceptions.
I'm trying to find this documentatio
--- Comment #16 from hhinnant at apple dot com 2005-12-04 02:12 ---
(In reply to comment #15)
> Subject: Re: exception_defines.h #defines try/catch
>
> I don't think anybody is disputing that. It is also a simple fact
> that GCC documents what happens with -fno-exc
--- Comment #14 from hhinnant at apple dot com 2005-12-03 01:25 ---
(In reply to comment #13)
> Subject: Re: exception_defines.h #defines try/catch
>
> I'm saying that if you're intending to use try/catch and yet not
> want what the mean in standard C++, nor w
--- Comment #11 from hhinnant at apple dot com 2005-12-02 21:21 ---
(In reply to comment #10)
> (In reply to comment #9)
> > Not being someone with a lot of FE experience, I have more hesitation about
> > this latter approach.
>
> That solution still does not
--- Comment #9 from hhinnant at apple dot com 2005-12-02 21:00 ---
(In reply to comment #8)
> Subject: Re: exception_defines.h #defines try/catch
>
> "hhinnant at apple dot com" <[EMAIL PROTECTED]> writes:
>
> | ------- Comment #5 from hhinnant at
--- Comment #5 from hhinnant at apple dot com 2005-12-02 19:07 ---
(In reply to comment #2)
> I'd rather you work around this in objective-c or objective c++.
How? I'm open to suggestions.
-Howard
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #5 from hhinnant at apple dot com 2005-11-12 19:02 ---
> (1) Strong-arm a C++ front-end guru into implementing rvalue references,
> then use them in the TR1 function objects. Heck, we'll need 'em
> for C++0x anyway :)
At the risk of b
mary: Non ambiguous typedefs
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24758
46 matches
Mail list logo
