Re: [Discuss-gnuradio] message port names

[Nowlan, Sean]

>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

I don't see a need to change how it's currently being done, i.e., using 
string_to_symbol. I had just asked the question because I was curious, and I 
think the outK "workaround" is useful because it corresponds with how GRC 
automates naming with <nports>.


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