Today, I wrote a parser in C++.

The slightly alarming thing is that it almost works correctly too. (It's 
not quite finished yet.)

And no segfaults! It turns out that if you throw enough STL containers 
at the problem, you can make it work without any manual pointer 
manipulation. (I shudder to think what the performance is like... 
Fortunately the input to the parser will always be small.)

It took 4 employees approximately 4 hours to get VisualStudio to 
successfully compile and link the code. (There are external 
dependencies, and the program is split into two projects which have to 
cross-reference each other correctly, and so on.) VS is really very 
clunky with C++ code.

It then took me about half an hour to write the parser test cases, and 
the rest of today to write the actual parser. Nested subexpression 
parsing still isn't working quiet right yet, so I need to go take a look 
at that.

I must say, when I signed up for a job as a C# programmer, I didn't 
think I'd spend 3 months writing Bash scripts, two weeks writing 
VBScript and then a day writing C++ code... :-P

Post a reply to this message

On Mon, 13 May 2013 20:09:39 +0200, Orchid Win7 v1 <voi### [at] devnull> wrote:

> Today, I wrote a parser in C++.
>

> I must say, when I signed up for a job as a C# programmer, I didn't  
> think I'd spend 3 months writing Bash scripts, two weeks writing  
> VBScript and then a day writing C++ code... :-P

Sounds exciting ;)

-- 
-Nekar Xenos-

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:

>
> I must say, when I signed up for a job as a C# programmer, I didn't
> think I'd spend 3 months writing Bash scripts, two weeks writing
> VBScript and then a day writing C++ code... :-P

It's the overly-detailed, over-inflated job 'qualifications' requirements :-P

To be a brick-layer these days, the qualifications probably read: "Must be
familiar with silicon/water chemistry on the atomic level, plus five years of
academic training in geometry. Phd in architectural design a plus."

Post a reply to this message

> It took 4 employees approximately 4 hours to get VisualStudio to
> successfully compile and link the code. (There are external
> dependencies, and the program is split into two projects which have to
> cross-reference each other correctly, and so on.) VS is really very
> clunky with C++ code.

After having spent a few years with VS and C#, a few months ago I tried 
again VS for C++ and agree it's still very clunky in comparison. Not 
sure if that's more a limitation of C++ compared to C#, but it's 
certainly not as user friendly.

> I must say, when I signed up for a job as a C# programmer, I didn't
> think I'd spend 3 months writing Bash scripts, two weeks writing
> VBScript and then a day writing C++ code... :-P

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

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> And no segfaults! It turns out that if you throw enough STL containers 
> at the problem, you can make it work without any manual pointer 
> manipulation.

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.

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
(especially if it's eg. a smallish array that's a member variable of a
class that gets instantiated a lot.)

You can still index those out-of-bounds, but many compilers, eg. Visual
Studio, will add boundary checks when compiling in debug mode. (The
boundary checks are not used in release mode for efficiency.)

-- 
                                                          - Warp

Post a reply to this message

> 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