Orchid Win7 v1 <voi### [at] devnull> wrote:
> spend 3 months writing Bash scripts, two weeks writing
> VBScript and then a day writing C++ code... :-P

you truly suck at bash ;)

Post a reply to this message

OK, so I have a class that looks like this:

   class Foobar
   {
     private:
       Secrets secrets;
     public:
       int Foo1();
       int Foo2();
       int Foo3();
   };

Now I want to put that in a header file. What I *actually* want to write is

   class Foobar
   {
     public:
       int Foo1();
       int Foo2();
       int Foo3();
   };

However, this doesn't work at all, because now the "real" Foobar class 
is a different size to what all the clients of Foobar are expecting. 
General mayhem ensues.

So I have to put the entire class definition into the header file. But 
that means I have to put Secrets into the header file too - a data 
structure that clients have absolutely no reason to know anything about. 
(And I have to include everything that Secrets mentions, and everything 
that those things mention, and...)

I thought perhaps I could just write an empty forward declaration, but 
unsurprisingly that doesn't work; the compiler needs size information.

After Googling it, the only solution I could find was to make the 
private field a *pointer* to the secret data. Now I can put a dummy 
forward declaration in the header file, and define the real data 
structure in the implementation, where it belongs.

And now I'm doing manual memory management. >_<

The example I got from Google shows a class with a constructor and a 
destructor - so, following Warp's teachings, my immediate reaction is 
"what the hell happens if somebody copies the object?" I fear the 
secrets will be double-freed at some point.

My question is... Is there some simple change I might make to the code 
to avoid all the gotchas of manual memory management?

I mean, there will only ever be one object, created in one place, so it 
"should" be fine... but it still makes me nervous. If some day somebody 
tries to use the code in a new way, I don't want it to suddenly fail in 
a spectacular way so some poor sod has to spend 3 weeks trying to figure 
out why...

Post a reply to this message

On 15/05/2013 12:34 AM, nemesis wrote:
> Orchid Win7 v1<voi### [at] devnull>  wrote:
>> spend 3 months writing Bash scripts, two weeks writing
>> VBScript and then a day writing C++ code... :-P
>
> you truly suck at bash ;)

Oh, and I suppose *you* know exactly how to parse the output of sfdisk 
to generate a valid mtab entry? :-P

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> On 15/05/2013 12:34 AM, nemesis wrote:
> > Orchid Win7 v1<voi### [at] devnull>  wrote:
> >> spend 3 months writing Bash scripts, two weeks writing
> >> VBScript and then a day writing C++ code... :-P
> >
> > you truly suck at bash ;)
>
> Oh, and I suppose *you* know exactly how to parse the output of sfdisk
> to generate a valid mtab entry? :-P

just a joke about the duration of your bash programming versus C++ :)

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> So I have to put the entire class definition into the header file. But 
> that means I have to put Secrets into the header file too - a data 
> structure that clients have absolutely no reason to know anything about. 

If having the internal-implementation-detail as a member variable of
the class is something you just must avoid, and especially if this is
a class that doesn't get instantiated a lot, then the solution is to
use the Pimpl idiom, which regardless of the funny name, is exactly what
you described. In other words, make a forward declaration of that private
class and just have a pointer to it as member.

> My question is... Is there some simple change I might make to the code 
> to avoid all the gotchas of manual memory management?

Yes: Use std::shared_ptr instead of a raw pointer. In other words, you do
it like this:

    class PrivateClass;

    class MyClass
    {
        std::shared_ptr<PrivateClass> privateObject;
    };

Then in the implementation of MyClass just do a:

    privateObject = new PrivateClass;

and then you can forget about managing it yourself.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>     class PrivateClass;

>     class MyClass
>     {
>         std::shared_ptr<PrivateClass> privateObject;
>     };

Oh, and take into account that if instances of MyClass are copied around,
the copies will share the one and same PrivateClass object. That will not
get deep-copied. (That's what the "shared ptr" means, actually.)

If you want to avoid MyClass being copied around, that can be disabled.
(Of course this restricts the ways in which the class can be used, so
it's always a compromise.)

Another possibility is to write a copy constructor and a copy assignment
operator that deep-copies the private object... It all depends on how
exactly you need MyClass to behave.

-- 
                                                          - Warp

Post a reply to this message

>>      class PrivateClass;
>
>>      class MyClass
>>      {
>>          std::shared_ptr<PrivateClass>  privateObject;
>>      };

OK. That seems easy enough.

> Oh, and take into account that if instances of MyClass are copied around,
> the copies will share the one and same PrivateClass object. That will not
> get deep-copied. (That's what the "shared ptr" means, actually.)

There "should" only ever be one instance of this class; I'd just like to 
avoid the program exploding if somebody *does* copy that instance for 
some reason. A shallow copy is acceptable.

Post a reply to this message

> There "should" only ever be one instance of this class; I'd just like to
> avoid the program exploding if somebody *does* copy that instance for
> some reason. A shallow copy is acceptable.

Is there a C++ equivalent to the C# static class? That would ensure at 
compile-time that nobody tried to create an(other) instance.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > There "should" only ever be one instance of this class; I'd just like to
> > avoid the program exploding if somebody *does* copy that instance for
> > some reason. A shallow copy is acceptable.

> Is there a C++ equivalent to the C# static class? That would ensure at 
> compile-time that nobody tried to create an(other) instance.

You could use a namespace instead of a class. Private implementation can
then all go to the source file, away from the header file.

On the other hand, this limits where you can use this "pseudoclass" and
it could be difficult to maintain backwards compatibility if you ever
wanted to change it so that more than one instance could be created.

Of course you could have a class that only has static member functions...

-- 
                                                          - Warp

Post a reply to this message

Le 16/05/2013 17:27, Warp nous fit lire :
> scott <sco### [at] scottcom> wrote:

>> Is there a C++ equivalent to the C# static class? That would ensure at 
>> compile-time that nobody tried to create an(other) instance.
> 

You can either have all methods of a class static, or use a singleton
pattern.

> You could use a namespace instead of a class. Private implementation can
> then all go to the source file, away from the header file.
> 
> On the other hand, this limits where you can use this "pseudoclass" and
> it could be difficult to maintain backwards compatibility if you ever
> wanted to change it so that more than one instance could be created.
> 
> Of course you could have a class that only has static member functions...
>

Post a reply to this message