Class Usage in the FTP Benchmark Code

In general, there is no inheritance among the classes, and all allocations are static. (Exceptions to this rule are noted below.)

The benchmark program 'bench' instantiates a bunch of ftp_client_pipe_t's using the utility function robouser_t::static_init(), which keeps them in the static array roboclient_t::s_users[].

In other words, The one instance of dynamic memory allocation is the array of ftp_client_pipe_t's, roboclient_t::s_users[]. Its elements are dynamically created by roboclient_t::static_init(). Note that this means just about everything is on the heap, but there's very little heap activity - once they're allocated, that's it.

None of the classes has constructors that do very much. To avoid heap fragmentation, the classes stay allocated, and init() and shutdown() methods are used to grab resources (e.g. file handles) as needed.

There aren't many pointers to objects; these include roboclient_t::s_users[], the pointer to Sked passed to robouser_t::static_init() and used in robouser_t::start(), and the pointer to the ftp_client_pipe_datainterface_t passed in to ftp_client_pipe_t::init().

There are two instances of inheritance so far- anything that uses ftp_client_pipe_t must inherit from and implement ftp_client_pipe_datainterface_t, and anything that uses Sked must inherit from and implement SkedClient, That's how the caller is notified that ftp data is waiting, or that a previously scheduled event is occurring. These are two examples of an object-oriented sort of callback function, also known to the Design Pattern crowd as the Observer pattern.