Reload option values in boost::program_options from new source - c++

I'm just starting to dig into boost::program_options for the first time. I like it quite a bit. However, what I'm trying to accomplish with it doesn't seem to be something its designers have accounted for.
I want to use boost::program_options to parse both command line options as well as config files. So far so good. Additionally, though, I would like to be able to check for updated settings (say from a new config file) that could override the previously parsed settings in my variables_map.
Granted, I could do a separate parse and try to merge the two maps. Perhaps that's what I'll end up doing. I'm just wondering, though, if anyone has done anything like this before and has come up with a slick solution.

Related

What could be the simplest way to incorporate Windows WPP Software Tracing into SCons builds?

I ask my question in such a specific way because I am afraid that a more generic form could lead to excessively theoretic discussions of how the things should be done best and in the most appropriate way (like a question about pre and post-process actions in SCons).
WPP incorporation actually requires execution of an additional command (commands) before compilation of a file and only even if the build process finds necessity to compile the file without any regard to WPP.
I would remark that this is easily achieved with few lines of definitions in a shared Visual Studio property page file making this work for multiple files in multiple projects, folders, etc. in an absolutely transparent for developers way.
Thus I am wondering whether this can be done in a similarly simple way with SCons? I do not have any deep knowledge of either SCons or MSBuild frameworks; I work with them for simple practical use so I would truly appreciate a practical and useful advise.
Here's what I'd suggest.
SCons builds command lines from Environment() variables.
For example the compile command line for building shared object for c++ is stored in SHCXXCOM (and the variable for what is displayed to user when the command is run defaults to SHCXXCOM, but can be changed by modifying SHCXXCOMSTR).
Back to the problem at hand.
Assuming you have a limited number of build steps you want to wrap, you can do something like.
env['SHCXXCOM'] = [ 'MPP PRE COMMAND LINE', env['SHCXXCOM'], 'MPP POST COMMAND LINE']
You'll have to figure out which variables you need to do this with, but take a look at the manpage to figure that out.
https://scons.org/doc/production/HTML/scons-man.html
p.s. I've not tried this, but in theory it should work. Let us know if not.

Autoclose xml tags in C/C++ file in vim

I have some documentation strings embedded within the source code (C/C++ files) as XML tags and I'd like to know what's the most minimal solution to make vim autoclose the tags (closest matching tag).
I've found closetag.vim but is there away to do this neatly without modifying anything but the .vimrc file?
Vim has no built-in support for that, so the closetag.vim plugin is the proper and easiest solution. (I use it myself, too!) Of course, you can develop your own simple mappings (that search backwards for an open tag, get that, drop the attributes, add the slash, and insert that), but:
that will either be very simplistic and therefore often wrong
or ends up with as much complexity as closetag, becoming a reimplementation of that plugin
If some rather strange restrictions (e.g. a custom primitive sync across systems) only allow you to manipulate the ~/.vimrc itself, you could just append the entire plugin's code to it (though I'd recommend against such an ugly hack).

Modifying a complex config file in C/C++

I need to be able to modify a complex config file from within my C/C++ program (whichever is going to be easier and more convenient to use in this case, probably C++). The idea is that the program computes the values that it needs to insert into the file, then writes them.
The config file itself looks like this:
^looots of stuff I won't be using^
option blah.blah.something "value"
option blah.blah.someotherthing "value"
Now, many of the options are logically connected, for instance:
option blah.blah.car.engine "value"
option blah.blah.car.color "value"
I don't really have an idea how to reach those lines that I'm interested in. Should I skip to a specific line and then search for a quotation mark and modify what's after it? That doesn't seems like a reliable and flexible solution, does it?

Loading a text file in to memory and analyze its contents

For educational purposes, I would like to build an IDE for PHP coding.
I made a form app and added OpenFileDialog ..(my c# knowledge was useful, because it was easy ... even though without intelisense!)
Loading a file and reading lines from it is basically the same in every language (even PERL).
But my goal is to write homemade intelisense. I don't need info on the richtextBox and the events it generates, endline, EOF, etc, etc.
The problem I have is, how do I handle the data? line for line?
a struct for each line of text file?
looping all the structs in a linked list? ...
while updating the richtextBox?
searching for opening and closing brackets, variables, etc, etc
I think Microsoft stores a SQL type of database in the app project folders.
But how would you keep track of the variables and simulate them in some sort of form?
I would like to know how to handle this efficiently on dynamic text.
Having never thought this through before, it sounds like an interesting challenge.
Personally, I think you'll have to implement a lexical scanner, tokenizing the entire source file into a source tree, with each token also having information about it mapping the token to a line/character inside of the source file.
From there you can see how far you want to go with it - when someone hovers over a token, it can use the context of the code around it to be more intelligent about the "intellisense" you are providing.
Hovering over something would map back to your source tree, which (as you are building it) you would load up with any information that you want to display.
Maybe it's overkill, but it sounds like a fun project.
This sounds to be related to this question:
https://softwareengineering.stackexchange.com/questions/189471/how-do-ide-s-provide-auto-completion-instant-error-checking-and-debugging
The accepted answer of that question recommends this link which I found very interesting:
http://msdn.microsoft.com/en-us/magazine/cc163781.aspx
In a nutshell, most IDEs generate the parse tree from the code and that is what they stores and manage.

c++: program settings - boost.PropertyTree or boost.program_options?

I was looking for a solution to store program settings or options or configuration in C++. These could be settings that are exposed in a GUI and need to be saved between runs of my code.
In my search I came across boost.PropertyTree which seemed to be a good choice. I know boost is well respected code so I'm comfortable using it and so I started developing using this. Then I come across boost.program_options which seems to allow you to do the same thing but also looks more specialized for the specific use-case of program settings.
Now I'm wondering which is the most appropriate for the job? (or is there a 3rd option that is better than both)
EDIT:
fyi this is for a plugin so it will not use command line options (as in, it's not even possible).
UPDATE
I ended up sticking with boost.PropertyTree. I needed to be able to save changed options back to the INI, and I didn't see a way of doing that with boost.program_options.
Use boost::program_options. It's exactly what it's for. In one library you get command line options, environment variables options and an INI-like configuration file parser. And they're all integrated together in the Right way, so when then the user specifies the same option in more than one of these sources the library knows the Right priority order to consider.
boost::property_tree on the other hand is a more generalized library. The library parses the text stream into a uniform data model. But You need to do the real parsing -- that of making sense of the blob of data for your needs. The library doesn't know when to expect a parameter when it sees a particular option string, or to disallow specific values or types of values for a particular option.
After some digging around I think boost.PropertyTree is still the best solution because it gives me the capability to save the options after changing them from within the program which is a requirement.
There is a non-Boost possibility too. Config4Cpp is a robust, simple-to-use and comprehensively documented configuration-file parser library that I wrote. It is available at www.config4star.org.
I suggest you read Chapter 3 (Preferences for a GUI Application) of the Practical Usage Guide manual to read an overview of how Config4Cpp can do what you want. Then open the Getting Started Guide manual, and skim-read Chapters 2 and 3, and Section 7.4 (you might prefer to read the PDF version of that manual). Doing that should give you sufficient details to help you decide if Config4Cpp suits your needs better or worse than Boost.
By the way, the indicated chapters and sections of documentation are short, so they shouldn't take long to read.