Category Archives: C++

More Fun with PInvoke

I’m getting more comfortable with PInvoke from C#. I’ve been using a web site that contains a pretty wide variety of recipes for getting at Win32 API calls with PInvoke.

At some point soon I need to take a look at the WindowsAPICodePack-Core which appears to have pre-built versions of some of these things. For now I’m happy that I’m getting closer to the point where I know how to invoke most API calls directly using PInvoke.

I do wish there was a more comprehensive reference document discussing all of the capabilities and ins and outs of using this facility. As is there are examples and specific documentation for some items (I’ve been using my copy of .NET 2.0 Interoperability Recipes: A Problem-Solution Approach to work out the basics and the PInvoke web site to extend that to more complicated examples.

I’ve put some of the sample code I’ve been playing with on GitHub at DupScan. This project is again code aimed at deduplicating file trees for archiving and management. The big driver here is the unique file ID API.

OPenCV Build on Ubuntu Worked

This time I pasted all of the pieces into a single shell script (instead of running it piecemeal) and things went smoothly. Still took a while, even on the Core-i5 system with an SSD and 32 GB of physical memory. I specifically pulled 4.0.1 from git rather than the default choice from the source of the instructions that built ‘master’.

Tonight I’ll have to write a bit of code to use the library and see if I can get streams of images programmatically from one or more of the webcams I’m working with.

At some point I may bump up the swap space on another of my RPi systems to see if the same script works there as well.

Working towards an OpenCV build on Ubuntu

Well…almost got OpenCV building on my main Ubuntu machine at home. I was copying fragments from the directions on the OpenCV site into an SSH session and clearly missed something along the way. I’ll have to build a single, large shell script up front next time and then run that. Unfortunately it seems as if (I may learn better later on) once CMake has done its magic, lots of things get baked into the files that drive the build in ways that really, really want a rebuild if things don’t go quite right.

I was working from the instructions here. (Other instructions here).

I was surprised to see that the github repo and contrib did not have a branch tag for release 4. It looks as if there’s a stable release out there, but 3.4 and master seemed like the available choices.

The main site clearly indicates that version 4 has been released with pre-built windows and ios downloads and documentation. I’m not sure currently how to pull that stable release code from git though.

I expect to take another run at the 4.0 build on Ubuntu tonight. Other than script grabbing issues, the build went smoothly…32 GB of memory and a Core-i5 CPU work better than an low-end ARM and 1 GB swapping on a micro-SD card.

Hmm…more github presence for version 4 here and here. Looks like OpenCV 4.0.1 is the latest. Ah…tags not branches here…need to look at pulling the appropriate tag for the build. Easy enough…just list the tags, find the 4.0.1 tag and check that out.

Bouncing Around a Bit Today

Building C++ supporting libraries on my small dev machine. Looking at another pass of C++/CLI work and some more thinking about motion capture options.

I’ve built zlib and bzlib2 yesterday. To get these building with VS 2017 I built them with their standard build procedures (which appeared to build 32 bit libraries) and then created visual studio 2017 projects to build the same pieces using fresh settings.

I’ve got boost, openssl, opencv and the mongodb c and c++ libraries on my list for today. The mongodb libraries are my primary target here though all of the above are of interest. This is also what is driving my CMake reading as several of these libraries use CMake for their builds.

I’m pretty interested in C++/CLI as a way to get access to C and C++ functionality from C#. Given the productivity that C# provides, access to C and C++ APIs and libraries from that environment would help quite a bit. My primary driver was access to the Win32 file ID API for some file management work, but Win32 APIs keep coming up now and again. I do need to take a look as some newer C# libraries that Malcolm suggested that may provide pre-packaged access here.

In the past, I’ve run into build issues when combining C# and C++/CLI in the same project. I expect this was setup issues so I’m now looking to take a more serious look at this.

The motion capture work will start out with OpenCV and getting my web cams running with code behind them to process the images. I’m thinking that pre-recording things and then post processing might be a good idea…using a light strobe to synchronize things could simplify time sync as well. Much to consider…

Next Steps

I’ve got boost, zlib and libbz2 built on boojum now. Next step will be to test the installs with a small program or two. Hoping that all went well and I have usable, native, win64 libraries available.

Once those have been checked out I’ll take another run at building the MongoDB drivers…this time on boojum rather than chaos. Boojum has a shorter history and is distinctly less cluttered than chaos so I’m hoping that this just works. Expecting less than that though…I’ll probably need to dig deeper into he CMake configs to get where I want to go. I’ll update as I move forward…now off to lunch though.

Looking at 3D location of Objects with Multiple Cameras

We tried doing some motion capture with a kinect 2 today. Results were mixed though less than ideal.

I am thinking of using OpenCV to acquire images and use them to register locations in three-space. I currently have two high quality cameras and a lower quality one to play with…I expect that if things go well I’ll likely pick up a third higher quality camera to work with along with some hard-mounts for them in the basement. Ideally I’d love to be able to code up some decent motion capture functionality using cameras and reference marks on limbs.

A bit of experimentation will be required in order to get there though.

I am wondering whether a faster, lower resolution webcam might do better for this. There are some $20.00 a piece cameras with USB-2 interface out there (Microsoft Lifecam-3000 or Logitech C270) instead of the higher-end, USB-3 autofocus Logitech C930e. Both wondering whether the lower resolution and USB-2 may provide a higher frame rate and whether fixed focus will stay consistent without periodic refocus hits.

Need to Learn More About CMake

I’ve been looking at using MongoDB from C++ and trying to build the MongoDB C and C++ driver code. So far, the build files that CMake has generated on my main development box (targeting Visual Studio 2017) have pulled in cygwin header files and generated various other problems. I don’t really understand why the tool would be getting confused like this, but I want a better understanding of how CMake decides where to look for build files and configuration and how to control that.

I’m sure that having cygwin and visual studio on the same machine should be a workable configuration so I expect there are ways to keep CMake from pulling in the wrong files.

Hoping to get to the point where I can cleanly build these drivers and get them working in some 64 bit visual C++ code.

Giving up on MongoDB from C++ for now

I’ve tried building this thing using CMake and Visual Studio and CMake seems to keep picking up cygwin headers for Visual Studio builds and I can’t seem to make things better. For now not worth the pain. I’m probably going back to C# with C++/CLI to get this working with C APIs and C# for MongoDB access.

I’m certain that I could get this building with enough effort. The code looks reasonable and I can put together the projects myself. I’m not all that inclined to go there though as I’d have to re-do this every time through. I’m not familiar enough with CMake to try modifying that part of the process.

Ok…not quite giving up. I did find that CMake appears to be adding a cygwin header folder to the projects. If I manually remove this from them the build goes further. The default build configuration appears to be 32 bit which is also an issue for me. Perhaps I’ll do a little more before I completely give up.

C++ MongoDB Driver Circles within Circles…

Looking at getting a bit of C++ file processing code done for some home sandbox tooling reasons. Grabbed the source code.

Source code asks for boost as a polyfill for C++ 2017 (optional and something else) with MSVC 2017. Grabbed boost. Got to build boost, really would like to build the full kit if I’m going to build it at all. Grabber zlib and libbz2. Now looking at any other dependencies needed to build a reasonably complete boost build locally.

Heading off to see the Captain Marvel movie and will continue with this (along with some presentation prep I need to do this weekend and some overflow work items I need to look into). Should be an interesting if busy weekend…

This is once again reminding me why C# and Java are so much more productive than C++ for many things. In C# I’d nuget the mongodb drivers. Up to date versions of any supporting libraries would be pulled in as needed and I’d be writing code in short order. I love C++ for its power and flexibility, but as a tool to get higher level logic in place it is not holding up well…

Add in building bjam to build boost with and then grabbing CMake to build the mongodb drivers with…making sure that the build processes find the right compiler (I’ve had at least one run where my build grabbed the g++ compiler out of the path even though the visual studio tools were there as well.

More adventures with C++/CLI

I’ve been working with C++/CLI to get access to native API functionality from C# some more lately. I’ve been running into cases where something compiles flawlessly when I create the project but then fails miserably when pulled from GIT clean and rebuilt. I’m looking at various build issues that might be contributing to this and will hopefully find the right recipe soon.

Some notes here related to parts that matter and APIs that I’m looking to use…half of this for my own reference as I mess with solutions to see what works:

Marshaling strings the (relatively) easy way:

 #include <msclr/marshal.h>

System::String^ myPath = "ABC";
std::wstring path = msclr::interop::marshal_as(myPath);

File information:

typedef struct _FILE_ID_INFO {
ULONGLONG VolumeSerialNumber;
FILE_ID_128 FileId;
} FILE_ID_INFO, *PFILE_ID_INFO;

FILE_ID_INFO info;

BOOL ok = GetFileInformationByHandleEx(myHandle, FileIdInfo, &info, sizeof(info));

Alternate string marshaling:

inline void MarshalString(String ^ s, std::wstring& os) {
using namespace Runtime::InteropServices;
const wchar_t* chars =
(const wchar_t)Marshal::StringToHGlobalUni(s)).ToPointer();
os = chars;
Marshal::FreeHGlobal(IntPtr((void)chars));
}

Volume information:

BOOL ok = GetVolumeInformationW(path.c_str(),
volumeNameBuffer, MAX_PATH + 1,
&serial,
&pathLength,
&flags,
filesSystemName, MAX_PATH + 1);

File attributes (can be used on c:\ to find things like volume creation time stamp)

WIN32_FILE_ATTRIBUTE_DATA info;     
BOOL ok(GetFileAttributesExW(path.c_str(),
  GetFileExInfoStandard,
static_cast<void *>(&info)));

creationDate = gcnew System::DateTime((long long)(info.ftCreationTime.dwLowDateTime) | ((long long)(info.ftCreationTime.dwHighDateTime) << 32));

Additional volume information:

    wchar_t volumeName[1024];     wchar_t fsName[1024];     DWORD vsn;     DWORD fsflags;     BOOL ok(GetVolumeInformationW(path.c_str(),         volumeName, 1024,         &vsn,         nullptr,         &fsflags,         fsName, 1024));

and

    ULARGE_INTEGER free;     ULARGE_INTEGER total;     ULARGE_INTEGER totalfree;     BOOL ok(GetDiskFreeSpaceExW(path.c_str(), &free, &total, &totalfree));

and basic info

FILE_BASIC_INFO info;
BOOL ok(GetFileInformationByHandleEx(handle, FileBasicInfo, static_cast(&info), sizeof(info)));

JSON over Stdin/Stdout for small local components.

I’m looking at adding a local control capability to my little C++ based file and volume identifier tool. I’ve run into a number of small functions that would be well served by tools written in specific languages that have access to specialized APIs but would benefit from a local interface with somewhat decent performance.

Unix style text in/text out is limiting as the command/response format lacks structure and the performance (with one process start per request) is potentially unacceptable.

Adding in a command line switch that sets the tool into ‘json in/json out’ mode and keeps the program alive until the pipes drop or an exit command is received should address these issues.

Ideally, the stdin and stdout would transport UTF-8 data containing complete JSON entities…one as a request and one containing the complete response. This can continue until the hosting program sends an EOF or drops the pipes.

I’m wrapping together a very lightweight JSON generator/parser to support this effort and will be following that up with some testing of C++/Java/C# (and perhaps others) sub-process and pipe management coding. If all goes well, I should have a nice little approach for wrapping small pieces of code that need to run in a particular language but must be hosted elsewhere with decent performance and a robust communications format.