Strongly typed enum in Visual C++?

Not yet. Victor Bazarov confirmed in reply to my post that there is no official announcement nor rumours that Microsoft is going to include native implementation of scoped and strongly typed enumerations defined in C++0x in upcoming Visual C++ 10.0. That’s a pity!

Thankfully, Boost provides portable emulation of scoped enums. It is compatible with compilers that already support this feature like GCC 4.4.0 (thought it’s still buggy). Nothing is perfect :-)

Compilation of VirtualBox add-ins for Ubuntu 9.10

I’ve been using the upcoming Ubuntu 9.10 installed as a guest system on VirtualBox for a while without any big problems. After one of big updates I found that currently under development 2.6.31 kernel version was installed. So, I decided to rebuild VirtualBox Guest Additions and it failed. Digging the logs helped me to find out what was the problem:

/home/mloskot/tmp/vbox/linux/module/vboxvfs/utils.c:423: error: implicit declaration of function utf8_mbtowc

Should be simple to fix. However, it seems that signatures of nls.h functions in the kernel have changed or have been moved to new place which I have no idea about. I’m not a kernel developer but I like to dig codes. Thus, I unpacked the VirtualBox installer, found the victim – utils.c and applied a very ugly fix:

extern int utf8_mbtowc(wchar_t*, const __u8*, int);
extern int utf8_wctomb(__u8*, wchar_t, int);

At least, it allowed me to compile and install the VirtualBox additions. I haven’t notice any run-time issues. I have reported this problem back to the VirtualBox as its code may need to be updated: #4823 (Missing declaration of utf8_mbtowc function in utils.c). So far, so good.

Portability poem

Meaning of PortabilityNumber of OSGeo stack software written by C/C++ camp have to run on Microsoft Windows systems. I think I wouldn’t be dead wrong if said that most of hackers from OSGeo Community work on Unix systems (Linux, Mac OS X) but there is large number of users who work on Windows.

Conclusion? Portability. Google is bursting at the seams of the essays about how to write portable code in C or C++ language. I’d add a little poem to the collection.

Principles of Portability

  • Obey the standards, because they are not just dumb rules.
  • Make a list of compilers that must be supported. Learn about their differences.
  • If possible, use GCC 4+ and Visual C++ 7.1+.
  • Using old compilers? If possible, use C89 but avoid C99.
  • Prefer GCC 4.3 and Visual C++ 8.0+, so you get C++0x support. C++0x “brings C++ more in line with the C99″ – Wikipedia, so portability is much easier.
  • Write code in C or in C++, but do not write both at the same time.
  • Avoid (direct) use of C POSIX Library.
  • Never ever disable any warnings compiler throw. Fix them.
  • Be pedantic. Compile in highest strict mode possible.
  • If possible, do not use compiler-specific features.
  • Do not make platform/architecture specific assumptions about memory addressing, memory layout, etc.
  • First understand why, then cast the hack.
  • Personal preferences are evil. Make decisions based on reasoning.
  • (Re)Use good code that already exist. Boost C++ Libraries won’t bite you!
  • KIMS (Keep it modular, stupid) and let modules to loose coupling but keep cohesion in architecture, design as well as in development cycle (releases, inter-modular dependencies).

ATL Security Update

Those of you who use Visual Studio in daily work have probably noticed there is has been new security update issued for Active Template Library. The Channel 9 also published very interesting webcast in which three engineers from Microsoft explain what’s inside the update for ATL.

Developers who have built controls using vulnerable versions of ATL should take immediate action to review and identify any vulnerabilities, modify and recompile their affected controls and components using the updated versions of ATL and finally distribute a non-vulnerable version of the controls and components to their customers.

Along with security fixes, the update includes one more interesting feature. Damien Watkins announced (12 min 20 sec) that now:

you can include ATL as a kind of header only implementation

I suppose, it may make it easier to port ATL features to development environments produced by parties like MinGW, so users of these will likely be able to use Windows Template Library (WTL) based on ATL. I’m dreaming, am I?

Inside the Active Template Library (ATL) Security Update | Jul 28th @ 10:02 AM

Hi COM! How’s it going?

In June 2000 at PDC in Orlando Microsoft announced .NET Framework project. Shortly after that developers concentrated around products and technologies made by Microsoft started debate on what’s the future of software development. One of questions and quite obvious was: So does this mean that COM is dead?. A few months later, Don Box addressed that concern in his extensive article Is COM Dead?:

It depends on what your definition of COM is. COM is many things to many people. To me, COM is a programming model based on integrating components based on type. Period. This was COM’s primary contribution to the field of component software, and that contribution has changed the way millions of programmers build systems today.

Don is right and the answer is historically and technically correct, however this is an indirect answer that didn’t cheer up at all. Given the closing words in that article:

(…) CLR provides significant benefits to developers who are using COM today. Virtually all aspects of the COM programming model have survived (…) I look at the CLR as breathing new life into the programming model that I’ve spent the last seven years of my life working with, and I know there are other programmers out there who share this sentiment.

overall conclusion becomes more an abstruse philosophy than binary answer. What about all these cryptic terms of Component Object Model technology made by Microsoft, like OLE, ActiveX, DCOM and other? Silent.

Nearly ten years later, developers are still asking the same question (a few days ago, similar discussion took place on ACCU mailing list) about COM. Alf. P. Steinbach gave an interesting answer that, however, sounds very similar to the one given by Don Box:

