On Nov 22, 2010, at 3:43 PM, Roy Stogner wrote:
> I'd originally planned on writing a SharedPtr wrapper that would hook
> to C++0x or to optional boost or to an internal fallback... but maybe
> it's time to bite the bullet and just introduce boost as a libMesh
> dependency? Other opinions would b
On Mon, Nov 22, 2010 at 4:43 PM, Roy Stogner wrote:
>
> The boost suggestion reminds me of something I meant to bring up on
> Friday (before work and vacation packing distracted me): we need to
> use some shared_ptr classes. Vikram's doing some work with the
> ErrorMap, and looking at that again
The boost suggestion reminds me of something I meant to bring up on
Friday (before work and vacation packing distracted me): we need to
use some shared_ptr classes. Vikram's doing some work with the
ErrorMap, and looking at that again reminds me how horrible it is to
force manual memory managemen
> -Original Message-
> From: [email protected] [mailto:[email protected]] On Behalf Of John
> Peterson
>
> On Mon, Nov 22, 2010 at 3:09 PM, Chetan Jhurani
> wrote:
> >> -Original Message-
> >> From: John Peterson [mailto:[email protected]]
> >>
> >> #2a - I agre
On Nov 22, 2010, at 3:32 PM, John Peterson wrote:
> This is a nice solution but IMHO changing the inheritance hierarchy is
> a little intrusive just to get two little functions disabled!
I concur.
Derek
--
Increase Vis
On Mon, Nov 22, 2010 at 3:09 PM, Chetan Jhurani
wrote:
>> -Original Message-
>> From: John Peterson [mailto:[email protected]]
>>
>> #2a - I agree that macros are evil, but this one is pretty benign:
>>
>> #define DISALLOW_COPY_AND_ASSIGN(TypeName) \
>> TypeName(const TypeNam
> -Original Message-
> From: John Peterson [mailto:[email protected]]
>
> #2a - I agree that macros are evil, but this one is pretty benign:
>
> #define DISALLOW_COPY_AND_ASSIGN(TypeName) \
> TypeName(const TypeName&); \
> void operator=(const TypeName&);
J
On Mon, Nov 22, 2010 at 1:25 PM, Derek Gaston wrote:
>
> On Nov 22, 2010, at 10:29 AM, John Peterson wrote:
>
>> So apparently they have some macro to declare copy constructor and op=
>> private when they are not needed. At first I thought this was
>> overkill because I assumed that if you provid
On 11/22/10 12:59 PM, Roy Stogner wrote:
>
> On Mon, 22 Nov 2010, Boyce Griffith wrote:
>
>> FWIW --- the g++ compiler option -Weffc++ can be helpful for tracking
>> down this kind of stuff --- it will emit warnings about classes that
>> violate some of the coding guidelines from Myers' book Effe
On Nov 22, 2010, at 10:29 AM, John Peterson wrote:
> So apparently they have some macro to declare copy constructor and op=
> private when they are not needed. At first I thought this was
> overkill because I assumed that if you provided *any* constructor, the
> compiler doesn't auto-generate th
On Mon, 22 Nov 2010, Boyce Griffith wrote:
> FWIW --- the g++ compiler option -Weffc++ can be helpful for tracking
> down this kind of stuff --- it will emit warnings about classes that
> violate some of the coding guidelines from Myers' book Effective C++,
> including one regarding copy construc
On 11/22/10 12:33 PM, Roy Stogner wrote:
>
> On Mon, 22 Nov 2010, John Peterson wrote:
>
>> So... I'm wondering if we should do something similar (disable op= and
>> copy ctor unless needed and explicitly provided, possibly with a
>> macro) in all of our library classes?
>
> So a bunch of potenti
On Mon, 22 Nov 2010, John Peterson wrote:
> So... I'm wondering if we should do something similar (disable op= and
> copy ctor unless needed and explicitly provided, possibly with a
> macro) in all of our library classes?
So a bunch of potential nasty run-time errors turn into compile-time
error
Hi,
Derek's question about copying SparseMatrix led me to google about
ways to automatically keep constructors up-to-date with class members.
I didn't really find anything about that, but in doing so I came
across one of google's coding style guidelines:
http://google-styleguide.googlecode.com/s
14 matches
Mail list logo
