2008/12/3 Anders Logg <[EMAIL PROTECTED]>: > On Wed, Dec 03, 2008 at 05:29:14PM +0100, Martin Sandve Alnæs wrote: >> 2008/12/3 Anders Logg <[EMAIL PROTECTED]>: >> > On Wed, Dec 03, 2008 at 03:18:35PM +0100, [EMAIL PROTECTED] wrote: >> >> The Buildbot has detected a new failure of linux_64. >> >> Full details are available at: >> >> http://fenics.org:8010/dolfin/linux_64/builds/1082 >> >> >> >> Buildbot URL: http://fenics.org:8010/dolfin/ >> >> >> >> Buildslave for this Build: x64-linux >> >> >> >> Build Reason: >> >> Build Source Stamp: HEAD >> >> Blamelist: Anders Logg >> >> >> >> BUILD FAILED: failed test >> >> >> >> sincerely, >> >> -The Buildbot >> >> >> >> _______________________________________________ >> >> DOLFIN-dev mailing list >> >> [email protected] >> >> http://www.fenics.org/mailman/listinfo/dolfin-dev >> > >> > Should be fixed now. I removed the extra test added to >> > Coefficient::attach. >> > >> > Don't know yet why the extra test breaks (probably in the call to >> > Function::in). >> >> This call compares the function space object addresses, so it's no >> wonder it fails. > > That might very well be the reason, but the error message seems to > indicate something else. > > But why shouldn't it be ok to compare the pointers? I imagine that > shared_ptr has implemented a reasonable comparison operator that does > the right thing.
In this case because you were sending in one "old" pointer and one newly created. They could never be the same. And in general, if someone does _not_ reuse FunctionSpaces optimally, we'll get a situation where V1 is a function space on the same mesh and with the same element as V0. Then given Function f(V0);, we should have f.in(V1) == true, while &V0 != &V1. -- Martin _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
