On Fri, Apr 29, 2011 at 8:07 AM, Yuan Pengfei wrote:
> B+ tree is more commonly used in file systems. In memory, I think RB-tree is
> better.
> RB-tree vs. hash table is just like map vs. unordered_map.
>
Any balanced tree that have O(log(n)) lookup complexity, including splay tree.
--
Chiheng
On Thu, Apr 28, 2011 at 9:13 PM, Robert Dewar wrote:
> I think the hash table is a much better choice than the B+ tree. You
> really are much more interested in average case performance in a compiler
> than worst case, especially when the worst case will not
> happen in practice.
Basically, I agr
Hi,
I am Ismail KURU, accepted by Google Summer of Code 2011.
My study mainly focuses on integration of transactional memory support
into data-flow extension of OpenMP that is
aiming increased expressiveness and performance while preserving the
paradigms' properties.
My project combines develo
Hi Xu,
B+ tree is more commonly used in file systems. In memory, I think RB-tree is
better.
RB-tree vs. hash table is just like map vs. unordered_map.
--
Yuan Pengfei
Peking Unversity, China
Snapshot gcc-4.5-20110428 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110428/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thursday 28 April 2011, Alan Stern wrote:
> > The compiler does not complain, it just silently assumes that it needs
> > to do byte accesses. There is no way to tell the compiler to ignore
> > what it knows about the alignment, other than using inline assembly
> > for the actual pointer derefere
On 04/28/2011 12:35 PM, Magnus Fromreide wrote:
So, now I would like to know if there is something amiss with
pedwarn_cxx98 or the comment above it?
Looking at the way pedwarn_cxx98 is used for long long (the original
motivating case), think the right way to use it for your issue too seems
havi
On Wed, 27 Apr 2011, Arnd Bergmann wrote:
> On Wednesday 27 April 2011 18:25:40 Alan Stern wrote:
> > On Wed, 27 Apr 2011, Rabin Vincent wrote:
> >
> > > On Wed, Apr 27, 2011 at 00:21, Alan Stern
> > > wrote:
> > > > On Tue, 26 Apr 2011, Rabin Vincent wrote:
> > > >> In my case it's this writel
On 04/21/2011 12:40 PM, Richard Guenther wrote:
A first release candidate for GCC 4.5.3 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5.3-RC-20110421/
and shortly its mirrors. It has been generated from SVN revision 172803.
I have sofar bootstrapped and tested the release candid
On 4/28/2011 8:55 AM, Richard Guenther wrote:
It seems to me that hash table in GCC is more like mapping(or
dictionary, or associated array, or function(Key->Value)), instead of
containter.
I think the main problem of hash table is that conflict rate is
unpredictable, so the lookup time is unp
On Thu, Apr 28, 2011 at 2:52 PM, Chiheng Xu wrote:
> On Wed, Apr 27, 2011 at 10:29 PM, Basile Starynkevitch
> wrote:
>>
>>> Here are some areas I'll look closer to, as shown by some early profiling
>>> I performed:
>>> * hash tables (both htab and symtab)
>>
>> There is probably a lot of tuning
On Wed, Apr 27, 2011 at 10:29 PM, Basile Starynkevitch
wrote:
>
>> Here are some areas I'll look closer to, as shown by some early profiling
>> I performed:
>> * hash tables (both htab and symtab)
>
> There is probably a lot of tuning possible around GCC hash tables. However,
> I would imagine th
Hello.
I noticed that (foo.cpp):
enum gaz { foo, };
generated a warning
foo.cpp:1:15: warning: comma at end of enumerator list [-pedantic]
when compiled with
g++ -std=gnu++0x -pedantic -fsyntax-only foo.cpp
According to n3290 this is acceptable so I tried to make this warning go
away.
This
13 matches
Mail list logo
