The Shrine

If you find yourself parsing an input complex enough to require more than three lines of a BNF grammar, check out the Spirit library that is a part of boost. In short, Spirit allows you to specify your input's grammar in a psuedo-EBNF syntax, and that specification is the parser. It's powerful stuff; I'm using it in my current project.

The concept of lexer, parser, and compiler generators is not new - lex and yacc have been around longer than most of us - but I think this library is more flexible. It's inline with the rest of my code, and I can choose to manipulate just text instead of dealing with a whole syntax tree.

This, of course, only applies If you are already working in C++, or you have the option of using it.

Very cool.

Parsing always gives me a headache though it's rare I have to parse anything super complex. I'll throw this into my list of useful links though.

Thanks.

It takes some time and effort to learn how to use the library, so the complexity of your input has to hit some threshold before it's worth your time. But, once you do have an understanding of how to use it, parsing simple inputs is even simpler.

Edit: Most of the value of the library, to me, is that I'm the one who has to discover what the BNF grammar of my input is. Since changing the grammar changes my parser, figuring out the grammar is much easier than were I coding it by hand. All of this is possible with lex and yacc, but having it inlined with the rest of my code makes the process faster and easier.

Boost? C++? Writing grammers in C++? Blech.

Still, the project itself looks pretty interesting.

Ishamael wrote:Boost? C++? Writing grammers in C++? Blech.

Still, the project itself looks pretty interesting.

What do you do nowadays, Ish? Just curious what your job focus is currently.

Lox wrote:

Ishamael wrote:Boost? C++? Writing grammers in C++? Blech.

Still, the project itself looks pretty interesting.

What do you do nowadays, Ish? Just curious what your job focus is currently.

I work on a mixed language project (Python, C++, Java) for a consumer product at a startup. It's quasi-embedded, but it's "embedded" like the XBox360 is "embedded", not like old school cellphone or microwave control pad embedded (i.e., lots of power compared to traditional embedded stuff). I focus on the Python and Java bits, and occasionally dirty myself with the C++ and, god help me, Boost bits.

And what about you guys? IIRC, Lox was working for UPS/Fedex and Kupek was researching some sort of threading related material in grad school.

Yeah, I'm still at UPS. I've finally made the transition from QA (where I was doing 1/2 manual testing and 1/2 writing test tools) to development.

So now, I'm working on a small project to enhance an existing in-house test tool (a VB scripting language that automates our in-house apps written in C++). The enhancements are 1/2 C++ and 1/2 C# as we're enhancing the tool to actually handle .NET applications. Very fun and interesting stuff.

There's a possibility that I will be moving to a app development group soon where I will be doing all C++. If I stay on this test tool project, I'll be moving to some development team around early 2008. I'll either be doing C++ or C# once I'm there.

Have I fallen off the radar completely? (I'm looking for work in So Cal as a game programmer as we speak - just interviewed at THQ.)

BTW, Kup, I've long heard of boost - not familiar with Spirit - but haven't ever been able to use it really, as most game programming environments still aren't terribly friendly to anything with a template argument. But it sounds cool, and if I ever get around to that language project that I've wanted to create on the side for awhile, I'll definitely check it out.

My Master's thesis was an object-oriented library for multithreaded programming. We never followed up on the initial work, which was a mistake. Some of my ideas were very similar to what Intel has implemented with their Thread Building Blocks.

Immediately after that project, I got into lock-free multithreaded memory allocation. That project has dead-ended, and I've moved onto effecient code generation for the Cell processor. (Hence my current need for a parser.)

As for languages, I spent the last two years doing lock-free memory allocation. I lived in C and assembly code land. I didn't want abstractions; I didn't want to hide the fact that I was dealing with raw memory and bytes. But now that I'm no longer doing that, I can choose whatever implementation language I want. C++ is my language of choice. It's the only language that allows for high level abstractions and systems programming at the same time.

But even if I didn't have to do any real systems stuff, I'd still want to use C++ because I think templates allow for a level of power that generics in Java and C# haven't been able to match. Templates are not just glorified macros; it is actually a Turing complete system, and people have created powerful libraries with it. Take templates away from C++, and you're just left with C with Classes (which is what the original implementation was called). It's templates, the STL and boost that allow me to write high level code.

Nev, why don't game development environments allow C++ templates? Do the compilers just not implement it? The amazing thing with templates is that if you use them correctly, the resulting code can actually be more efficient due to having much more information available at compile time.

Kupek wrote:My Master's thesis was an object-oriented library for multithreaded programming. We never followed up on the initial work, which was a mistake. Some of my ideas were very similar to what Intel has implemented with their Thread Building Blocks.

Immediately after that project, I got into lock-free multithreaded memory allocation. That project has dead-ended, and I've moved onto effecient code generation for the Cell processor. (Hence my current need for a parser.)

As for languages, I spent the last two years doing lock-free memory allocation. I lived in C and assembly code land. I didn't want abstractions; I didn't want to hide the fact that I was dealing with raw memory and bytes. But now that I'm no longer doing that, I can choose whatever implementation language I want. C++ is my language of choice. It's the only language that allows for high level abstractions and systems programming at the same time.

But even if I didn't have to do any real systems stuff, I'd still want to use C++ because I think templates allow for a level of power that generics in Java and C# haven't been able to match. Templates are not just glorified macros; it is actually a Turing complete system, and people have created powerful libraries with it. Take templates away from C++, and you're just left with C with Classes (which is what the original implementation was called). It's templates, the STL and boost that allow me to write high level code.

Nev, why don't game development environments allow C++ templates? Do the compilers just not implement it? The amazing thing with templates is that if you use them correctly, the resulting code can actually be more efficient due to having much more information available at compile time.

Templates as a concept are fine. C++ as a language though, sucks. Also, game-wise, I believe there are/were issues involving various compiler implementations, increased compile times, decreased execution speed, and difficulty in debugging that made a lot of programmers shy away from them (though I believe some people use them). Additionally some of the dynamic behavior provided by templates can be better implemented in real scripting languages (Lua, python, etc) which are very common in gaming engines these days.

Something that might be of interest are these slides from a talkby Tim Sweeney (head tech guy behind Unreal games) .