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

List:       koffice-devel
Subject:    structs vs classes; was Re: koffice/kspread
From:       Jaroslaw Staniek <js () iidea ! pl>
Date:       2008-05-29 17:11:36
Message-ID: 483EE3C8.9020209 () iidea ! pl
[Download RAW message or body]

Thomas Zander said the following, On 2008-05-29 10:11:
> On Wednesday 28. May 2008 10:49:55 Christian Ehrlicher wrote:
>> KoPageLayout SheetPrint::paperLayout() const
>> {
>>     return m_settings->pageLayout();   // here the pageLayout is copied
>> }
>>
>> void otherFunction()
>> {
>>   paperlayout().width = 25;
>> }
> 
> The pattern intended (and used in Qt) is that the otherFunction would have to 
> do;
>   KoPageLayout pl = print.paperLayout();
>   pl.width = 25;
>   print.setPaperLayout(pl);

This would suggest that KoPageLayout is implicitly shared for efficiency. It 
is not, instead it contains uninitialized members as optimization.

KoPageLayout (and similar structs) cannot be fully compared to the Qt pattern,
because the former is designed in a C-like way: (again: uninitialized members).

Moreover structs with methods could become classes for clarity.

We fix struct/class warnings every month in KOffice. Looks like a proposal for 
JJ before our API stabilizes, and start using classes everywhere except for 
real C structs.

Thoughts?

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)
_______________________________________________
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]