Skip to main content

Project: Boost-free Goblins, part 3

Ready, Aim, and Fire

After the battle-cry, and then calming down to make some preparation, I decided to take the shot. The target: boost::shared_ptr.

To Action

A quick search turns up that shared_ptr is supported in the STL's memory library since c++11. Well, that seems like an easy task. Let's take our script for a spin. 
tools/boostrm.sh shared_ptr memory
Now I have a bunch of std::shared_ptr replacing the boost variant. Seems like everything is in good order. After pushing it into the github to have Travis CI do the honors of compiling it, turns out, some boost::weak_ptr, apparently derived from boost::shared_ptr, was being casted into boost::shared_ptr, and they are not compatible with std::shared_ptr since that's not what they inherited. Well, after a bit of research, it seems the weak_ptr has a STL version. It seems like weak_ptr needs to go, too. 
tools/boostrm.sh weak_ptr memory
After another push into github, and another build run by Travis CI, it turns out that it conflicts with boost's serialize. This time, there's no easy replacement of it in STL. Full stop.

Catch 22

After staring at the boost code for it, I found that the old boost version being used is really the culprit: the old methods relies on calling the member function to serialize the object. The newer versions use helper functions and supports the STL variants. But earlier experiences taught us that using newer versions crashes the program. So my first bout with the boost ended in a bit of a loop: I was able to replace the objects, but in process lost some of the deprecated functionalities. They will not be a problem in the updated boost, except latest boost had caused us unknown errors. So now, we stand in an impasse: until we can progress far enough in development (i.e. remove more or all of boost), it may be too difficult to try updating the boost. To remove boost and test if it works well, we need to update to the later versions.

Lesson Learned

For now, Boost and I are at stand-off, slightly anti-climatic finish to my first attempt that wanted to take out just one object but ended up touching up on 3 different objects. If this is of any indication of the future, this war is going to be a long one. Still, I am interested in continuing the efforts: currently, another developer is working hard to get a Windows build to work, and one of the biggest stumbling block seems to be the Boost. Getting rid of it will simplify some of his headaches and make it possible to run the program in Windows quicker.
Labels:

Comments

Post a Comment

Popular posts from this blog

Creating a patch for GNU GCC using Git

Overview and Target Audience The GNU GCC project followed a blend of a traditional method with contemporary git tools when it comes to contributing code, making the experience unique from some other, git-based projects. This blog post will explore different aspects of the process, helpful commands, and various scripts that would make the experience more pleasent for new contributors. While this blog aims to help new contributors get acustomed to the GNU GCC code culture and make contributing easier, it must be stressed that this is not in any way in-depth exploration of the process. This should help you put your first foot forward; the community will help you take the rest of the steps from that point on. This post also assumes the user is in a POSIX environment (e.g. Linux, FreeBSD). Git and GNU As stated in this phoronix post , GNU GCC made a full transition to git early 2020. As of this writing, the community seems to be adjusting to the new tools. GNU GCC hosts its own git serve...
Post a Comment
Read more

Debugging with GCC: GIMPLE

GCC and GIMPLE One of the very first thing GCC asks the GSoC applicants to do, even before writing the application, is to try various different debugging techniques using GCC. I was personally familiar with the basic, compile-with-g-flag-and-use-gdb method. Turns out, there's more: GIMPLE. A Simple but Non-trivial Program Problem Description The instruction asks to compile a simple but non-trivial program with some flags that generates debugging information: -O3 -S -fdump-tree-all -fdump-ipa-all -fdump-rtl-all . Because I was keep reading on ways to debug GCC just prior to the statement, I immediately thought "GCC" and tried make -j8 CXXFLAGS="-O3 -S -fdump-tree-all -fdump-ipa-all -fdump-rtl-all" . This was a mistake: turns out, GCC can't be compiled with those flags. Thankfully, GCC developers have a very active IRC channel for me to signal SOS. Resolution jakub and segher were quick to respond to my call for help. jakub: it isn't meant that y...
1 comment
Read more

Intel Parallel Studio 2019 meet Cygwin

Introduction Intel Parallel Studio provides pre-configured bat to run command line interface using Windows CMD.  The command is called 'icl'. To some, this is satisfactory.  To me, I need a better shell. Cygwin satisfies my need for a UNIX shell.  This post is about setting up a Windows system to successfully compile a simple code using Cygwin and icl, Intel C++. Largely, I had two issues: one minor, quality-of-life issue, the other critical. Quality-of-Life issue The minor issue is that I wanted to simply double-click on the icon to open up a console with appropriate environment.  The provided bat file does that, but for CMD.  I wanted to gear that toward Cygwin bash environment.  The obvious way is to open up the CMD through the bat, and then execute Cygwin.bat from the Cygwin installation folder. To have one-click icon to open up a prepared Cygwin bash console, we must provide appropriate arguments to the shortcut. Method Locate the Intel...
Post a Comment
Read more