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

On 5/21/2013 10:25 AM, Orchid Win7 v1 wrote:
> 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?


boost::shared_ptr<std::vector<Foo>> _foo(new std::vector<Foo>());

Take a look over the constructors of shared_ptr for more detail.  I 
should note that it's relatively uncommon that I want a shared_ptr to a 
std::vector.  Unless you actually need to store _foo somewhere else in 
the code it's might be better to just forgo the shared_ptr and pass _foo 
by reference to whichever functions need it.

Post a reply to this message

On 5/21/2013 10:32 AM, Kevin Wampler wrote:
> On 5/21/2013 10:25 AM, Orchid Win7 v1 wrote:
>> 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?
>
>
> boost::shared_ptr<std::vector<Foo>> _foo(new std::vector<Foo>());
>

Oh, and it's probably best to write it like this:

boost::shared_ptr<std::vector<Foo> > _foo(new std::vector<Foo>());

Since some compilers will complain about using >> in a type definition 
(due to the ambiguity with the >> operator).

Post a reply to this message

On 21/05/2013 06:32 PM, Kevin Wampler wrote:
> On 5/21/2013 10:25 AM, Orchid Win7 v1 wrote:
>> 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?
>
>
> boost::shared_ptr<std::vector<Foo>> _foo(new std::vector<Foo>());
>
> Take a look over the constructors of shared_ptr for more detail. I
> should note that it's relatively uncommon that I want a shared_ptr to a
> std::vector. Unless you actually need to store _foo somewhere else in
> the code it's might be better to just forgo the shared_ptr and pass _foo
> by reference to whichever functions need it.

The only reason I'm doing this is to avoid putting the real definition 
of Foo in the header file.

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> 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?

What do you mean by "field"? Your question is not clear enough.

(And btw, don't start names with an underscore. Those are reserved for
the compiler.)

-- 
                                                          - Warp

Post a reply to this message

On 22/05/2013 08:45 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull>  wrote:
>> 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?
>
> What do you mean by "field"? Your question is not clear enough.

I mean something like

   class Foobar
   {
     private:
       boost::shared_ptr<std::vector<Foo>> foo;
     public:
       Foobar()
   }

> (And btw, don't start names with an underscore. Those are reserved for
> the compiler.)

Hoooookay... In that case, there's about 200 lines in the existing 
codebase that need to be changed. o_O

Post a reply to this message