Re: [glade--]Re: [gtkmm] Problem with gtkmm handling comboboxes from glade
- From: Daniel Elstner <daniel elstner gmx net>
- To: Murray Cumming <murrayc usa net>
- Cc: Christof Petig <christof petig-baender de>, John Bartelt <bartelt ics uci edu>, gtkmm mailing list <gtkmm-main lists sourceforge net>, glademm mailing list <glademm-list gnome org>
- Subject: Re: [glade--]Re: [gtkmm] Problem with gtkmm handling comboboxes from glade
- Date: 03 Dec 2001 14:46:29 +0100
Am Mon, 2001-12-03 um 14.25 schrieb Murray Cumming:
> On Mon, 2001-12-03 at 13:54, Daniel Elstner wrote:
> > Yes. People should update their compiler. Since when are we starting
> > to work around bugs in other OSS packages?
>
> That's not very practical.
>
> > > > > I have not followed this in detail, but this doesn't seem to be the same
> > > > > conclusion that was drawn last time this came up:
> > > > > http://marc.theaimsgroup.com/?t=100494551700001&w=2&r=1
> > >
> > > I still need this to be answered. The previous discussion seemed to
> > > suggest that there was something wrong with the declaration used by
> > > glademm.
> >
> > It wasn't wrong, but redundant and weird-looking. It seems we have now
> > finally sorted this out.
>
> OK. Thanks for clearing that up.
>
> > I don't think it'd be clearer. The way it's now is the only way in C++
> > to generate an array at compile time. And why would you want to
> > generate an array at runtime if you can do it at compile time?
>
> Actually it would be nicest to use the compile-time version with a typedef
> to make it clearer, but it needs to work on gcc2.96RH.
Well, we could add specializations of Traits<T> for 'const T[N]' and
'const T*'. That might help the compiler to chose the correct
specialization, and it won't break the API or ABI at all.
> >
> > > > (and considerung the
> > > > compiled code size, I would guess that the first variant is much bigger (inlining), but I
> > > > don't have numbers)
> > >
> > > I doubt that this is of any relevance.
> >
> > The predefined array needs _no_ code at all. So the vector variant must
> > be bigger in any case.
>
> I don't disagree that it's bigger and slower, but I don't believe that
> that is of any relevance to a running application.
>
> --
> Murray Cumming
> murrayc usa net
> www.murrayc.com
>
>
> _______________________________________________
> to unsubscribe or change your subscription parameters :
> https://lists.sourceforge.net/lists/listinfo/gtkmm-main
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]