COM is one of the few successful C++ component technologies, if not the only one (depending on one’s definition of “successful (…) Some reduced and slightly modified versions of COM are used in e.g. Linux user interface and in Firefox browser (XCOM). Original COM itself is however a Windows-specific technology. But while it’s necessarily used to interface to the operating system and at higher levels in e.g. scripting, it’s my impression that it’s now now not much used as a general C++ component technology, i.e., that use of COM is something forced, not something desired and freely chosen.

Even though both are similar, it’s been decade since the question was asked for the first time and now we have 10 years of experience based on observations what has changed after .NET was thrown on the marked. The managed baby seems to be winning the market of Microsoft-oriented (not only, though) developers and users. COM is widely used as components of Windows systems and other already existing software but are new COM servers and objects still being developed? Or, has it started to suffer of COM programmer species extinction?

The www.microsoft.com/COM/ website confirms that:

Microsoft recommends that developers use the .NET Framework rather than COM for new development.

In my humble opinion, Mr. COM is like an old veteran, alive, but most of his comrades-in-arms have died, so he usually goes to pub alone.

Detecting Visual C++ version in NMAKE makefile

Traditionally when building GDAL/OGR, GEOS or libLAS using NMAKE users specify version of Visual C++ compiler being used as value of MSVC_VER macro. This macros is not required but it’s recommended, so NMAKE can compose best possible set of compilation and linking flags for particular version of Visual C++. For instance, command specifying Visual C++ 8.0 (Visual Studio 2005) looks like this:

nmake -f makefile.vc MSVC_VER=1400

Recently, I hacked libLAS makefiles (and GEOS makefiles too), so Visual C++ version can be determined (semi-)automatically. NMAKE 1.62 or higher reports its version as value of _NMAKE_VER macro. The solution is to defined compiler version based on version of NMAKE tool:

Update 2009-04-03: Added _NMAKE_VER number 9.00.21022.08

!IF "$(_NMAKE_VER)" == ""
MSVC_VER = 4.0
!ERROR *** Prehistoric version of Visual C++
!ELSEIF "$(_NMAKE_VER)" == "162"
MSVC_VER = 5.0
!ERROR *** Prehistoric version of Visual C++
!ELSEIF "$(_NMAKE_VER)" == "6.00.8168.0"
MSVC_VER = 6.0
MSC_VER = 1200
!ERROR *** Prehistoric version of Visual C++
!ELSEIF "$(_NMAKE_VER)" == "7.00.9466"
MSVC_VER = 7.0
MSC_VER = 1300
!ELSEIF "$(_NMAKE_VER)" == "7.10.3077"
MSVC_VER = 7.1
MSC_VER = 1310
!ELSEIF "$(_NMAKE_VER)" == "8.00.50727.42"
MSVC_VER = 8.0
MSC_VER = 1400
!ELSEIF "$(_NMAKE_VER)" == "8.00.50727.762"
MSVC_VER = 8.0
MSC_VER = 1400
!ELSEIF "$(_NMAKE_VER)" == "9.00.21022.08"
MSVC_VER = 9.0
MSC_VER = 1500
!ELSEIF "$(_NMAKE_VER)" == "9.00.30729.01"
MSVC_VER = 9.0
MSC_VER = 1500
!ELSE
MSVC_VER = 0.0
MSC_VER = 0
!ENDIF

Later macros MSVC_VER and MSC_VER can be used to report Visual C++ version:

!IF "$(MSVC_VER)" == "0.0" && "$(MSC_VER)" == "0"
!MESSAGE *** Cannot determined Visual C++ version
!ERROR *** Aborting make job
!ELSE
!MESSAGE *** Using Microsoft NMAKE version $(_NMAKE_VER)
!MESSAGE *** Using Microsoft Visual C++ version $(MSVC_VER)
!MESSAGE *** Using Microsoft C/C++ version $(MSC_VER)
!ENDIF

This is not a rocket science, but it seems to work well and it frees users from manual specification of Visual C++ version. I’m not sure how the NMAKE version numbers vary across Visual Studio versions and builds. It would be good collect these version numbers to make the solution reliable. So, I’d be thankful if readers using Visual Studio 2002, 2003, 2005 and 2008 or newer :-) could report their NMAKE versions directly to me or post them as comments below.

Building PostGIS using Visual C++

I don’t like MinGW. I’ve been dreaming about building PostGIS using Visual C++ – the native development toolset for Windows platform – without being forced to install Unix-like environment inside Windows. Finally, I’ve got motivated enough and decided to make my dreams reality, so here is the story.

First, I collected all run-time dependencies required by PostGIS. I intentionally used the word run-time to indicate I’m not going to install MinGW neither Cygwin or any other GCC-for-Windows package. GNU make is also not required.

I use PostGIS source code from trunk in the Subversion repository.

Dependencies

There are only 3 software packages required:

  1. PostgreSQL 8.3.6official Win32 binaries and source code
  2. GEOS – build from sources, it’s safe to grab SVN trunk
  3. PROJ.4 – also build from sources and also from SVN trunk

I installed the PostgreSQL 8.3.6 without PostGIS extensions, as I’m going to provide my own :-), using default location c:\Program Files\PostgreSQL\8.3. The source code of PostgreSQL 8.3.6 went to d:\dev\postgresql\postgresql-8.3.6.

Short note on directories layout using for projects downloaded directly from repositories. Root path of source tree of each project have the same layout: D:\dev\PROJECT\_svn\trunk. For Visual Studio projects, these paths are defined as macros in postgis.vsprops (Visual C++ Property Sheet), so it should be easy to redefine them without any need to hack other project settings like Additional Include Directories and others.

Continue reading