Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.c++.moderated    |    Moderated discussion of C++ superhackery    |    33,346 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 33,337 of 33,346    |
|    fmatthew5876 to Thomas Richter    |
|    Re: Uniquely identifying types at runtim    |
|    19 May 14 11:48:03    |
   
   From: fmatthew5876@googlemail.com   
      
   { Please limit your text to fit within 80 columns, preferably around 70,   
    so that readers don't have to scroll horizontally to read each line.   
    This article has been reformatted manually by the moderator. -mod }   
      
   On Saturday, May 17, 2014 8:56:54 PM UTC-4, Thomas Richter wrote:   
   > The output of typeid() is compiler dependent and not standardized.   
   > In specific, if a library is compiled with a different compiler,   
   > typeid() may work completely different, thus you cannot compare   
   > the output of typeid() from the code generated by one compiler with   
   > the output of typeid() created by another compiler.   
   >   
   That should be ok for my use case. This is an internal project and   
   all clients will be using the same compiler and development setup.   
   As long as each type (polymorphic or not) has a unique typeid()   
   it should solve my problem.   
      
   Does anyone know of any good method of doing this which would be portable?   
      
   On Saturday, May 17, 2014 9:08:08 PM UTC-4, Norman J. Goldstein wrote:   
   > Do you mean that any class where you are calling typeid() is either   
   > the most derived class, or it is polymorphic?   
      
   I will be using typeid() on classes which may not be using inheritance   
   at all.   
      
   This is for a parallel framework which will be designed using the   
   dataflow based programming paradigm. That is nodes connected by data   
   channels which can all run in parallel. The users will inherit from   
   a node base class and specify what the supported inputs and outputs   
   are via variadic template parameters. This will give the users type   
   safety (no nasty void* reinterpret_cast like in many other frameworks)   
   and make it easier for them to plugin nodes to add functionality.   
      
   Under the hood, I will be type erasing the input and ouput data channels   
   void* and use a generic MPMC concurrent queue.   
      
   I want users to be able to connect nodes into a graph at run-time using   
   a config file, so I cannot rely on the compiler to do static type   
   checking. Instead, I can use typeid() on the inputs and outputs and   
   throw an exception when the user tries to link up 2 nodes whose input   
   and output types don't match.   
      
   > There is an interesting discussion at   
   >   
   > http://stackoverflow.com/questions/2709669/rtti-and-portability-in-c   
      
   Thanks, that was helpful.   
      
      
   --   
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
    [ comp.lang.c++.moderated. First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca