One of the major reasons that we have to #include header files in header files
is because we cannot forward declare enums. Witness the fact that LColor.h
has the greatest number of dependencies in the entire project. And all
because LColor::color is passed as an argument to functions.
I would l
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> One of the major reasons that we have to #include header files
Angus> in header files is because we cannot forward declare enums.
Angus> Witness the fact that LColor.h has the greatest number of
Angus> dependencies in the entire pro
On Wed, Sep 10, 2003 at 10:49:57AM +0200, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> One of the major reasons that we have to #include header files
> Angus> in header files is because we cannot forward declare enums.
> Angus> Witness the fac
On Wednesday 10 September 2003 9:03 am, Andre Poenitz wrote:
> > Why not just just move the LColor::color enum out of the LColor class?
> > This would be much easier...
> >
> > We could just define a LColorTag enum in its own header file, and have
> > LColor operate on LColorTag instead of LColor::
Angus Leeming <[EMAIL PROTECTED]> writes:
| On Wednesday 10 September 2003 9:03 am, Andre Poenitz wrote:
>> > Why not just just move the LColor::color enum out of the LColor class?
>> > This would be much easier...
>> >
>> > We could just define a LColorTag enum in its own header file, and have
>>
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> How would that help? enums cannot be forward declared, so any
Angus> header file declaring a function that is passed an enum must
Angus> #include the header file that defines the enum. It makes not a
Angus> jot of difference whether
On Wednesday 10 September 2003 10:17 am, Jean-Marc Lasgouttes wrote:
> The difference is whether one has to include std_string.h and
> boost/scoped_ptr.hpp. I'd be surprised if this was negligible
> (especially the second one).
There are no #includes in EnumWrapper.h. I don't understand your point
On Wed, Sep 10, 2003 at 11:00:44AM +, Angus Leeming wrote:
> On Wednesday 10 September 2003 9:03 am, Andre Poenitz wrote:
> > > Why not just just move the LColor::color enum out of the LColor class?
> > > This would be much easier...
> > >
> > > We could just define a LColorTag enum in its own
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> On Wednesday 10 September 2003 10:17 am, Jean-Marc Lasgouttes
Angus> wrote:
>> The difference is whether one has to include std_string.h and
>> boost/scoped_ptr.hpp. I'd be surprised if this was negligible
>> (especially the second
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> On Wednesday 10 September 2003 10:17 am, Jean-Marc Lasgouttes
Angus> wrote:
>>> The difference is whether one has to include std_string.h and
>>> boost/scoped_ptr
Andre Poenitz wrote:
> But not nice (read UGLY). In fact I neither like the template idea and
> certainly not the macro.
>
> [OTOH, enums are rarely nice...]
>
> [And if you keep pushing on that I'll see the day when we'll have the
> template but not the macros getting nice obfuscated code...]
T
On Wed, Sep 10, 2003 at 12:47:57PM +0200, Jean-Marc Lasgouttes wrote:
> Angus> You aren't. Class EnumLColor is not a template. It derives from
> Angus> a template instantiation. That's the trick. (And it works. See
> Angus> the forward declaration of function 'compare' in the sample
> Angus> code.)
Jean-Marc Lasgouttes wrote:
>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> On Wednesday 10 September 2003 10:17 am, Jean-Marc Lasgouttes
> Angus> wrote:
>>> The difference is whether one has to include std_string.h and
>>> boost/scoped_ptr.hpp. I'd be surprised if this was
On Wed, Sep 10, 2003 at 11:59:59AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> > But not nice (read UGLY). In fact I neither like the template idea and
> > certainly not the macro.
> >
> > [OTOH, enums are rarely nice...]
> >
> > [And if you keep pushing on that I'll see the day when we'
On Wed, Sep 10, 2003 at 12:04:48PM +, Angus Leeming wrote:
> > So this mean that if std::string derived from basic_string instead of
> > being a typedef, it would be forward-declarable?? Why isn't this done?
>
> That's right it would. I don't know.
>
> (You could propose 'class lyxstring : pu
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Ah well. It is all becoming academic, as I've run out of time
Angus> to play with LyX. You'll just have to keep the inter-twined
Angus> header files and painful recompilation when you change any
Angus> header file in the src directo
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> You mean because of those default assignments, like:
Yes.
Angus> Question: is the default assignment really helpful here?
Angus> Probably not.
You may be right.
Angus> (You could propose 'class lyxstring : public std::string {}
Andre Poenitz wrote:
> On Wed, Sep 10, 2003 at 11:59:59AM +, Angus Leeming wrote:
>> Andre Poenitz wrote:
>> > But not nice (read UGLY). In fact I neither like the template idea and
>> > certainly not the macro.
>> >
>> > [OTOH, enums are rarely nice...]
>> >
>> > [And if you keep pushing on
Jean-Marc Lasgouttes wrote:
> Angus> (You could propose 'class lyxstring : public std::string {};'
> Angus> if you like. You'd have to define the constructors but that'd
> Angus> be all. After you propose it, Lars will throw it out. Again,
> Angus> the reasons why won't be clear.)
>
> I have to ad
Angus Leeming <[EMAIL PROTECTED]> writes:
| Jean-Marc Lasgouttes wrote:
>> Angus> (You could propose 'class lyxstring : public std::string {};'
>> Angus> if you like. You'd have to define the constructors but that'd
>> Angus> be all. After you propose it, Lars will throw it out. Again,
>> Angus> t
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Jean-Marc Lasgouttes wrote:
>>> Angus> (You could propose 'class lyxstring : public std::string {};'
>>> Angus> if you like. You'd have to define the constructors but that'd
>>> Angus> be all. After you propose it, Lars
Angus Leeming <[EMAIL PROTECTED]> writes:
| We know you oppose it. But I suspect that your opposition is based
| on feelings of "Better the Devil you know than the one you don't".
That might very well be the case. I am feeling all jittery when
thinking about this.
| Attached is a _working_ test
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | We know you oppose it. But I suspect that your opposition is based
> | on feelings of "Better the Devil you know than the one you don't".
>
> That might very well be the case. I am feeling all jittery when
> thinking ab
On Wed, Sep 10, 2003 at 05:52:08PM +0200, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | We know you oppose it. But I suspect that your opposition is based
> | on feelings of "Better the Devil you know than the one you don't".
>
> That might very well be the case. I
Andre Poenitz wrote:
> Note that if this is done one of the main remaining reasons to stick to
> 'STRCONV' and --with-included-strings (namely smaller binaries) might go
> away, so this in fact could lead to nicer code.
This is what two people had to say on the matter on comp.lang.c++
In a nutshel
On Wed, Sep 10, 2003 at 05:39:31PM +, Angus Leeming wrote:
> There are two issues.
>
> (a) No virtual destructor. This means you can't safely call delete on
> a pointer to string when the object pointed to is in fact a
> derived_from_string.
>
> (b) It isn't designed for polymorphism
Angus Leeming <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
>> Note that if this is done one of the main remaining reasons to stick to
>> 'STRCONV' and --with-included-strings (namely smaller binaries) might go
>> away, so this in fact could lead to nicer code.
>
| This is what two people had
On Wednesday 10 September 2003 5:01 pm, Andre Poenitz wrote:
> On Wed, Sep 10, 2003 at 05:39:31PM +, Angus Leeming wrote:
> > There are two issues.
> >
> > (a) No virtual destructor. This means you can't safely call delete on
> > a pointer to string when the object pointed to is in fact a
>
On Wed, Sep 10, 2003 at 06:06:11PM +, Angus Leeming wrote:
> What we should do is put some hard numbers to all this. The only
> reason to go down this route at all is to reduce compile times,
> right?
Yes...
> If that is the case, then it is enough to just 'suck it and see' and
> post back th
29 matches
Mail list logo
