> You mean you haven't found an excuse to use POV yet!?! (and then
> obviously the newsgroups as well...)

Well, I did use my IRTC entry for some of our test data...

Post a reply to this message

On 14/05/2013 06:04 PM, Warp wrote:
> When using the standard containers, one should know how they work and
> what they are doing, in terms of efficiency. For example, passing them
> by value eg. as function parameters is inefficient, and that should always
> be done by reference, if possible.

How about std::string? Presumably it's a bad idea to pass that by value 
either...

> And also, of course, use the right tool for the job. It makes no sense
> to use, for example, std::list for something that std::vector will do.
> And if your array is of static size, use std::array instead of std::vector

All this stuff is pretty dynamic. I have no idea how big the expression 
I'm parsing will be until after I finish parsing it.

I'm sure if you could see my code, you'd probably have a heart attack 
over all the highly inefficient stuff it's doing. Then again, it gets 
run once at application start-up, parsing a few dozen strings that are 
mostly a dozen characters long each, so...

(Perhaps the biggest inefficiency is having a lot of zero-element 
vectors laying around. I have no idea what the space overhead for that 
is. But I also have no idea how to avoid it.)

Post a reply to this message

On 13/05/2013 07:09 PM, Orchid Win7 v1 wrote:
> The slightly alarming thing is that it almost works correctly too. (It's
> not quite finished yet.)

At about 2AM, I rolled over in bed and realised why this is broken.

   std::vector<Stuff> current = stack.back();
   current.push_back(more_stuff);

Uh, yes... that doesn't do what I meant AT ALL! >_<

Still, I'm impressed I managed to figure out the bug when I don't even 
have access to the code...

Post a reply to this message

On 13/05/2013 07:09 PM, Orchid Win7 v1 wrote:
> It took 4 employees approximately 4 hours to get VisualStudio to
> successfully compile and link the code.

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... >_<

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> On 14/05/2013 06:04 PM, Warp wrote:
> > When using the standard containers, one should know how they work and
> > what they are doing, in terms of efficiency. For example, passing them
> > by value eg. as function parameters is inefficient, and that should always
> > be done by reference, if possible.

> How about std::string? Presumably it's a bad idea to pass that by value 
> either...

It depends on the implementation.

Since std::string is so ubiquitous, many standard library implementations
have optimizations that make copying them fast (some use short string
optimization, some use lazy copying...), but that's in no way a guarantee.

There's usually no reason to not to use a std::string reference if it
suffices. Only copy when you have to.

-- 
                                                          - Warp

Post a reply to this message

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