On Mon, Mar 21, 2016 at 8:50 PM Cody Permann <codyperm...@gmail.com> wrote:
> On Mon, Mar 21, 2016 at 6:34 PM Derek Gaston <fried...@gmail.com> wrote: > >> >> 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. > Sure: I overstated slightly due to losing quite a bit of time to this this evening ;-) Of course there _are_ uses... but I don't think this is one of them. There is no reason why the System's pointer to a solution vector should get invalidated if I get a copy of that pointer... > 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? > You just haven't used "auto" enough yet (that's not an indictment... just saying that I felt the same way you did until I started using it more). Type checking still happens... everywhere. Your API will still need to specify exactly what kind of ID you are expecting... and if it's not compatible with what I have it will still generate an error (or do automatic type casting just like normal). You can't declare a function with "auto" as types of parameters! "auto" doesn't magically make C++ into a scripting language that does run-time type evaluation! > 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. > No - nothing is happening at "run time" with "auto". It's fully resolved at compile time and all type checking is done. > 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 > "open up that object"? What does that mean? Again: this isn't Python... you don't need to do "type(variable)" or something. All you would need to do is look at the function you are calling to see what it returns. Anyway - wrong list here. I just don't want you to start to have a negative bias against "auto". It really is very useful... and not just for being "lazy". Derek ------------------------------------------------------------------------------ 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 Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
