Constructor of block is not private

GNU Radio
1

Dear Sir,

From the documentation, the constructor of user-defined block is often
private.
But how come it is defined as public, refer below code.
This is a typical code generated by gr_modtool:

Filename: byte_source_impl.h

/* -- c++ -- */#ifndef INCLUDED_HOWTO_BYTE_SOURCE_IMPL_H#define
INCLUDED_HOWTO_BYTE_SOURCE_IMPL_H
#include <howto/byte_source.h>
namespace gr {
namespace howto {

class byte_source_impl : public byte_source
{
   private:
      unsigned int counter;


   public:
      byte_source_impl();   // constructor is public ??
      ~byte_source_impl();

      void forecast (int noutput_items, gr_vector_int

&ninput_items_required);

      int general_work(int noutput_items,
               gr_vector_int &ninput_items,
               gr_vector_const_void_star &input_items,
               gr_vector_void_star &output_items);
};

} // namespace howto
} // namespace gr
#endif /* INCLUDED_HOWTO_BYTE_SOURCE_IMPL_H */

Please advise, thanks.

Regards.
[email protected]

2

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

Hi Activecat,

the _impl classes are usually not instantiated by themselves; in fact,
their symbols are usually not exported and not wrapped by swig.
Instead, an instance of them is usually generated using the
superclass’ ::make method. So there is need for at least that make
method being able to access the constructor.

Hope that cleared things up a little!

Greetings,
Marcus

On 23.01.2014 07:33, Activecat wrote:

namespace gr { namespace howto {

Regards. [email protected]

_______________________________________________ Discuss-gnuradio
mailing list [email protected]
Discuss-gnuradio Info Page

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

iQEcBAEBAgAGBQJS4L+lAAoJEAFxB7BbsDrLzKgH/3hXX64ZTxL0jMsns+Iukaqv
D8dp31yTa2dLDlaB/C+/SuZx1bRRjSEwUSWSl9/heqL90M80R7FLbr4AiGBlmPWu
o/c5kSTimPjSmEjND2yDJbEBacK7p4ha2S77BRNXi1eFcWCYBrDDJD3gkisGlFop
Tw0sYZHnGrt6RydNm/BCPSTufY9hpdM0dnYIEOIG0ox5DOXK5ZIKZvbEnfG+GZW9
yiN0sUgZQa+RSuxpbHL8IOwXgXN1s+XkrMFpqSIzeXN6GRduuXKl0+qYw2sJEV94
mPvO2deLBeaBEafioCMubO25w3sEJzv41Et7gld45VlMwhY69+DusJXH37gJwcU=
=2xFR
-----END PGP SIGNATURE-----

3

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;

Hence the constructor is usually defined as private as below:
class byte_source_impl : public byte_source
{
private:
byte_source_impl();
}

But in the code attached in the previous email, the constructor is
defined
as public instead.
Does this mean that gr_modtool has generated wrong code …?
Shall we just manually correct this by moving the constructor to
“private”
rather than leaving it in “public” ?

Please advise, thanks.
activecat

4

-----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 :wink:

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-----

5

On 01/23/2014 10:50 PM, Marcus M. wrote:

Does this mean that gr_modtool has generated wrong code …?

gr_modtool would never ever do such a thing :wink:

:smiley:
I might not swear on this to be true, but in this case, it’s all
correct.

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.

What he said. If you know the old API, there were lots of ‘friend’
statements. We don’t want them back.

MB