Re: [Discuss-gnuradio] message port names

[Marcus Müller]

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

Greetings,
Marcus

* 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?
> > > Tom
> > 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.
>
> M
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio