[Top][All Lists]

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

Re: [Discuss-gnuradio] message port names

From: Marcus Müller
Subject: Re: [Discuss-gnuradio] message port names
Date: Fri, 28 Feb 2014 16:00:45 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

Hi Sean, Tom and Martin,

basic_block enforces using a symbol in its message_port_register_in method, so 
that's where you'd have to start changing things.
But to add my 0b0010* ct to this:

- using strings as port names keeps consistency
- using strings is the "proper" way to ensure all tools (esp. the companion) 
display port names alike and are able to save/generate a flowgraph into/from a text file 
- stepping away from pmt_symbol as port name type opens up the gate for people 
doing stuff like assigning numeric values of different types (that could lead 
to a nice monte carlo QA for pmt::eqv; corner cases like 
pmt::eqv(pmt_uint64(x),pmt_int(x))==false will lead to problems)
  - I guess the whole point of pmt_symbol is it being unique and provide 
guaranteed identification**
- comparatively very little overhead with the outK method, your workaround seems 
feasible (also: you could consider keeping your own port name 
std::vector<pmt_t> and use that for later reference; if you just need a 
(strangely sorted) list of your ports, it's basic_block::msg_queue)
- hashing overhead negligible for short strings and it speeds up the std::map 
operations when adding/using message ports (hashing will probably even pay 
during runtime)
+Ok, I admit it's strange to use PMTs if you'd actually wanted to use strings 
(and have the type safety)


* valid for gcc 4.3+, clang and C++14 ;)
** Tom: why is there a d_next member in pmt_symbol?
On 02/28/2014 09:19 AM, Martin Braun wrote:
On 02/28/2014 01:39 AM, Nowlan, Sean wrote:
Hey Sean,
I /think/ so. I'd have to double check, but at some point it's
likely to go through a symbol_to_string conversion.
Can you think of a need for a port name to be something other than
a symbol/string? Maybe an enumeration or something?
In a certain block I'm registering N ports, where N is a constructor
argument to the block. I was hoping I could call them
pmt::from_long(0) through pmt::from_long(N-1), but that didn't work.
I ended up creating string names "out0" through "outK" (where K =
N-1) and then used pmt::string_to_symbol.
I doubt anyone implemented that to limit names, it was more likely that
we didn't think of this use case. If you see this is a small,
non-invasive change that would allow other PMTs to be port names, that
would be interesting to see.


Discuss-gnuradio mailing list

reply via email to

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