[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: KOffice not compiling
From:       Adriaan de Groot <groot () kde ! org>
Date:       2008-06-19 21:46:06
Message-ID: 200806192346.06484.groot () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 19 June 2008, Carlos Licea wrote:
> El Thursday 19 June 2008 14:45:39 escribió:
> > Hi Carlos,
> >
> > The code you're working on in KPresenter
> > (filters/kpresenter/kpr2odf/StylesFilterkpr2odf.cpp) doesn't compile,
> > with the following error:
> >
> > line 333: Error: "Filterkpr2odf::createGradientStyle(const
> > KoXmlElement&)" is expected to return a value.
>
> Actually I was concerned because I wasn't getting that error, I'm compiling
> it right now without much trouble. Weird huh?.

GCC is very relaxed like that, which is a bad thing.

> > And I really can't tell what needs fixing here. Line 333 is clearly a
> > missing return but I have no idea what the function might sensibly
> > return. Some kind of m_styles.lookup(), but what?
>
> Yes a m_styles.lookup() is the right return, I'll try to fix it right now.

Thank you.

> > There were a bunch of other "happy constructor" pattern gcc-isms which I
> > removed.
>
> What do you mean?, it's a explicit constructor so as far as I can tell
> foo::foo is a right call, isn' it?
> What's '"happy constructor" pattern gcc-isms' ?

No. For a class foo, you call the constructor with foo(), not foo:foo(). That 
last one works in gcc but not in other compiles, and I call it the happy 
constructor pattern because apparently you really like typing "foo" ;) I see 
it in a lot of KOffice code. Also, foo v = foo() can be shortened to foo v() 
with no bad effects -- Andre Woebbeking pointed that out to me.

The explicit keyword means that the constructor will not participate in any 
implicit type conversions, that's all. So if you have

	class foo {
		explicit foo(int);
	}

	void bar(const foo&);

then you can't do

	bar(7);

but you can do

	bar(foo(7));

If the explicit was *not* there in the declaration of foo's constructor, then 
the compiler would find an implicit type conversion int -> foo for you. 
Whether explicit is useful or not depends on context and the type of classes 
being used -- see the EBN checks for explicitness for details.

> > There are no API docs or much of an explanation in the code of what is
> > going on; API documentation in particular is generally appreciated. It
> > wouldn't have helped me here, since I *really* don't know what the code
> > is supposed to do, but in other cases, or with other people looking at it
> > ..
>
> Nope, because I'm still working on the gradient, acually I think I document
> too much, just not in that function... yet.

OK, so I'm just looking in the wrong place by accident.

Thanks for a quick response, BTW.

[ade]


-- 
These are your friends - Adem
    GPG: FEA2 A3FE Adriaan de Groot

["signature.asc" (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]