Thread: Virtual design, again

  1. #1
    Kiss the monkey. CodeMonkey's Avatar
    Join Date
    Sep 2001
    Posts
    937

    Virtual design, again

    I asked about this in an earlier thread, but now I have some skeletal code to show for it.

    I'd like to have the functionality as shown in this family of classes. It all boils down to constructing the correct derived type from a simulator pointer and passing it as a thread (or just calling it, for the single threaded case). I should note the the multithreaded version functions as one of the threads, not as something that spawns threads.

    Can anybody think of a more elegant way to do this?
    Code:
    class simulator
    {
    	//constructor: modes, laplacian, region, dt, n.
    public: 
    	virtual void operator()() = 0;
    protected:
    	//all the references and stuff
    };
    
    class single_thread
    {
    	//constructor: modes, laplacian, region, dt, n.
    public: void operator()()
    		{
    			//laplacian
    			//relax
    			//subtract()
    		}
    		virtual void subtract()
    		{
    			//unsynchronized subtract
    		}
    };
    
    class multi_thread
    {
    	//constructor: modes, laplacian, region, dt, n, barrier.
    public: void operator()()
    		{
    			//laplacian
    			//wait()
    			//relax
    			//wait()
    			//subtract()
    			//wait()
    		}
    		virtual void subtract()
    		{
    			//synchronized subtract
    			//TODO: (note to self) How will I pull this off?
    		}
    };
    
    struct low_mode
    {
    	void subtract() {}  //overloads subtract() to do nothing.
    };
    
    struct high_mode
    {
    	//doesn't overload subtract().
    };
    
    ///////////// So.... ///////////
    
    //simulator, single thread, low mode
    class sim_st_lm : public simulator, public single_thread, public low_mode
    {
    	//constructor: modes, laplacian, region, dt, n. 
    };
    
    //simulator, multiple thread, low mode
    class sim_mt_lm : public simulator, public multi_thread, public low_mode
    {
    	//constructor: modes, laplacian, region, dt, n, barrier.
    };
    
    //etc...
    class sim_st_hm : public simulator, public single_thread, public high_mode
    {
    	//constructor: modes, laplacian, region, dt, n.
    };
    
    class sim_mt_hm : public simulator, public multi_thread, public high_mode
    {
    	//constructor: modes, laplacian, region, dt, n, barrier.
    };
    "If you tell the truth, you don't have to remember anything"
    -Mark Twain

  2. #2
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    5,108
    How do you envision using these classes?

    I don't really get what you mean by "passing it [the simulator pointer] as a thread".

    Soma

  3. #3
    Kiss the monkey. CodeMonkey's Avatar
    Join Date
    Sep 2001
    Posts
    937
    My bad. Something like this:

    Code:
    int main()
    {
        collect_input_and_stuff();
    
        boost::ptr_vector<simulator> sims;
        boost::barrier bar;  //This will needlessly exist if nthreads == 1
    
        if(mode_to_get > 0 && threads > 1)
        {
              partition_region();
              sims.resize(nthreads, new sim_mt_hm(...));
        }
        else if( . . . )
        {
              partition_region();
              sims.resize(nthreads, new sim_mt_lm(...));
        }
        else if( . . . )
              sims.resize(nthreads, new sim_st_hm(...));
        else if( . . . )
              sims.resize(nthreads, new sim_st_lm(...));
        else
              throw something;  //I've suppressed try blocks and stuff.
    
        if(mode_to_get == 0)
               ( sims.front() )();
        else
        {
              boost::thread_group tg;
              for(unsigned int i = 0; i < nthreads; ++i)
                  tg.add_thread(sims[i]);
              tg.join_all();
        }
    }//main()
    *edit* It looks like I'll have to implement my own non-member resize(boost::ptr_vector<T>&, size_t n, T&)
    Last edited by CodeMonkey; 01-14-2009 at 12:36 PM. Reason: smile
    "If you tell the truth, you don't have to remember anything"
    -Mark Twain

  4. #4
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    It looks like I'll have to implement my own non-member resize
    No, you just have to support the Cloneable concept for your type.
    http://www.boost.org/doc/libs/1_36_0...l#cloneability
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  5. #5
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    5,108
    I see. (I think.)

    I would arrange the different classes representing the model and the "mode" so that you can glue them together at run-time. This will simplify the inheritance hierarchy. I think that the possibility for shared state will simplify the implementation. (I don't know if I truly understand the intent.)

    Soma

    Code:
    // ...
    threader_implementation * model((threads > 1) ? new multiple_threaded : new single_threaded);
    // ...
    mode_implementation * mode(use_low_mode() ? new low_mode : new high_mode);
    // ...
    simulator * whatever(new simulation(model, mode));
    // ...

  6. #6
    Kiss the monkey. CodeMonkey's Avatar
    Join Date
    Sep 2001
    Posts
    937
    I see. And this is preferable to having four classes because it requires less code?
    *edit* no, because it requires fewer explicit class definitions?
    "If you tell the truth, you don't have to remember anything"
    -Mark Twain

  7. #7
    Kiss the monkey. CodeMonkey's Avatar
    Join Date
    Sep 2001
    Posts
    937
    So simulator would contain a mode_method_type and a thread_method_type? This could work. And the top calling code would be shorter. Thanks.
    Any other clever ideas?
    "If you tell the truth, you don't have to remember anything"
    -Mark Twain

  8. #8
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    5,108
    And this is preferable to having four classes because it requires less code?
    There is no guarantee that it will require less code. That may be the case for any example.

    No, because it requires fewer explicit class definitions?
    There is no guarantee that it will require fewer explicit class definitions. That may be the case for any example.

    So simulator would contain a mode_method_type and a thread_method_type?
    Sure. If that's what you want. Those are just details.

    I think you are over thinking the suggestion. Breaking a class with optional or multiple characteristics into component classes only to glue those components together is just one option in considering a design. Some cases benefit from the tactic while others don't.

    Soma

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Need Partners (D&D fan preferably)
    By C_ntua in forum Game Programming
    Replies: 44
    Last Post: 11-22-2008, 09:21 AM
  2. Replies: 48
    Last Post: 09-26-2008, 03:45 AM
  3. Virtual function design pattern
    By George2 in forum C++ Programming
    Replies: 6
    Last Post: 03-19-2008, 07:18 AM
  4. C++ XML Class
    By edwardtisdale in forum C++ Programming
    Replies: 0
    Last Post: 12-10-2001, 11:14 PM
  5. Exporting Object Hierarchies from a DLL
    By andy668 in forum C++ Programming
    Replies: 0
    Last Post: 10-20-2001, 01:26 PM