-----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----- _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
