auto-completing URLs on Ctrl-Enter

>> Half OT:
>> I remember that static initialisers were not
allowed formerly
>> (explanations
>> ran always like "leading to crashes when
dlopening" or the similary).
>> Why
>> isn't it an issue any more?
>
> It's still an issue for class-static or file-static
members, since the
> order of initialization for those is undefined.
>
> But here it's about method-static, which is fine since
we know it will
> only
> be initialized when calling the method for the first
time.

There was an another issue: they could cause crashes on
dlunload on
certain systems. At least some older FreeBSD versions were
thus afflicted,
but I am not sure anyone uses those particular versions
anymore.

On Friday 03 February 2006 17:56, Maksim Orlovich wrote:
> >> Half OT:
> >> I remember that static initialisers were not
allowed formerly
> >> (explanations
> >> ran always like "leading to crashes when
dlopening" or the similary).
> >> Why
> >> isn't it an issue any more?
> >
> > It's still an issue for class-static or
file-static members, since the
> > order of initialization for those is undefined.
> >
> > But here it's about method-static, which is fine
since we know it will
> > only
> > be initialized when calling the method for the
first time.
> 
> There was an another issue: they could cause crashes on
dlunload on
> certain systems. At least some older FreeBSD versions
were thus afflicted,
> but I am not sure anyone uses those particular versions
anymore.

I don't think we even call dlunload anymore.

-- 
David Faure, faurekde.org, sponsored by Trolltech to work on
KDE,
Konqueror (http://www.konqueror.org
), and KOffice (http://www.koffice.org).

On Saturday 04 February 2006 01:04, David Faure wrote:
> > There was an another issue: they could cause
crashes on dlunload on
> > certain systems. At least some older FreeBSD
versions were thus
> > afflicted, but I am not sure anyone uses those
particular versions
> > anymore.
>
> I don't think we even call dlunload anymore.

By default we don't. Which is very annoying for testing
plugins, as you have 
to restart all the time.

But looking at the KLibLoader source and svn log's output
there are actually 
provisions to force a dlclose:

------------------------------------------------------------
------------
r69148 | matz | 2000-10-28 05:05:26 +0200 (Sat, 28 Oct 2000)
| 11 lines

Internal cleanups. Proper ref-counting when
loading/unloading the same library
multiple times. Make sure, you don't create KLibrary objects
yourself. Instead
go through KLibLoader (this was there from the beginning,
but now it's really
required).

It now defaults to _not_ dlclose() libraries. Only those
which export the 
symbol __kde_do_unload. (__kde_do_not_unload is still
recognized, as are the 
env. vars KDE_NOUNLOAD (disabling dlclose() alltogether) and
KDE_DOUNLOAD 
(enabling dlclose() for _all_ libs). This means, that
currently no libraries 
are dlcose'ed by default.
------------------------------------------------------------
------------

I wish I knew about the $KDE_DOUNLOAD trick back when I
worked on Kopete :/

-- 
Martijn

Martijn Klingens wrote:
>I wish I knew about the $KDE_DOUNLOAD trick back when I
worked on Kopete
> :/

A library can be unloaded if and only if:
- you have no pointers into its memory addresses
- you have no objects of classes defined there
- you have no objects created there that could be using a
non-global 
symbol (libraries are loaded without global binding)

And by "you", I mean "everything loaded in
your program that is not the 
library itself", including other loaded modules.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago
(AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

4. And æfter se scieppend ingelogode, he wrát
"cenn", ac eala! se 
rihtendgesamnung andswarode "cenn: ne wát hú cennan
'eall'. Ástynt."