Recently, I was trying to debug some code on my weekend spare time, to help out a former employer who needs a bug fixed in a C++ application. I removed an ad-hoc shared memory implementation previously, and substituted a well known and trusted shared memory implementation, called Boost::Interprocess.
I really don't see a reasonable alternative to Boost::Interprocess for C++ shared memory, but I really haven't gained any love for C++ during this exercise. In fact, my antipathy towards C++ has grown towards what you might call full blown hatred of Modern Boost::style::C++. I think that I would like to make a T-Shirt that says....
Is that a ...
boost::intrusive::detail::tree_algorithms<
boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void,int,unsigned int,0>,1> >::find<
int,boost::intrusive::detail::key_nodeptr_comp<boost::container::container_detail::rbtree<int,std::pair<int const ,DATAPOINT>,
boost::container::container_detail::select1st<std::pair<int const ,DATAPOINT> >,std::less<int>,boost::interprocess::allocator<std::pair<int const ,DATAPOINT>,
boost::interprocess::segment_manager<char,boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,int,unsigned int,0>,0>,
boost::interprocess::iset_index> > >::key_node_compare<boost::container::container_detail::tree_value_compare<int,std::pair<int const ,DATAPOINT>,std::less<int>,
boost::container::container_detail::select1st<std::pair<int const ,DATAPOINT> > > >,
boost::intrusive::rbtree_impl<boost::intrusive::setopt<boost::intrusive::detail::base_hook_traits<boost::container::container_detail::rbtree_node<std::pair<int const ,DATAPOINT>,
boost::interprocess::offset_ptr<void,int,unsigned int,0> >,boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void,int,unsigned int,0>,1>,0,
boost::intrusive::default_tag,3>,boost::container::container_detail::node_compare<boost::container::container_detail::tree_value_compare<int,std::pair<int const ,DATAPOINT>,
std::less<int>,boost::container::container_detail::select1st<std::pair<int const ,DATAPOINT> > >,boost::container::container_detail::rbtree_node<std::pair<int const ,DATAPOINT>,
boost::interprocess::offset_ptr<void,int,unsigned int,0> > >,unsigned int,1> > > >(const boost::interprocess::offset_ptr<boost::intrusive::compact_rbtree_node<boost::interprocess::offset_ptr<void,int,unsigned int,0> > const ,
int,unsigned int,0> & header={...}, const int & key=3, boost::intrusive::detail::key_nodeptr_comp<boost::container::container_detail::rbtree<int,std::pair<int const ,DATAPOINT>,
boost::container::container_detail::select1st<std::pair<int const ,DATAPOINT> >,std::less<int>,boost::interprocess::allocator<std::pair<int const ,DATAPOINT>,
boost::interprocess::segment_manager<char,boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,int,unsigned int,0>,0>,
boost::interprocess::iset_index> > >::key_node_compare<boost::container::container_detail::tree_value_compare<int,std::pair<int const ,DATAPOINT>,std::less<int>,
boost::container::container_detail::select1st<std::pair<int const ,DATAPOINT> > > >,
boost::intrusive::rbtree_impl<boost::intrusive::setopt<boost::intrusive::detail::base_hook_traits<boost::container::container_detail::rbtree_node<std::pair<int const ,DATAPOINT>,
boost::interprocess::offset_ptr<void,int,unsigned int,0> >,boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void,int,unsigned i comp={...})
... in your call stack or are you just happy to see me?
How would you feel debugging a line of call-stack items of the above level of complexity, where the above is simply 1 of about 20 similar levels of function calls. Why even print that crap, we may as well go back to debugging via memory addreses in the EXE file, and naming these things checkpoint Fred, checkpoint Charlie and checkpoint Dave.
Anyways, before you go absolutely crazy with Spring4D and try to create an equivalent mess in Delphi now that we have generics which are a lot less powerful than modern C++ templates, but still powerful enough to create a lot of trouble, ask yourself, do you really really want to debug a call stack that has a few dozen TFactoryProxy<
TDependencyInversionContainer<
TRedBlackTreeImplementation,
TMyFactoryProxyClassBeanMetaClass>>>
expressions when you break it?