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