On 14/05/2013 06:29 PM, Orchid Win7 v1 wrote:
> But that's nothing compared to how long it took to get VS to produce a
> DLL, and then get C# to successfully call this DLL without access
> violations... >_<

But THAT is nothing compared to the trouble we had trying to build a 
Linux "shared object" and getting Mono to load that...

I can still hardly believe that this whole improbable contraption 
actually ended up WORKING in the end! o_O

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> You can either have all methods of a class static, or use a singleton
> pattern.

If you are using an enforced singleton, and you don't want to expose
*any* implementation detail to the outside, one possibility would be
to do this:

//------------------------------------------------------------
// In the header file:
// ------------------

class TheClass
{
 public:
    virtual void someFunction() = 0;
    virtual int anotherFunction(int parameter) = 0;
    virtual void aThirdFunction(double, double) = 0;
};

TheClass& theClassInstance();
//------------------------------------------------------------

//------------------------------------------------------------
// In the implementation file:
// --------------------------

#include "TheClass.hh"

namespace
{
    class TheActualClass: public TheClass
    {
        struct InnerType { int a, b; }

        int privateMember;
        double anotherPrivateMember;
        InnerType aThirdPrivateMember;

        void privateFunction();

     public:
        TheActualClass() { /* constructor */ }

        virtual void someFunction()
        {
            // implement it here
        }

        virtual int anotherFunction(int parameter)
        {
            // implement it here
        }

        virtual void aThirdFunction(double, double)
        {
            // implement it here
        }
    };
}

TheClass& theClassInstance()
{
    static TheActualClass actualClassInstance;
    return actualClassInstance;
}
//------------------------------------------------------------

-- 
                                                          - Warp

Post a reply to this message

On 16/05/2013 08:39 AM, Orchid Win7 v1 wrote:
>>> class PrivateClass;
>>
>>> class MyClass
>>> {
>>> std::shared_ptr<PrivateClass> privateObject;
>>> };
>
> OK. That seems easy enough.

I entered this into VisualStudio, and it worked great.

However, when I tried to compile it under Linux, GCC refused to accept it.

First, VS seems to somehow allow you to compile things even without 
actually importing the necessary include files. (E.g., it will happily 
accept std::shared_ptr even though I didn't #include <memory>.) GCC 
demands that you actually specify the include files [like you'd expect]. 
Weird, but true.

Second, it seems this "feature" only exists in C++11. I don't know what 
GCC is defaulting to, but apparently you have to add a switch to tell it 
to accept C++11. And when I do that, my code compiles perfectly, but the 
rest of the codebase breaks spectacularly.

So, in summary, I had to revert everything back to how it was. *sigh*

Post a reply to this message

On 16/05/2013 06:46 PM, Orchid Win7 v1 wrote:
> I can still hardly believe that this whole improbable contraption
> actually ended up WORKING in the end! o_O

The daft thing is, it turns out to actually be pretty easy to write some 
C++, make a DLL out of it, and call that from C#. The actual code that 
ended up in source control is both small and simple.

This belies the vast amount of man-hours it took to *arrive* at this 
final arrangement. It took an absurd amount of Google searches and 
trail-and-error to get the myriad of pieces to fit together just right.

In summary, it's easy when you know how. So easy, presumably, that 
nobody bothers to write down how it's actually done - so the next person 
who tries to do this will have the exact same problem. :-/

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> Second, it seems this "feature" only exists in C++11. I don't know what 
> GCC is defaulting to, but apparently you have to add a switch to tell it 
> to accept C++11. And when I do that, my code compiles perfectly, but the 
> rest of the codebase breaks spectacularly.

> So, in summary, I had to revert everything back to how it was. *sigh*

You could use std::auto_ptr instead of std::shared_ptr, but then you'd
better disable copying for your class.

-- 
                                                          - Warp

Post a reply to this message

On 5/17/2013 11:16 AM, Warp wrote:
> Orchid Win7 v1 <voi### [at] devnull> wrote:
>> Second, it seems this "feature" only exists in C++11. I don't know what
>> GCC is defaulting to, but apparently you have to add a switch to tell it
>> to accept C++11. And when I do that, my code compiles perfectly, but the
>> rest of the codebase breaks spectacularly.
>
>> So, in summary, I had to revert everything back to how it was. *sigh*
>
> You could use std::auto_ptr instead of std::shared_ptr, but then you'd
> better disable copying for your class.
>

Or use boost::shared_ptr of course.

Actually, this reminds me that I should update some of my own code from 
boost:shared_ptr to std::shared_ptr.

Post a reply to this message

On 15/05/2013 10:44 PM, Warp wrote:
> 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 next question was going to be "is there a way to expose part of a 
class so that the test framework can access it, but nothing else can?"

And then I read the documentation for our test framework [GTest, in case 
anybody cares], and it says to do basically the same thing as the above. 
IOW, make a private class, put it in its own header file, let the test 
framework include that header file, but nobody else.

Not sure if it's worth it just to hide one single method, but it might 
be useful in other parts of the codebase...

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> And then I read the documentation for our test framework [GTest, in case 
> anybody cares], and it says to do basically the same thing as the above. 
> IOW, make a private class, put it in its own header file, let the test 
> framework include that header file, but nobody else.

In principle if a class or function exists in a namespace that's not
local to a compilation unit (in other words, a nameless namespace inside
a compilation unit), it will be visible globally and could therefore
technically speaking be used by everything else.

Unlike it might seem, header files in C/C++ are not a language feature.
They are not syntax that imposes some kind of semantics (eg. access
restrictions or something like that.) It's not like other code couldn't
use some class or function if it doesn't have access to the header file
that declares them.

Header files are both a convenience and an abstraction tool, but are
strictly speaking unnecessary.

Let's say that you *know* that somewhere in the innards of some compilation
unit (which might be eg. a library) there's a function named 'foo' which
takes an int and returns an int, which is in the global namespace. Even
if you have no access to any header that declares said function, you can
still just write in your own code:

//----------------------------------------------------------------
int foo(int);

void myFunction()
{
    foo(5);
}
//----------------------------------------------------------------

With classes it becomes a bit more complicated because you need to
know the exact contents of the class. However, technically speaking
if you know that you don't need any header file to use it.

Of course all this is mostly theoretical.

-- 
                                                          - Warp

Post a reply to this message

>>> So, in summary, I had to revert everything back to how it was. *sigh*
>>
>> You could use std::auto_ptr instead of std::shared_ptr, but then you'd
>> better disable copying for your class.
>
> Or use boost::shared_ptr of course.

OK, so I went with boost::shared_ptr in the end.

However, I can't seem to figure out what to write in the constructor. 
I've got a field that looks like

   boost::shared_ptr<std::vector<Foo>> _foo;

What do I need to do to initialise this correctly?

Post a reply to this message

On 20/05/2013 09:15 PM, Warp wrote:
> Of course all this is mostly theoretical.

Yeah. Assuming that my fellow coders aren't *purposely* trying to break 
things, I just want to structure the code I'm writing in a way which 
minimises the potential for mistakes, that's all.

(We've got some code which is only public so that the test suite can 
run. It makes me feel slightly twitchy, but hey...)

Post a reply to this message