discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Clarification


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Clarification
Date: Fri, 08 Aug 2014 10:19:29 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

Hi Mike,

puh, you're asking us to translate C++ish to plain English. C++'s
language design isn't too open for such unclean and incomplete concepts
as the English language ;)

I'll try:

> Make sure the methods in include/modname/blockname.h are declared pure
virtual so that blockname can remain an abstract class.

Methods of your base class as defined in include/modname/blockname.h
should *not* be fully fledged callable methods, but only entries in the
table that lets the compiler know that there must be a subclass actually
implementing this method.
In practice, this looks like:

namespace gr{
    namespace modname{
    class MODNAME_API blockname : virtual public gr::block {
        ...
        public:
        virtual set_my_herring_count(int herrings) = 0;
        ...
    };
    }
}

The trick is that this class cannot ever be "complete", because there's
a method defined, but you don't implement
blockname::set_my_herring_count(int) in blockname itself. Now, as this
class is incomplete ("abstract"), this guarantees that SWIG doesn't try
to directly instantiate blockname, and the only way to get an instance
of blockname is through the make call.

Greetings,
Marcus
On 07.08.2014 23:10, Mike Willis wrote:
> I still have the problem with the AttributeError: 'module' object has
> no attribute problem for my OOT module. Really clutching at straws
> now, hair all gone. Can anyone explain in plain English what the
> following advice from the WiKi means? I am sure it is 100% clear to
> whoever wrote it but it means little to me.
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7?version=7
>
> Make sure the methods in include/modname/blockname.h are declared pure
> virtual so that blockname can remain an abstract class.
>
> Following that is the advice that If blockname is not abstract, your
> code may compile but SWIG will interpret the declaration as the
> concrete class instead of your blockname_impl class. At runtime this
> will cause an error like ImportError: [...] undefined symbol when the
> Python interpreter attempts to load your SWIGged object code.
>
> Well that's more or less what is happening but it might not be the cause.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




reply via email to

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