On 23/11/2012, Basile Starynkevitch wrote:
> On Thu, Nov 22, 2012 at 09:29:43PM +0100, Florian Weimer wrote:
>> On 11/18/2012 07:06 PM, NightStrike wrote:
>>
>> >What's wrong with std::shared_ptr?
>>
>> The pointer needs two words, and the per-object overhead for the
>> reference counts etc. is fo
On 11/23/2012 10:45 AM, Jonathan Wakely wrote:
Actually, this observation may favor a real garbage collector. Marking GC as
simple as ggc+gengtype usually have one (or a few) mark bits, so can consume
only a few bits (or perhaps a byte in some mark array) per object. Copying
GC could avoid consu
Quoting Florian Weimer :
On 11/18/2012 07:06 PM, NightStrike wrote:
What's wrong with std::shared_ptr?
The pointer needs two words, and the per-object overhead for the
reference counts etc. is four words, if I'm counting correctly.
(Other forms of reference counting have less overhead, of c
Quoting Joern Rennecke :
P.S.:
If we need more than one operation, or mark-things-live when copying
during normal operation causes too much overhead, we could select
operations
to be performed by the copy constructor by adjusting some global state
(need not literally be a global variable - it mi
On 11/23/2012 11:17 AM, Joern Rennecke wrote:
How about we require that in general, use of raw pointers to GC-able
objects
are banned, and instead we require the use of a class (maybe obtained by
template?) that is a pointer to the GC-able object, with a
special copy-constructor. The copy-const
Hello!
x86_64 has particularly interesting address mode limitations when
"high" 8bit registers (%ah, %dh, %ch and %bh) are handled. Following
examples are all valid:
movb (%rdx), %ah
addb (%rdx), %ah
but when extended register is part of a memory address, insn requires
REX prefix
Hi,
On Thu, 22 Nov 2012, Lawrence Crowl wrote:
> I have found that tree-flow.h implements iteration over htab_t,
> while there is no current facility to do that with hash_table.
> Unfortunately, the specific form does not match the standard C++
> approach to iterators. We have several choices.
>
On 11/22/2012 01:18 PM, Lawrence Crowl wrote:
I have found that tree-flow.h implements iteration over htab_t,
while there is no current facility to do that with hash_table.
Unfortunately, the specific form does not match the standard C++
approach to iterators. We have several choices.
(1) Ignor
On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote:
> In this day and age of rich-text capable mailers, restricting postings
> to be text-only seems quaint and antiquated. Are there any hard
> requirements that force us to only accept plain text messages?
I think it is a bad idea to accept no
On Fri, Nov 23, 2012 at 12:12:17PM -0800, Andrew Pinski wrote:
> On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote:
> > In this day and age of rich-text capable mailers, restricting postings
> > to be text-only seems quaint and antiquated. Are there any hard
> > requirements that force us to
On Fri, Nov 23, 2012 at 3:14 PM, Ruben Safir wrote:
> On Fri, Nov 23, 2012 at 12:12:17PM -0800, Andrew Pinski wrote:
>> On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote:
>> > In this day and age of rich-text capable mailers, restricting postings
>> > to be text-only seems quaint and antiquat
On Fri, Nov 23, 2012 at 3:12 PM, Andrew Pinski wrote:
> On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote:
>> In this day and age of rich-text capable mailers, restricting postings
>> to be text-only seems quaint and antiquated. Are there any hard
>> requirements that force us to only accept
> >
> > incorrect accessment
>
> I can't parse this.
Maybe HTML markup can help you.
Stupid conversation
Why are you using google for your mail? Can't you get a real mail
client and a real mail access? Or maybe you work for google, in which
I can undersand it.
On Fri, Nov 23, 2012 at 3:31 PM, Ruben Safir wrote:
>> >
>> > incorrect accessment
>>
>> I can't parse this.
>
>
> Maybe HTML markup can help you.
>
>
> Stupid conversation
No need to respond in such an arrogant and condescending manner. I do
not understand what "incorrect accessment" means.
On Fri, Nov 23, 2012 at 03:35:57PM -0500, Diego Novillo wrote:
> On Fri, Nov 23, 2012 at 3:31 PM, Ruben Safir wrote:
> >> >
> >> > incorrect accessment
> >>
> >> I can't parse this.
> >
> >
> > Maybe HTML markup can help you.
> >
> >
> > Stupid conversation
>
> No need to respond in such an a
On 11/23/2012 08:12 PM, Andrew Pinski wrote:
> On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote:
>> In this day and age of rich-text capable mailers, restricting postings
>> to be text-only seems quaint and antiquated. Are there any hard
>> requirements that force us to only accept plain tex
On Fri, Nov 23, 2012 at 4:14 PM, Andrew Haley wrote:
> On 11/23/2012 08:12 PM, Andrew Pinski wrote:
>> On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote:
>>> In this day and age of rich-text capable mailers, restricting postings
>>> to be text-only seems quaint and antiquated. Are there any
> And restricting writers, may result in the loss of contributors in the
> medium/long term.
We have a lot of things we do that "restrict" writers. We insist that
patches be tested. We insist that coding standards be followed. We
insist that good documentation practices be applied. We don't all
On Fri, Nov 23, 2012 at 4:27 PM, Richard Kenner
wrote:
>> And restricting writers, may result in the loss of contributors in the
>> medium/long term.
>
> We have a lot of things we do that "restrict" writers. We insist that
> patches be tested. We insist that coding standards be followed. We
>
> It's not that they *cannot* follow an arbitrary rule. It is that the
> rule bears no relation with the quality of their work, so they see it
> as an artificial roadblock which merely irritates them. Add enough
> irritants and they may decide to take their contributions elsewhere.
Coding standa
On Fri, Nov 23, 2012 at 4:41 PM, Richard Kenner
wrote:
> Similarly for text-only vs. "rich text". You may argue that there's no
> compatibility issue, but I disagree. As was pointed out upthread, when
> people use "rich text", they often start to use colors or other mechanisms
> to express them
> It's just that an increasing number of mail agents are configured by
> default to send rich-text.
And people who know enough about computing to work on compilers don't know
how to change the default on their MUA? That seems like a poor reason to
make such a change.
On Fri, Nov 23, 2012 at 5:00 PM, Richard Kenner
wrote:
>> It's just that an increasing number of mail agents are configured by
>> default to send rich-text.
>
> And people who know enough about computing to work on compilers don't know
> how to change the default on their MUA? That seems like a p
Snapshot gcc-4.6-20121123 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20121123/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Thanks for all the comments.
I have incorporated all the feedback (I hope). We will start
implementing this in the cxx-conversion branch.
I've created a new wiki page with the debugging proposal:
http://gcc.gnu.org/wiki/cxx-conversion/debugging-dumps
It is also indexed from the general improvem
For me the most annoying thing about HTML burdened emails
is idiots who choose totally inappropriate fonts, that make
their stuff really hard to read. I choose a font for plain
text emails that is just right on my screen etc. I do NOT
want it overridden. And as for people who use color etc,
well o
> > Similarly for text-only vs. "rich text". You may argue that there's no
> > compatibility issue, but I disagree. As was pointed out upthread, when
> > people use "rich text", they often start to use colors or other mechanisms
> > to express themselves, which can now be dependent on the renderin
28 matches
Mail list logo
