#c-plus-plus

A checklist for the frustrated beginner Redis is a technology I'm only just beginning to use. If you don't know what it does, I question A) why you're reading this and by extension B) what you're doing with your life by even reading this blog. Seriously, get off the internet and go outside. If these questions have sent you spiralling into some sort of existential maelstrom, know that Redis provides an in-memory database which is very fast and very useful for inter-process communication. The possibilities are almost endless, and I am quite excited to start exploring them. Hiredis ( https://github.com/redis/hiredis ) is a reasonably stable C++ client written to access such a database. The developers have provided a Visual Studio solution which can be built with very little issue. However, as is the way with such things, linking it to another project can cause some headaches. I encountered several headaches when linking the project, but made a breakthrough right after being pleasantly distracted - so if all else fails, distract yourself for a while. It helps. I hope that going through the following checklist will alleviate this pain:  

Firstly, coordinate your Platform Toolset. I am using v120_xp across all the projects, because it will run on our industrial hardware which runs XP. Make sure you change this for Win32_Interop, hiredis, and your project.

  For your project, the hiredis project, and the Win32_Interop project, check that Properties->C/C++->Code Generation->Runtime Library is set to the same across all. I tested with /MTd and /MDd, both were fine as long as they matched between the calling project, the hiredis project, and the Win32_Interop project which hiredis uses for it's wrapped Winsock functions. This will resolve many linking errors that you might be seeing.

  Ensure that hiredis is linked to Win32_Interop.lib - you can do this in Properties->Librarian->General->Additional Dependencies. Add the full path of your Win32_Interop.lib file. Mine was c:\dev\redis-2.8\msvs\Debug\Win32_Interop.lib, so be sure to link it properly otherwise you'll get a few linking errors from networking funtions such as socket, bind, fcntl, etc. I did not try linking with a pragma comment, so if you prefer the readability of this then try it out for yourself.

  For your project, make sure you are using Multi-Byte Character Set - hiredis and Win32_Interop use these by default. If you're combining with MFC, you'll notice that MBCS was deprecated in VS2013. Check the link in the article here ( http://blogs.msdn.com/b/vcblog/archive/2013/07/08/mfc-support-for-mbcs-deprecated-in-visual-studio-2013.aspx ) which gives you a download for these.

  In your project's Properties->C/C++->General->Additional Include Directories, add a path to the redis src directory amd the deps/hiredis directory. Mine were, respectively, c:\dev\redis-2.8\src and c:\dev\redis-2.8\deps\hiredis

  In your main.cpp file, include "hiredis.h" before anything else. Windows has a funny habit of being quite fussy about the order of includes, so this is just something we all have to live with.

  Link with hiredis.lib - you can do this as a #pragma comment(lib, "c:\your_redis_msvs_output_path\hiredis.lib") or in the linker, whichever you prefer.

  This should solve the majority of confusing build errors. To properly test, run a default redis-server (the path to which may be something like c:\dev\redis-2.8\msvs\Debug\redis-server) and write a test program. This need not be anything more than creating a pointer to a redisContext and initialising it with the function redisConnect("127.0.0.1", 6379) and then pinging the server with     redisReply *myRedisReply = (redisReply*)redisCommand(myRedisContext, "PING"); You can get the result of the ping (which should be "PONG") by looking in the str member of the redisReply object. That's it! If there are any other beginner errors that would be useful to list, contact me and I'll add them.

Edit: Some additional steps for building hiredis into a project:

 You may need to add external files into the project from the src folder. Use extern "C" { ... } to wrap the #include-d redis headers, otherwise you'll get more unresolved external symbols. Then just add the existing files into your project. Make sure you #include files from the redis-2.8\deps\hiredis folder, and add files from the redis-2.8\src folder.

Predictable complications and omniscient lists After dealing with some high-priority projects over the last month or so, I'm back to getting Daedelus off the ground (hue). Filling out the opcode behaviour uncovered a new requirement - branching. Yes, conditional and control statements like if, while, etc. I knew it was going to require a C-like approach, but I vainly thought through other alternatives anyway. Of course, none really provided the intuitive aspect that the problem begged. It really seemed there was only one thing to do - and that was getting right on with it. My first attempt was to treat conditions the same way as I'd treated arguments - parse them recursively and store the blocks of code that were nested within. However, as this language construct is more abstract than opcodes, such a naive approach turned out in brainstorming to be very inappropriate. Pondering, I drew a picture of a script as a set of circles and lines, and was immediately reminded of a set of points as in a graph. My games programming past instantly shouted "Vectors! Easy!" And I was quite happy with this and even started programming it. This approach could have been made to work, but during the process was actually providing some unnecessary complexity - not only would I have to match vectors into pairs, I'd then need to go back into the script and start thinking about a way to execute or ignore code based on x/y coordinates... Starting to seem like overkill. The final solution to the branching question was the OmniList. There's probably another name for this, I don't know what it is though. Bi-axial doubly-linked list is a bit cumbersome. Quad-linked list?              *parent *brother |node|    *sister              *child                   It seemed like a pretty cool data structure so I put it into it's own class and templated it to be used later. The implementation for a Branch is like this: class Branch : public OmniList<Branch> The main drawback I can't seem to get around just yet is that list creation must proceed in only one direction vertically, and only one direction horizontally. My order is child -> sister, but I'm sure there's a way to get at least horizontal creation to go in both directions, even if it doesn't make much sense to do so. Given that it would be an unused functionality, I've stuck with child->sister for now. The parent and brother nodes are linked back on creation.

A simple guide by a simple man

A spike project I have worked on lately has to do with the way we communicate between proprietary field equipment and a centralised observation program. The architecture of the observer is in the process of being completely rebuilt with modern software design principles, and our field equipment has to be dragged out of the festering, corpse-strewn mire it currently inhabits and updated to use the message queue capabilities of the new design. The chosen message queue program, as you have guessed, is Apache's ActiveMQ. As the field equipment runs embedded XP, .net interfaces are out of the question and the implementation has to be done in C++. Why this entry? Because it was problematic to set up, and the fix was not entirely obvious (at least not to me). By chance it was that I happened upon the answers, and so I'll share them here for anyone who needs to do something similar. Why this entry, here in solitude? Now that's a better question. Needed to get basic messaging running: APR (http://apr.apache.org/) - http://mirror.mel.bkb.net.au/pub/apache//apr/apr-1.5.0-win32-src.zip ActiveMQ(http://activemq.apache.org/) - http://www.apache.org/dyn/closer.cgi?path=/activemq/apache-activemq/5.10.0/apache-activemq-5.10.0-bin.zip ActiveMQ-cpp (http://activemq.apache.org/cms/) - http://www.apache.org/dyn/closer.cgi/activemq/activemq-cpp/source/activemq-cpp-library-3.8.2-src.zip If you're anything like me, just getting the basics to build is the most important step and you're pretty confident of success after that. Of course, all I need to do in this project is push a message onto the queue from the field equipment, and read any relevant ones coming in. So all I want to do in terms of ActiveMQ is just get the activemq-cpp and activemq-cpp-example projects running for now. This isn't a guide on how to get messages going back and forth on a queue or how to set up ActiveMQ for Windows - that's a guide that may or may not come later.

Building APR So you've downloaded APR and want to build it. "The apr project builds! So does libap- oh..." You have just encountered a fairly intricate frustration, so hold up a second. As you've noticed, the folder structure is a bit fiddly, but once you've got apr.dsw converted and opened in VS2013, you need to go to the property pages for each of the following:  - apr  - libapr and change the Platform Toolset to Visual Studio 2010 (v100). Why? Well thanks to this obscure post - http://osdir.com/ml/dev-apr-apache/2013-11/msg00019.html - we see that some function casts used in the source code are 32-bit only. "Why do I, the library user, need to work around this?" Because that's how life works.

Build aprapp. It takes a while. In the meantime you can look at the C source code, or for a more pleasant experience, douse yourself in acid. Once that's done, go to the APR root folder and get the libapr-1 dll and lib files from either Debug or Release (I personally just built them in release mode). In your ActiveMQ-cpp directory, you should find a supplied vs2008-build folder. Make a subfolder in this for APR, with include and lib subfolders, and copy over the dll/lib files and the include folder from APR.

Building ActiveMQ-cpp Open activemq-cpp.sln, then the properties page for activemq-cpp, and in the Configuration\C++\General\Additional Include Directories, add your APR include path. Also, change the platform toolset to VS2010. You will need to repeat that for the project activemq-cpp-example, but will also need to add libapr-1.lib into Configuration\Linker\Input\Additional Dependencies "Oh cool, it builds now. Let's run it!" You wouldn't want to forget such an integral step as linking the dll would you? Just put libapr-1.dll into the folder that the exe is output to.

In conclusion... Now you can run it. The official readme wants you to grab 2 or 3 more libraries, but they aren't used at all in the build process so don't trouble yourself. This whole process highlights some of the pitfalls of modern software development, not just for library users but also developers. It's so damn big. Not just in raw code, but in the techno-geography of where it could end up being built and run. Look at main.cpp in activemq-cpp-example. Look at all those include files. Is that a difference in design or scale? The minds behind these libraries have to account for so many implementation quirks and they still offer this product for free!

Perhaps it's naivety on my part, but when I start writing code that can be put into a library or even just a handy class, the very first thing that I think about is using it from the "other end". But then, I don't work for one of these software-to-software solution companies, whose products are marketed toward other programmers, so there could be whole face to this issue that I can't see. I really hope I never have to work for one of these companies anyway, it's not my thing. It's not quite as physically applicable as I'd enjoy.

Obligatory gloating and selecting operation by argument count

As it turns out, forcing brackets was a great idea. The initial tutorial architecture was woefully inadequate, and not a great idea. I think it was meant to be party to both C and C++, which explains some of the design choices. Either way, a little bit had to be refactored with the introduction of the argument stack - curmudgeonly pointer interfaces were the most prominent.

One thing that hit me on the drive home yesterday, and a suspicion which was confirmed today, is that the recursive parser needs a queue rather than a stack. ctrl+f saved the day, thankfully the STL is fairly homogenous and I only had to replace calls to top() with front().

I ran the first operation with a right-most nesting, and after a minor correction with a string index it ran happily. I then tried an operation with a nested first argument, which didn't work. It didn't seem it would be hard to correct though, and this too was a well-founded inquiry. All I had to do was increment that aforementioned string index by 1 after returning from the recursion.

See for yourself!

Well that's the gloating part. What now? Argument-dependent operation types, which I briefly mentioned in the first part of this series. This might be a little bit more tricky. This pertains to the TMR and REG commands - with two arguments, it is considered a write operation and does not return anything. With one argument, it is a read operation and passes it's return down the queue.

Introduction, basic design, and parsing perplexities

One of my major projects in the next month is to develop a scripting language - codenamed DAEDELUS - to run on a certain brand of industrial computer, such that they can be used as a PLC with much more functionality beyond the basic IO operations. The idea is that an engineer will create a series of scripts which will be executed cyclically at a guaranteed rate (that last bit has me a little concerned - more on that later though) that will operate the various input/output from the field.

Given the relatively simple requirements, the instruction set came out looking a lot like assembler, and as I began following this excellent, albeit basic, tutorial - http://www.gamedev.net/page/resources/_/technical/game-programming/creating-a-scripting-system-in-c-part-i-an-i-r1633 - it became more obvious that my requirements demanded a little more from the virtual machine.

Never happy to entirely discard hard work, I have begun to refactor the code to accept nested opeartions. Initially I thought of reading the line left to right, searching for keywords, placing them on a stack when found, then continuing until the last complete expression was found. In execution, simply execute down the stack and pass the result of each expression into the next execution... as per the following diagram:

As the reader has likely presumed, certain operations are of variable length that determine whether to interpret it as a read or write call. This convention will be used for registers and timers.

Before writing this post, I began to question the logic of this setup. The most glaring criticism is that it's hard to read. Obviously the text parsing will discard characters such as brackets and braces, but a way to improve readability and lower the likelihood of parsing errors (especially given variable-length operations) would be to enforce brackets around each expression as a syntactic feature.