On Wed, 15 Aug 2012, Richard Guenther wrote:
> On Sun, 12 Aug 2012, Diego Novillo wrote:
>
> > This implements a new C++ hash table.
> >
> > See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html for
> > details.
> >
> > Diego.
>
> Now as we see the result I'd have prefered a more C++-way
Hi,
On Wed, 15 Aug 2012, Richard Guenther wrote:
> Like the following, only the coverage.c use is converted. I've never
> seen template function arguments anywhere and having to repeat them all
> over the place is really really ugly (yes, even if only in the
> implementation).
>
> This goes
On Wed, 15 Aug 2012, Michael Matz wrote:
> Hi,
>
> On Wed, 15 Aug 2012, Richard Guenther wrote:
>
> > Like the following, only the coverage.c use is converted. I've never
> > seen template function arguments anywhere and having to repeat them all
> > over the place is really really ugly (yes,
On 2012-08-15 07:29, Richard Guenther wrote:
> + typedef typename Element::Element_t Element_t;
Can we use something less ugly than Element_t?
Such as
typedef typename Element::T T;
? Given that this name is scoped anyway...
r~
On 8/15/12, Richard Guenther wrote:
> On Sun, 12 Aug 2012, Diego Novillo wrote:
> > This implements a new C++ hash table.
> >
> > See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html for
> > details.
>
> Now as we see the result I'd have prefered a more C++-way instead
> of making the conve
On 8/15/12, Richard Guenther wrote:
> On Wed, 15 Aug 2012, Michael Matz wrote:
> > On Wed, 15 Aug 2012, Richard Guenther wrote:
> > > Like the following, only the coverage.c use is converted.
> > > I've never seen template function arguments anywhere and
> > > having to repeat them all
> > >
> > >
On 8/15/12, Richard Henderson wrote:
> On 2012-08-15 07:29, Richard Guenther wrote:
>> + typedef typename Element::Element_t Element_t;
>
> Can we use something less ugly than Element_t?
> Such as
>
> typedef typename Element::T T;
>
> ? Given that this name is scoped anyway...
I do not much
On Wed, Aug 15, 2012 at 2:58 PM, Lawrence Crowl wrote:
>
> I do not much like _t names either.
Also, names ending in _t are reserved by POSIX if you #include
. Though that may only apply to global names, not to
types defined in classes or namespaces.
Ian
On Wed, 15 Aug 2012, Lawrence Crowl wrote:
> On 8/15/12, Richard Henderson wrote:
> > On 2012-08-15 07:29, Richard Guenther wrote:
> >> + typedef typename Element::Element_t Element_t;
> >
> > Can we use something less ugly than Element_t?
> > Such as
> >
> > typedef typename Element::T T;
>
Hi,
I have another "out of curiosity"-type question ;)
On 08/16/2012 11:19 AM, Richard Guenther wrote:
!
! template
! inline int
! pointer_hash::equal (const T *existing,
! const T *candidate)
! {
! return existing == candidate;
}
are these uses in the new cod
On Thu, 16 Aug 2012, Paolo Carlini wrote:
> Hi,
>
> I have another "out of curiosity"-type question ;)
>
> On 08/16/2012 11:19 AM, Richard Guenther wrote:
> >
> > !
> > ! template
> > ! inline int
> > ! pointer_hash::equal (const T *existing,
> > ! const T *candidate)
>
On 8/16/12, Richard Guenther wrote:
> On Wed, 15 Aug 2012, Lawrence Crowl wrote:
> > On 8/15/12, Richard Henderson wrote:
> > > On 2012-08-15 07:29, Richard Guenther wrote:
> > > > + typedef typename Element::Element_t Element_t;
> > >
> > > Can we use something less ugly than Element_t?
> > >
On 8/15/12, Richard Henderson wrote:
> On 2012-08-15 07:29, Richard Guenther wrote:
> > + typedef typename Element::Element_t Element_t;
>
> Can we use something less ugly than Element_t?
> Such as
>
> typedef typename Element::T T;
>
> ? Given that this name is scoped anyway...
I've been fi
Hi,
On Tue, 25 Sep 2012, Lawrence Crowl wrote:
> On 8/15/12, Richard Henderson wrote:
> > On 2012-08-15 07:29, Richard Guenther wrote:
> > > + typedef typename Element::Element_t Element_t;
> >
> > Can we use something less ugly than Element_t?
> > Such as
> >
> > typedef typename Element::T
On Tue, Sep 25, 2012 at 4:30 PM, Lawrence Crowl wrote:
> On 8/15/12, Richard Henderson wrote:
>> On 2012-08-15 07:29, Richard Guenther wrote:
>> > + typedef typename Element::Element_t Element_t;
>>
>> Can we use something less ugly than Element_t?
>> Such as
>>
>> typedef typename Element::T
On 9/26/12, Michael Matz wrote:
> On Tue, 25 Sep 2012, Lawrence Crowl wrote:
> > On 8/15/12, Richard Henderson wrote:
> > > On 2012-08-15 07:29, Richard Guenther wrote:
> > > > typedef typename Element::Element_t Element_t;
> > >
> > > Can we use something less ugly than Element_t?
> > > Such as
On Wed, Sep 26, 2012 at 1:09 PM, Lawrence Crowl wrote:
>
> The problem is that while T is customary as a template parameter, I
> have never seen it used as a typedef name. And that's the situation
> that we are in now.
this should be a no-brainer: T should be reserved for the name of the
templat
Hi,
On Wed, 26 Sep 2012, Lawrence Crowl wrote:
> > A lower-case type name indicates to me a non-changing type,
> > i.e. nothing that depends on a template. In C we only had
> > such types so we used lower-case names everywhere. With C++
> > and templates I think we should start using upper case
On Thu, Sep 27, 2012 at 7:12 AM, Michael Matz wrote:
> (And if they aren't, then again, we did something too
> complicated with the switch to C++).
or we are doing something by insisting not to use
standard notation.
On 9/27/12, Michael Matz wrote:
> On Wed, 26 Sep 2012, Lawrence Crowl wrote:
> > > A lower-case type name indicates to me a non-changing type,
> > > i.e. nothing that depends on a template. In C we only had
> > > such types so we used lower-case names everywhere. With C++
> > > and templates I t
On Thu, Sep 27, 2012 at 1:35 PM, Lawrence Crowl wrote:
> If we were to follow C++ standard library conventions, we would call
> it value_type. That would be my preference. However, if folks
> want a shorter name, I'll live with that too. But as it stands,
> the current name is very confusing.
Hi,
On Thu, 27 Sep 2012, Lawrence Crowl wrote:
> > template
> > struct D : B
> > {
> > typedef typename B::E E; // element_type
> > E getme (int index);
> > }
>
> Inside that struct, lets say we have a field of type E. Do we name
> it F or f?
IMHO only for types, not for any other decls.
On Fri, Sep 28, 2012 at 8:18 AM, Michael Matz wrote:
>> It is common practice to have
>>
>> struct Q
>> {
>> typedef int E;
>> E getme (int index);
>> };
>
> Easy: I wouldn't make a typedef for Q::E that merely is int. The reason
> is that it makes knowing what getme really returns harder.
On 9/28/12, Michael Matz wrote:
> On Thu, 27 Sep 2012, Lawrence Crowl wrote:
> > > template
> > > struct D : B
> > > {
> > > typedef typename B::E E; // element_type
> > > E getme (int index);
> > > }
> >
> > Inside that struct, lets say we have a field of type E. Do we name
> > it F or f?
>
On Fri, Sep 28, 2012 at 12:40 PM, Lawrence Crowl wrote:
> On 9/28/12, Michael Matz wrote:
>>
>> I would even prefer 'e' over value_type. It's scoped, the context always
>> will be clear, no need to be verbose in that name. I find the long names
>> inelegant, as most of the standard libs convent
On 9/28/12, Gabriel Dos Reis wrote:
> On Fri, Sep 28, 2012 at 8:18 AM, Michael Matz wrote:
>>> It is common practice to have
>>>
>>> struct Q
>>> {
>>> typedef int E;
>>> E getme (int index);
>>> };
>>
>> Easy: I wouldn't make a typedef for Q::E that merely is int. The reason
>> is that it m
26 matches
Mail list logo
