Marcus,
Based on what you and others have replied, I think my "most elegant" plan
of attack would be to toss the generated puthon glue code (which I
generated using grc-companion BTW) and do everything in C++ so I dont have
to worry about the language interface at all.
This way, I will not need global shared pointers.
Thank you again for all the time you have spent responding to me.
Ranga
On Thu, Nov 14, 2013 at 11:43 AM, Marcus Müller <mar...@hostalia.de> wrote:
> Hi Ranga,
>
> either you're seriously astray or I don't understand what you want.
> This is C++ running on an operating system with segmentation. There are
> *no* globally visibly objects, there is only calls to the operating systems
> / IPC to communicate with other processes and objects that live within your
> own process that you can directly address. Ok, there's shared memory, but
> you can't move a uhd_source to shared pages; that doesn't make sense.
>
> When you're in the same process, it's easy just to pass pointers around.
> They are objects as everything else. Let's assume you construct a flowgraph
> like
> top_block->connect(uhd_source, processing, mac, sink)
> then you can just do
> mac->set_uhd_src_pointer(uhd_source)
>
> which would be something like
> mymac::set_uhd_src_pointer(uhd_source::sptr src)
> {
> _uhd_src_sptr = src;
> }
>
> which enables you to just
> _uhd_src_sptr->set_center_frequency(20000);
> inside your class.
>
> Greetings,
>
> Marcus
>
>
> On 14.11.2013 16:53, M. Ranganathan wrote:
>
> Marcus,
>
> Looking around I don't see where the pointer to the block is made globally
> visible. I am inclined to add some code to the make method to register the
> shared pointer in a global variable when the method is called. Since my
> application has only a single USRP block (source and sink), there's no
> danger of overwriting something.
>
> My problem is this:
>
> I have python code that creates the blocks and strings them together
> etc. but I want to actually access the created block from c++ code (in the
> mac block implementation).
>
> Let me know if I am seriously astray.
>
>
> Thanks again for your help.
>
>
>
>
>
>
> On Thu, Nov 14, 2013 at 9:52 AM, Marcus Müller <mar...@hostalia.de> wrote:
>
>> In GR 3.7, the shared pointer is usually blockname::sptr;
>>
>> I can't really point you to a very good example, but when you call
>> top_block.connect(src, sink) in C++, you're giving it spointers :)
>>
>> As I said, whenever you make a block, you actually get a shared pointer
>> to that instance, and not the object itself.
>>
>>
>> On 14.11.2013 15:39, M. Ranganathan wrote:
>>
>> Marcus,
>>
>> Thanks for your reply. What will the shared pointer be called. I see
>> stuff like this in the code:
>>
>> GR_SWIG_BLOCK_MAGIC2(uhd, usrp_source)
>> GR_SWIG_BLOCK_MAGIC2(uhd, usrp_sink)
>> GR_SWIG_BLOCK_MAGIC2(uhd, amsg_source)
>>
>>
>> Presumably, that generates a structure that is registered as a global
>> pointer. So in my mac, I want something like
>>
>> extern ....
>>
>> At the risk of asking for too much help, can you give me some guidance
>> or point me to a fragment of code somewhere that does this sort of thing.
>>
>> Thanks,
>>
>> Ranga
>>
>>
>>
>> On Thu, Nov 14, 2013 at 4:06 AM, Marcus Müller <mar...@hostalia.de>wrote:
>>
>>> Hi Ranga,
>>>
>>> that's what pointers are for, after all. Just do it! Thanks to the
>>> make()-magic you basically always have a smart shared pointer instead of an
>>> block object (unless you really try to break the system ;) ).
>>>
>>> Just a quick note though: MAC is usually timing-relevant. Timed commands
>>> might not work as you expect, so please be aware that calling
>>> set_command_time on your source might break functionality since there is no
>>> out-of-order execution.
>>>
>>> Greetings,
>>> Marcus
>>>
>>>
>>> On 14.11.2013 01:26, M. Ranganathan wrote:
>>>
>>> Hello all!
>>>
>>> I want to write a block that can directly access the uhd_usrp_source.
>>> This block is a mac block hence it is up on the food chain and far away
>>> from uhd_usrp_source in terms of its processing function. What is a good
>>> way of passing it a handle to the usrp_source ?
>>>
>>> I can think of some hacks (such as a static global pointer where the
>>> uhd_usrp_source C++ object registers itself) but it seems ugly to me to
>>> take that route. Is there a better way to access global objects from within
>>> a block implementation.
>>>
>>> Thanks in advance for any help.
>>>
>>> Regards,
>>>
>>> Ranga
>>>
>>> --
>>> M. Ranganathan
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing
>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>>
>> --
>> M. Ranganathan
>>
>>
>>
>
>
> --
> M. Ranganathan
>
>
>
--
M. Ranganathan
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
