Tag Archives: c++

Traits of void resolved

Posted on by
Reply

It looks like I’ve got clarified status of the traits of void type. I posted my question to libstdc++ where Paolo Carlini kindly provided me what the bits I have been missing. Now, all the puzzles are in place:

[n1836], the specifications for the TR1 features mandates true for is_pod<void>, etc. Arguably this is a defect, which has been fixed in the ongoing work for the next standard, so-called C++0x.

The TR1 document in section 4.9 states:

8 It is unspecified under what circumstances, if any, is_pod::value evaluates to true, except that, for all types T:

is_pod<T>::value >=
   (is_scalar<T>::value || is_void<T>::value);

Given that, the bug report ID:458570 I submitted to Visual C++ 9.0 and it’s TR1 implementation on Microsoft Connect stays valid and according to what Stephan T. Lavavej confirmed in comments to my report, it’s been fixed in Visual C++ 10.0.

Paolo also added a note particularly important to programmers relying on C++ implementation by GCC compiler and libstdc++ library:

In general, we consider TR1 essentially frozen at this time and minimally maintained, consider that it was just an interim Technical Report

Here are references that are fundamental for the matter:

  • n1836 – Draft Technical Report on C++ Library Extensions
  • n2960 – Working Draft, Standard for Programming Language C++
  • Implementation of is_pod<T> and the rest of type traits by Boost.TypeTraits library.

Mission accomplished ;-)

Traits of void

Posted on by
Reply

Long time ago, I reported bug to Visual C++ 9.0 (Visual Studio 2008 SP1) complaining that has_trivial_destructor applied to void returns true (ID:458570). I also discussed it with folks on comp.std.c++ where, among quite different voices, Pete Becker writes:

[tr.meta.req]/8 in TR1 requires is_pod::value to be 1. n2857 is not a standard, and implementations of previous standards are not wrong for not doing what isn’t yet required of them.

and later concludes:

Under the current standard, using the name std::is_pod requires a diagnostic. So if you want to be literal, both compilers are “wrong”. Nevertheless, neither is really “wrong”, they just implement different non-standard versions of is_pod.

So, Visual C++ might actually not be wrong. Fair enough.

Today, I got back to this issue for a while a little extending my test program to use the type traits from both, TR1 and C++0x:

#include <iostream>
#include <tr1/type_traits>
int main()
{
using std::cout; using std::endl;
cout << std::tr1::is_pod<void>::value << endl;
cout << std::tr1::has_trivial_destructor<void>::value << endl;
cout << std::is_pod<void>::value << endl;
cout << std::has_trivial_destructor<void>::value << endl;
}

and compiled it with GCC 4.4.1:

$ g++ -Wall -pedantic -std=c++0x void.cpp
$ ./a.out
1
1
0
0

Now, my confusion has been raised to the power of 2. This is clearly a Polnische Wirtschaft or Czech movie or Turkish sermon…

…let’s try to ask libstdc++ folks.

Inconsistent int64_t definition in GCC?

Posted on by
Reply

While compiling programs on Linux 32-bit with Comeau C/C++ 4.3.10.1 front-end and GCC 4.3.3 I encountered some problems using Boost Integer library, namely boost/cstdint.hpp header. Here we go:

If I first include sys/types.h (added with POSIX), directly or indirectly, and then include boost/cstdint.hpp in C++ program:

#include <sys/types.h>
#include <boost/cstdint.hpp>
int main()
{
    boost::int64_t a(0);
}

then it does not compile:

$ como -I/home/mloskot/dev/boost/_svn/trunk test1.cpp
MODE:non-strict warnings C++ noC++0x_extensions
"/home/mloskot/dev/boost/_svn/trunk/boost/cstdint.hpp", line 111: error: the
          global scope has no "int64_t"
    using ::int64_t;
            ^
"bad.cpp", line 5: error: namespace "boost" has no member "int64_t"
      boost::int64_t a(0);
             ^

Then, if stdint.h (added with C99) is included first (again, directly or indirectly), then the program compiles without any errors:

