discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] constructor of block is not private


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] constructor of block is not private
Date: Thu, 23 Jan 2014 22:50:31 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Activecat,

I don't quite understand if there is actually a problem that arose
from this or if this is more of an understanding / architectural question.

On 23.01.2014 09:27, Activecat wrote:
> Dear Marcus,
> 
> Correct me if I am wrong. The reason why the constructor is defined
> as private, is to disallowed this (below) from happening, either
> intentionally or unintentionally:
> 
> byte_source_impl   block2;
Well; yes. and: no.
So: what should not happen is that code from outside your module is able
to directly instantiate a Byte Source.
However, as developer of your own module, you should be able
instantiate your own impl; the base class should at least.

Since only byte_source should carry the macro decorator of being
"MODULENAME_API" (and byte_source_impl should not), programs that just
link against your module will not be able to access _impl's
constructor (since it is not an exported symbol in the shared object
and neither will be available via SWIG).

> But in the code attached in the previous email, the constructor is
> defined as public instead.
Yes, otherwise the byte_source_impl would have to "friend"
byte_source::make. In my humble opinion that's confusing, as is the
private constructor mechanism in general. While the latter is
inevitable to stop people from using non-shared pointers or instances
of blocks, making the constructor of an "not so public" implementation
subclass is not necessary and does not really yield increased security
- -- when you want to have a handle of a /block/, you use the base class
(here: byte_source::make) and get a shared pointer. If your
instantiating an object ending in _impl, you know quite well what
you're doing, since you already #included the
/module/lib/byte_source_impl.h; otherwise your compiler won't even
know your byte_source_impl.

> Does this mean that gr_modtool has generated wrong code ..?

gr_modtool would never ever do such a thing ;)

> Shall we just manually correct this by moving the constructor to
> "private" rather than leaving it in "public" ?
Don't do it. It will break the make method and not do anything good.
> 
> Please advise, thanks.
Just use the _impl architecture as it is, if it doesn't introduce any
problems for you. Otherwise, describe these problems!

Happy hacking,
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS4Y6nAAoJEAFxB7BbsDrLaBoH/20oiSVaiKJBnNbz8kzvYMly
ry6pyEDBTOZvETQ4V7Dy2sIs0pX9U17Tdpywds99Bap4MwqAt9o035to2GG6BHJ8
h3qHK5mRf8fzh5daIVWtBz6snY1lfj1ww3R8fOAP4TU7Mo2Z48No0P88ilajvCq2
L/izraTuFBAlARE+ayKsLgE+XMxi0gRx4aSf2XURjoAMCeLnG4hzqeexZ9QX1Fxb
GyRXt59DX4iOkiFwHI1DwZLmABWVCL0afbha747x6KzEPwhHK+8EOMBuoCGYg4BM
TebNabatzc9rsqJQv4SFSeFs7p6xCItKiyu1fM/fhzSlVHWt0V9pk8wMTX9setQ=
=Y0gm
-----END PGP SIGNATURE-----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]