I will look that up :-) Just one last question: In the constructed a class I store a DoFHandler and Triangulation object as member variables like this: SmartPointer<const DoFHandler<dim>> dof_handler; SmartPointer<const Triangulation<dim>> triangulation;
I created the instance at the same time when constructing the Solid instance (pM = boost::make_shared<.......>) After a few loadsteps my solid triangulation changes and the DoFHandler as well (standard adaptivity). The instance of the other class where I stored the just mentioned SmartPointers is "aware" of that, i.e. I don't update the SmartPointers after adaptivity. Of course the (smart)pointer stores the address of the triangulation, but is it not possible that the the call "triangulation.execute_refinement()" makes the triangulation object too big so that it has to be reallocated at another adress (->address changes)? So is that what I observe something like undefined behaviour or do calls like "dof_handler.distribute_dofs(fe)" or "triangulation.execute_refinement()" indeed don't change the address of the underlying triangulation (dof_handler) in memory? Thank you very much again! Am Mi., 7. Juli 2021 um 06:35 Uhr schrieb Wolfgang Bangerth < bange...@colostate.edu>: > On 7/6/21 2:45 AM, Simon Wiesheier wrote: > > > > Is it also possible to get a reference (pointer) to the Solid object > within > > the constructor of 'AnotherClass', so without passing a solid reference > to the > > latters constructor? 'this' would in this case refer to the instance of > > 'AnotherClass'. > > > > The class 'AnotherClass' needs access to objects of type DoFHandler<dim> > and > > CellDataStorage<typename T>. As for the DoFHandler<dim> the copy > instructor, > > i.e something like 'dof_handler(dof_handler_from_solid)' will delete > > 'dof_handler_from_solid'. It actually doesn't delete it but throws an > > exception as it is also described in the documentation. > > I checked a few source code files of the library how they manage the > storage > > of large objects, for instance the GridTools::Cache<dim> class stores a > > triangulation like this: > > SmartPointer<const Triangulation<dim>> tria; > > So I did this in the same way for the DoFHandler and the CellDataStorage > object: > > SmartPointer<const DoFHandler<dim>> dof_handler; > > ... > > Is this a efficient way to do that or is there a more sophisticated way > to > > store the member variables? I asked myself why dealii did not just use > the > > SmartPointers of the c++ standard library, namely std::shared_ptr<...>, > > std::unique_ptr<...>,.... I guess most of them also make sure that they > don't > > become dangling pointers. > > All of this is possible with minimal pain by using "lambda functions" and > "captured variables". You might want to read up on them in a recent C++ > book :-) > > Cheers > W. > > > -- > ------------------------------------------------------------------------ > Wolfgang Bangerth email: bange...@colostate.edu > www: http://www.math.colostate.edu/~bangerth/ > > -- > The deal.II project is located at http://www.dealii.org/ > For mailing list/forum options, see > https://groups.google.com/d/forum/dealii?hl=en > --- > You received this message because you are subscribed to the Google Groups > "deal.II User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dealii+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/dealii/0bad1924-dbba-c826-d91e-ed56c17767a6%40colostate.edu > . > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/CAM50jEuuDrsx0i6SFOw6fTUw3ByTVXLRvEyeJEiP2PX9iivMWQ%40mail.gmail.com.
