[En-Nut-Discussion] Optimizing nutconf

[Thiago A. Corrêa]

On Sun, Jan 11, 2009 at 7:42 AM, Harald Kipp <harald.kipp at egnite.de> wrote:
> Ole Reinhardt wrote:
>> Hi Thiago,
>>
>>>    I'm running on a 2.8Ghz Quad, and still takes some 3 seconds to
>>> tick a checkbox, wonder how nutconf is doing for others.
>
> Right Thiago, since the Configurator moved from static to dynamic
> scripting, the performance suffered significantly. Though, updates never
> took more than a second here.

It's really pronounced with checkboxes, other controls work ok. AFAIK
it seams to be the dependency checkings, since checkboxes usually
enable/disable other options.


>> I just build the HEAD version of NutConf on my Ubuntu 8.10 machine and
>> tried to reproduce your problems. Unfortunately I ended up in a
>> segmentation fault just after selecting a configuration file. So it does
>> not work at all for me.
>
> Ole, are you running KDE4? There seems to be a problem with this KDE
> version and the wxWidget file open dialog. Last time I googled for that,
> only very few reports about this issue appeared and no solution...

You know... I was almost going to rewrite the nutconf (nutconf2) using
Qt, just for the fun of it. Doesn't seam too much work, since all of
the "what to do and how" is already layed out in nutconf code.
Qt code looks much better and shouldn't have so many issues on other
platforms (Mac issues, now KDE).

> Thiago added an abstract class, which simplifies the code for scanning
> directories. Unfortunately
>
>  g++ (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
>
> doesn't aacept line 723 of nutconfdoc.cpp:
>
>  virtual ~CAbstractDirCopyTraverser() = 0
>  {
>  }
>
> IMHO it is not allowed to have both, a pure-specifier and the
> definition. Although, the MS compiler accepted that statement. Do we
> need the  declaration of the destructor at all?

Actually, destructors are a speciall case in pure virtual syntax, they
must always have a body, and since the compiler won't generate one if
you declare it, you must provide one. Probably the compiler has a bug
with the inline body.

> I should add, that my knowledge about C++ is not sufficient to
> understand all the details. After removing the destructor, it seems to
> work, but I'm not sure whether this may break something else.

That is actually a bit of syntax suggar, as long as you don't
instantiate it (no reason to anyway), it would work as abstract just
as well. This only serves to enforce that design decision, so the
compiler will warn you that you can't instantiate it directly, only
inherit from it.

So, it's quite safe to remove it. :)

Thanks,
   Thiago A. Correa