On Mon, Mar 21, 2016 at 6:34 PM Derek Gaston <[email protected]> wrote:
> I guess. I had no idea that UniquePtr would _nullify_ the one _inside_ > the object! To me, this is a problem with using a UniquePtr... I really > think this should be a std::shared_ptr... so it can get passed around just > like a normal pointer would. > > Seriously: when do we ever want to leave a dangling null pointer behind > because of an assignment!??! You should only do that in the case that it's > _not safe_ for the previous owner to still have a pointer to the object. > That is NOT the case for the pointer to the solution vector. > > Just to reiterate: by doing a simple assignment it left a dangling NULL > pointer in the middle of a critical libMesh object! > There are lots of uses for unique pointer. I don't want to start a debate on the list but just Google around a bit, you'll find a few. Shared pointers aren't perfect for every situation. You can run into issues with circular references (normal reference count problems) if you don't deal with them plus they (may) have more overhead. All that being said, this particular use may be incorrect. I haven't actually looked at the intent of the code but it just takes a little thinking. > > But I absolutely do agree about "auto". Using it or not is pretty > arbitrary and we are going to have to come up with a set of rules. My own > personal "auto ethics" currently boil down to this... I use it when: > > 1. The type is complicated (like templated types) > 2. The type might change in the future > > #2 is actually really useful if you think about it... it means that code > that uses "auto" is MUCH more future-proof. For instance: I now use "auto" > a lot instead of "unsigned int" for everything coming back as an "id" (so I > don't need to get dof_id_type, max_id_type, other_id_type, right... it will > just always be the right type... and if that type changes in the future the > code is future proof). > > I'm not sure I completely agree with your comment. Yes, it's nice because now C++ feels more like a scripting language. You want an int "thingy" so just declare it as auto and it basically behaves like an int "thingy". What about the case where you actually want to check for type correctness? Maybe I want to check that you are actually passing me a processor_id type for my API and not just some int thingy? The easiest sell has got to be iterators. I'm not sure that I like the next step of using "auto" to catch return types in good library code. I think if we start using this too frequently in the library we'll find ourselves spending time tracking down more runtime bugs that could have just been a quick compiler type error. Maybe the rule is does this type matter at all for this context or is it just visual noise? If I see auto catching a return type do I now need to open up that object to find the type that's coming back? It might cost us more development time when you get to maintaining the code. </soap box> But yeah: we're going to need some rules... > > Derek > > On Mon, Mar 21, 2016 at 8:26 PM Cody Permann <[email protected]> > wrote: > >> I think "auto" is going to turn out to be one of those really annoying >> keywords. We will have endless debates about what contexts are appropriate >> for it's use and where it should be avoided. That line of code seems simple >> enough but if you had actually typed "UniquePtr solution_vector ..." we all >> would have spotted that error sooner! >> >> >> On Mon, Mar 21, 2016 at 6:22 PM Kirk, Benjamin (JSC-EG311) < >> [email protected]> wrote: >> >>> >>> On Mar 21, 2016, at 7:12 PM, Derek Gaston <[email protected]<mailto: >>> [email protected]>> wrote: >>> >>> Fixed it. >>> >>> Nice catch. I was looking at every *other* line. >>> >>> >>> ------------------------------------------------------------------------------ >>> Transform Data into Opportunity. >>> Accelerate data analysis in your applications with >>> Intel Data Analytics Acceleration Library. >>> Click to learn more. >>> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 >>> _______________________________________________ >>> Libmesh-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/libmesh-users >>> >> ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