#include <stdint.h>
#include <boost/cstdint.hpp>
int main()
{
    boost::int64_t a(0);
}

It turns out that there is some amount of overlap in the stdint.h and sys/types.h headers. The issue is that the overlapped parts slightly differ. For the architecture, operating system and compilation toolset I use, both headers define int64_t type as follows:

typedef long long int int64_t;

However, the definition in sys/types.h header is guarded with different preprocessor condition testing __GLIBC_HAVE_LONG_LONG:

#  elif __GLIBC_HAVE_LONG_LONG
__extension__ typedef long long int int64_t;
#  endif

If I change sys/types.h replacing the clause with simple #else:

#  else
__extension__ typedef long long int int64_t;
#  endif

then the first variant of my program, the one including sys/types.h, does compile perfectly well.

Now, is this small difference a bug in the GNU C Library?
I’m going to try to confirm it.

como adventures with boost/cstdint.hpp

Posted on by
Reply

While compiling a program that uses boost/cstdint.hpp from Boost Integer Library:

#include <iostream>
#include <boost/cstdint.hpp>
int main()
{
    boost::int64_t i64 = -2;
    boost::uint64_t ui64 = 2;
    boost::uint64_t d = ui64 - i64;
    std::cout << d << std::endl;
    return 0;
}

front-end of Comeau C/C++ 4.3.10.1 compiler complains:

boost/cstdint.hpp", line 111: error: the
          global scope has no "int64_t"
    using ::int64_t;
            ^

However, if I reorder include directives:

#include <boost/cstdint.hpp>
#include <iostream>

then the program compiles well.

I believe that the order of header files should not be relevant here, but seems it is. I’ve submitted a ticket #3548 to Boost.Integer and I’m curious awaiting the diagnosis.

After this issue is fixed, I’m looking forward building the Generic Geometry Library using Comeau C/C++ compiler. This should help us to maintain high quality of standard and yet more portable C++ code.

Always use proper C++ integer types

Posted on by
2

When programming in C++, it’s a good idea to use proper integer types relevant to particular context. A little bit of strictness always pays back. It’s not uncommon to see a tendency to ignore the integral types defined as specific to standard containers, namely size_type. It’s available for number of standard container like std::string or std::vector. Such ignorance may get its revenge easily.

Below is a simple example of incorrectly used type to catch result of std::string::find function. I’m quite sure that many would expect there is nothing wrong with the unsigned int here. But, actually this is just a bug. I run Linux on 64-bit architecture and when I compile this program as is, it works as expected. However, when I replace the string in line [1] with abc, it still works but not as expected :-)

#include <iostream>
#include <string>
using namespace std;
int main()
{
  string s = "a:b:c"; // "abc" [1]
  char delim = ':';
  unsigned int pos = s.find(delim);
  if(string::npos != pos)
  {
    cout << delim << " found in " << s << endl;
  }
}

Fix is very simply. Just replace unsigned int with std::string::size_type. The problem could be avoided if somebody who wrote this program took care of use of correct type. Not to mention that the program would be portable straight away.

I’ve seen this kind of issues quite many times, especially in code written by former C programmers who do not like to wear the muzzle of strictness the C++ types system enforces and requires. The example above is a trivial one, but I believe it presents the root of the problem well.

It’s not acceptable to cut corners in the biscuits business, so why it should be acceptable in programming :-)

The Myth of Objectivity

Posted on by
3

I do not advocate anything or anyone. All right, may be I do advocate but only a few small tiny things like C++ programming language, generic programming and high quality of software code and design and my dog, of course. However, I let myself to go down in the discussion about advantages and disadvantages of Open Source GIS on OGC forum at LinkedIn and somewhat at OSGeo mailing list too.

A human nature pisses me off, sometimes. (I am a human being, in case of doubt.) The world is bloody relative but we love to sling absolutes around. Yeah, we love this game! We are not good in learning from mistakes, anyway. Thus, the only achievement of attempting to apply a patch to someone’s buggy ignorance is a waste of time and may be a bit of training in fast typing or boxing ;-)

Paul is right recommending don’t feed the troll!. But, what has been learned is going to be lost, naturally.