Learning C++

Comparing floating point numbers

2010-04-02T17:08:00.008+05:30

Floating point comparisons can be a painful work to achieve. And always must one avoid laziness in doing equality comparisons using inbuilt operator== for floating point numbers.

There could be roundings involved and/or infinite decimal expansions that can lead to inaccurate representations or better say, losing of some precision off the number. Owing to that, even though you would expect a number to match a definite expansion that the calculation may have lead to, it may not.

An easy way to handle that is to choose a reasonable tolerance in the comparison. For example, we could choose a tolerance of 0.0000001 when comparing two doubles for equality such that the absolute value of their difference if less than this value then, you could consider them to be equal or better say, 'close enough' for most reasonable cases. This tolerance can, however, be insufficient if:

    1) The numbers are very large or if the numbers are very small in value for the tolerance to be able to compare to their difference.
    2) If there have been multiple arithematic operations performed that could lead to compounded incorrectness (owing to multiple roundings/loss of precision involved) in the result.

In C++, there is a value std::numeric_limits::epsilon() that is referred to sometimes as machine epsilon value/tolerance or machine accuracy. It gives the difference between 1 and the smallest value greater than 1 that is representable for data type for which the template's instantiated, which is double here. This helps us with the standardization of the tolerance value that we previously had chosen as 0.0000001. But doesn't help us with the limitations 1) and 2) pointed out above.

There could more factors than that mentioned in 2) that can cause the rounding error. Apart from arithematic operations, it could be type promotions or binary conversions that can cause more than epsilon() rounding error. So, combination of 2 arithematic operations could lead to more than 2*epsilon. I don't know how quantifiable that is, but by a safer choice of N (number of arithematic operations involved), we hope to be able to overcome the problem in most practical cases. :-)

For the short-coming mentioned in 1), we would need to bring the epsilon to the degree of large-ness or small-ness of the numbers involved. Considering this, you might have something like:

template<typename T>
bool fequal(T x, T y, int N)
{
    T diff = std::abs(x-y);
    T tolerance = N*std::numeric_limits::epsilon(); //caters to 2)
    return (diff <= tolerance*std::abs(x) && diff <= tolerance*std::abs(y)); //caters to 1)
}

where x and y are the input numbers being compared for near equality and N is the approximate number of rounding errors you are expecting.

References:

1) Trap Handlers, Sticky Bits, and Floating-point Comparisons
2) Floating-point comparison algorithms
3) numeric_limits::epsilon

Floating point numbers and NaN

2010-04-02T14:11:00.008+05:30

NaN expands to 'not a number'. Various floating point operations can lead to this value. IEEE-754 is the most widely used floating point computation standards. It defines 5 possible exceptions that can occur during floating point arithematic:

    1) Invalid Operation: when an invalid operation is performed on a number, for example, taking square root of a negative value, taking log of 0 or a negative number, etc.
    2) Division by Zero: when a number is divided by zero
    3) Overflow: when the result is too large to be representable
    4) Underflow: when the result is too small to be representable
    5) Inexact: when the result is inexact meaning the number was rounded and caused discarding of any non-zero digits

The cases falling under invalid operation would result in a value of NaN as per the above mentioned standard. (I get -INF with gcc 3.4.4, but NaN for any negative number's logarithm). You would check for NaNs and Infinities resulting out of computations in order to determine the success and validity of the operation but that can lead to code that is cluttered with ifs and elses and can become almost un-readable. You can, however, do the checks at every logical chunk of the computation. However, NaNs and INFs can get lost mid-calculations. The standard dictates that an exceptional value NaN or INF should get propagated throughout the calculations so that the checks at the end of a computation could catch them but certain operations can lose them, for example:

    1) NaN operation with INF value would result in INF, as in NaN + INF = INF.
    2) INF can become 0, as in x/INF = 0

The way to catch these would be to check the sticky bits that are essentially the exception flags that are set on occurence of floating point exceptions anywhere during the calculation. But let's not get too carried away and leave it to the credibility of the programmers and users to be able to handle the various cases in the most sensible way. :-)

To conclude, here is a function that will help check if a value is a NaN or not, based on the fact that any comparison involving NaNs would result in 'false' result:

template<typename T>
bool myIsNaN(T value)
{
    return value != value;
}

C99 has a function isNaN() and TR1 for C++ has included the support for this function but just in case your compiler doesn't support it. Similarly, you have isinf() that will help catch both positive and negative infinities. If you are feeling too experimental, try your own version of isinf() using numeric limits. :-)

References:

1) Trap Handlers, Sticky Bits, and Floating-point Comparisons
2) What is this NaN thing?
3) C++ Numeric limits
4) Wikipedia - IEEE 754

Extending enums

2010-03-27T15:33:00.001+05:30

There might come a scenario where you want to include an enum into a another one where the first one is a subset.

#include
struct enum_a {
     enum constant {
         a, b, c, d,
         end_of_enum_a = d
     };
};
struct enum_b : public enum_a {
     enum constant {
         e = end_of_enum_a + 1,
         f, g, h
     };
};
int main() {
     std::printf("enum_a: a(%d), b(%d), c(%d), d(%d)\n",
         enum_b::a, enum_b::b, enum_b::c, enum_b::d);
     std::printf("enum_b: e(%d), f(%d), g(%d), h(%d)\n",
         enum_b::e, enum_b::f, enum_b::g, enum_b::h);
     return 0;
}

Inheritance to the rescue. :-)

String literals in C++

2009-07-28T21:29:00.006+05:30

Here's a short one on string literals in C++. Ask yourself: what is their type? It is 'array of n const char', correct! So, we might think:

char* literal = "Hello World!";

would be "invalid"/"illegal" in C++. But you'd be surprised it is not and even Comeau online compiles it successfully without even a warning.

The C++ standard, however, tries to protect you hinting that the above is wrong by stating that it is a deprecated feature in C++ that probably was allowed to keep backward compatibility with C.

Here is what the standard says as part of section [2.13.4/2]:

[quote]
A string literal that does not begin with u, U, or L is an ordinary string literal, also referred to as a narrow string literal. An ordinary string literal has type “array of n const char”, where n is the size of the string as defined below; it has static storage duration (3.7) and is initialized with the given characters.
[/quote]

So, the following would have definitely been invalid in C++:

char* literal = "Hello World!";

"Hello World!" is an array of 13 [spooky :-)] constant characters. 'literal' is the pointer to the first element of the array and since that element is const, the pointer cannot be declared as a non-const char*. The pointer has to be of the type 'pointer to a const char'.

But as mentioned above, to have backward compatibility with C where the above works an implicit conversion is defined for array to pointer conversion where a string literal would be converted to an r-value of type "pointer to a char". The standard mentions this in section [4.2/2]:

[quote]
A string literal (2.13.4) with no prefix, with a u prefix, with a U prefix, or with an L prefix can be converted to an rvalue of type “pointer to char”, “pointer to char16_t”, “pointer to char32_t”, or “pointer to wchar_t”, respectively. In any case, the result is a pointer to the first element of the array. This conversion is considered only when there is an explicit appropriate pointer target type, and not when there is a general need to convert from an lvalue to an rvalue. [ Note: this conversion is deprecated. See Annex D. —end note ]
[/quote]

But, the thing to be happy about is the note above, that is re-iterated in Annexure D section [D.4/1] as:

[quote]
The implicit conversion from const to non-const qualification for string literals (4.2) is deprecated.
[/quote]

So, best is to keep the good habit of declaring the pointer to the literal as a pointer to a const. :-)

[The C++ standard's draft version used for quotes above, has document number : N2315=07-0175 dated 2007-06-25]

Accessing static members of a class

2009-03-01T14:23:00.002+05:30

Static members of a class are not associated with any one particular instance/object of it. They can even be accessed without any instance. The way to refer to them in your code is as shown below:

[CODE]
class Test
{
    private:
        static const std::string className;
    public:
        static const std::string& getClassName()
        {
            return className;
        }
    //other members
};

int main()
{
    std::cout << Test::getClassName();
}

It is also allowed to be able to access the static members via an instance/object as below: (modifying the above main function and keeping reset the same)

int main()
{
    Test testObject;
    std::cout << testObject.getClassName();
}

Usually though, it is better to use the previous notation using the scope resolution operator (op '::'). That makes the code more readable in the sense that you know it is a static member and not a non-static one. It speaks for itself.

Inline specializations and multiple inclusions

2009-01-24T22:48:00.002+05:30

Recently, I came across a problem being faced by an individual on the forums. He had the code like this:

[CODE]
//file: header.h
#ifndef HEADER_H
#define HEADER_H

#include <iostream>

template<class T>
void foo(T val){
    std::cout << "foo<T>("<<val<<")\n";
}
template<>
inline void foo(double val){
    std::cout << "foo<double>(" << val <<")\n";
}

#endif

//file: main.cpp
#include "header.h"

int main(){
    double x=4;
    foo(x);
    return 0;
}

//file: other.cpp
#include "header.h"
void somecode(){}

Just to summarize the above code, there is a header file (header.h) that contains the template functions and its specialization on type 'double' for template type parameter declared inline. And that header is being included into 2 implementation files (main.cpp & other.cpp)

This code compiled fine for him but as soon as he removed the inline keyword, it started to given him linker error for multiple definitions of the foo<double> function. We might start wondering what is it between templates and inline that might be causing this? Something and nothing. What happens is explained below:

The linker error seen is not specific to templates or specializations. One will face the same problem if they turned foo into a non-template function. C++ functions have external linkage hence they must be implemented in just one .cpp file (implementation file). They can, however, be declared multiple times. When we provide the implementation in the header file instead of an implementation file and that header is being included multiple implementation files (main.cpp and other.cpp), we have multiple definitions and hence, rightly the linkage error. Putting the implementation into the header file was what we were forced to do when using a template function because we need to put the implementation in the header file as well as the declaration since 'export' doesn't work except for just with the Comeau compiler. But specializations are a different case than regular templates. We don't face such issues with regular templates (not their specializations) because the instantiation rules guarantees that there is just one copy of the function generated as and when needed. While in case of specializations, we end up with multiple definitions because of them being included into multiple implementation files.

Now, with inline functions, we provide the implementation in the header file so as to be visible to the compilation point where they are used. They become inline in the final executable or not is irrelevant. You just follow the rule to define the inline functions. There will be only one copy of them.

Coming to the solutions to the above linker error, below are the two simplest ways:

1. Make the specialization as inline (as in original code, in case, someone facing this issue didn't have it in the first place)

2. Declare it not as a specialization but just as an overloaded foo function and declare it in the header (header.h) and provide implementation in an implementation file (for that matter any one implementation main.cpp/other.cpp or a .cpp of its own for header.h templates' specializations just making sure we don't do it twice).

References:

1. Codeguru thread where I came across this - "inline" and linking errors
2. C++ FAQ Lite on Inline Functions

Permutations in C++

2008-08-15T22:04:00.004+05:30

A small simple sample that illustrates how to get the various permutations of the characters of a string in C++ using std::next_permutation provided under the standard include <algorithm>.

[code]
#include<algorithm>
#include<string>
#include<vector>
#include <iostream>

int main()
{
    std::string input="ABC";
    std::vector<std::string> perms;
    perms.push_back(input);
    std::string::iterator itBegin = input.begin();
    std::string::iterator itEnd = input.end();
    while(std::next_permutation(itBegin, itEnd))
    {
        perms.push_back(std::string(itBegin, itEnd));
    }
    std::copy(perms.begin(), perms.end(), std::ostream_iterator<std::string>(std::cout, "\n"));
}
[/code]

C++ unions : how to find currently active member

2008-07-27T18:31:00.004+05:30

C++ unions can have member functions. And to surprise you even more, they can have constructors and a destructor. But that's not all that I intend to write about. A question straightaway comes into our mind: If unions can have member functions, how would you know which of its data member is currently 'active' or 'set' (well, this can come up even in case they don't have member functions, not very specific to them).

This is important to know because if say member1 of the union is set then that is the one that is active and you can only access its value. Accessing value of any of the other members is undefined behavior as per the standard and we all know what undefined behavior means; it may work in your case, on your machine, and it can fail you in front of a very potential client of yours or your managers when demo-ing your application.

Here is a way; you can let your member functions (is applicable to unions in general) know which data member is currently set:

[code]
union myunion
{
    int member; //if == 1 then mem1 is set, use it; if ==2 mem2 is set, use it
    struct
    {
        int struct_id; //1

        //other members
    } mem1;
    struct
    {

        int struct_id; //2
        //other members
    } mem2;
    //and so on...
    void memfunc()
    {
        //could use a switch
        if(member==1)
        {
            //use mem1
        }
        else if (member ==2)
        {
            //use mem2
        }
        //and so on...
    }
};
[/code]

The in-lined comments are self explanatory. The member variable 'member' can be used as a signifier as to which of the other struct members is currently active, reading which is not unsafe. What makes it safe, you might wonder? To understand the guarantee that the programmer is provided with, let's go through what the C++ standard has to say about it. Quote: 18.5 [class.union]/1 provides the rules that suffice the above explanations. I will quote that paragraph in full below:

[quote]
In a union, at most one of the data members can be active at any time, that is, the value of at most one of the data members can be stored in a union at any time. [Note: one special guarantee is made in order to simplify the use of unions: If a standard-layout union contains several standard-layout structs that share a common initial sequence (9.2), and if an object of this standard-layout union type contains one of the standard-layout structs, it is permitted to inspect the common initial sequence of any of standard-layout struct members; see 9.2. —end note] The size of a union is sufficient to contain the largest of its data members. Each data member is allocated as if it were the sole member of a struct. A union can have member functions (including constructors and destructors), but not virtual (10.3) functions. A union shall not have base classes. A union shall not be used as a base class. An object of a non-trivial class (clause 9) shall not be a member of a union, nor shall an array of such objects. If a union contains a static data member or a member of reference type the program is ill-formed.
[/quote]

The above tells you that member functions are allowed with unions including constructors and destructors. It also makes a statement that structs inside a union that follow a common initial sequence, it is legal to inspect (i.e. query or read the value of) that common initial sequence. Also, it says that, each data member is allocated as if it were the sole member of a struct. In our example above, 'member' is such a data member. It is as if you have a struct as a member of the union with just a single data member of type 'int'.

Moreover, there is another mention in section 9.2/18 as follows:

[Quote]
A pointer to a standard-layout struct object, suitably converted using a reinterpret_cast, points to its initial member (or if that member is a bit-field, then to the unit in which it resides) and vice versa. [Note: There might therefore be unnamed padding within a standard-layout struct object, but not at its beginning, as necessary to achieve appropriate alignment. —end note]
[/quote]

Considering the above quotes, it is guaranteed that, each 'struct_id' (in the code sample above) shares the same layout as the first member of the union of int type "member". And hence using them (being the same initial sequence) in a union is perfectly safe, independent of which union member had been previously set (or is active).

This (the int member 'member') allows us to have a convenient way to see which data member of the union is currently active without peeping into any specific struct members (not that it is impossible) and without causing any effect on the size of the union.

Having member functions find out the active member that way is a little inextensible. What if you plan to add another struct member? You would need to enhance the switch statement, or the if-else-if conditionals to accommodate that. But then, even in case unions have no member functions, you might very well need to know that information and the above method helps.

comparing structs with memcmp

2008-05-03T17:31:00.011+05:30

Can you use memcmp to compare C style structs reliably? Let's first see what the C-standards has to say about the function: memcmp.

From the C-standards, 7.21.4.1/The memcmp function:

[QUOTE]
Synopsis
1 #include <string.h>
int memcmp(const void *s1, const void *s2, size_t n);

Description
2 The memcmp function compares the first n characters of the object pointed to by s1 to the first n characters of the object pointed to by s2.(248))

Returns
3 The memcmp function returns an integer greater than, equal to, or less than zero, accordingly as the object pointed to by s1 is greater than, equal to, or less than the object pointed to by s2.
[QUOTE END]

The footnote (248) mentioned above is important and interesting:

[QUOTE]
The contents of ‘‘holes’’ used as padding for purposes of alignment within structure objects are indeterminate. <snipped>
[QUOTE END]

There's our trouble. Indeterminate values. There can be unused padding bytes with structures as need by alignment requirements for a platform and how they are filled is not defined by the standard. It is not even mentioned if they are going to be initialized or how they get initialized. You might get lucky with the indeterminate values but in the programming world, we always consider ourselves unlucky with something like that. So, unless you are very sure that there is no padding memcmp is rendered useless. You can find if your struct has padding or not as below :

[CODE]
    if (sizeof(mystruct) == sizeof(member1) + sizeof(member2) /*+ ..so on...*/)
    {
        //no padding - probably can use memcmp - but are you really sure!!!???
    }
    else
    {
        //has definitely some padding - dont use memcmp
    }
[CODE END]

Even though you find no padding, it is not safe to do memcmp in all cases. One reason that I can make out is because +0 and -0 for us would be same. They should evaluate equal but memcmp would not think the same way. To generalize it, whenever there are more than one bit representation of a particular value, memcmp may report false negatives, when the values might be equal but comparing their bit pattern comes unequal.

Below are few points of concern would prevent reliable use of memcmp to comparing 2 structs or even 2 basic fundamental datatypes or an array of those:

1. Unused bits : Not all bits for a type (except unsigned char) are used for its value representation. For example, on a platform where an int is 4 bytes and considering that for the platform, a byte has 8 bits, not all 32 bits be used to represent the value held by an int. So, on such platforms the largest possible value of an int may not be 2^(32-1) but lesser. How the unused bits are filled is implementation specific and hence memcmp would not be reliable to even compare the basic fundamental types like int even when the values are equal. The unused bits are called holes.

2. Padding bytes : Padding bytes within a struct between 2 members of the struct to cater to alignment requirements. The padded bytes will have indeterminate values that may compare equal or unequal in a non-deterministic way. So, memcmp would lead to false negatives for comparison. However, the positives returned would be reliable but that would be a smaller set out of the possible positives of the comparison.

3. Unreliable treatment of unused bits and padding bytes after memset : memset on the types or structs can probably work around the uninitialized padding bytes/holes indeterminate values (as it treats the data as a sequence of unsigned chars which have no holes) but there can be other reasons to failure and who knows if the values of those padding bytes might change during the process of the program between a memset call and a memcmp call. If the standards explicitly prohibits an implementation from doing so, please let me know and I shall correct myself. The relevant quote would be fantastic!

4. Floating types : floating point numbers cannot even be compared reliably using ==, forget about memcmp. They always need to be compared to be a around each other but varying by some value of epsilon() as defined by the compiler.

5. Pointer representation : Pointer's bit representations can be different for the same linear address and two completely different pointers may compare equal. Of particular peculiarity is the segment:offset representation where two different segment::offset pair values stored in a pointer's representation may actually by referring to the same linear address. Linear address here = segment*16 +offset. You will get 2 different pairs of segment and offset for which the equation would evaluate to the same linear address. The inbuilt == operator is guaranteed to work such that two pointers of the same type pointing to the same object will always compare equal. This is also considering you are just wanting to compare the pointers and not the values pointed to by them.

Considering the above cases when memcmp would be unreliable, I would choose member wise comparison to be the solution to choose to compare 2 structs of same type. If the structs are different types with comparable members (but could be of different types), memcmp would probably fail more miserably. If it is a non-POD struct, it is simply undefined behaviour.

It is worth going through the following discussion on comp.lang.c that discuss the above in greater detail : Expert-Q: (a!=b) != memcmp(&a, &b, sizeof a) ?.

boost::tokenizer and BOOST_FOREACH

2008-04-19T23:33:00.005+05:30

I looked at the documentation for what all could foreach macro support? The list didn't have boost tokenizer in it, which was expected but it said something that meant, it should work: "The support for STL containers is very general; anything that looks like an STL container counts. If it has nested iterator and const_iterator types and begin() and end() member functions, BOOST_FOREACH will automatically know how to iterate over it."

So, I tried it out and yes, it worked. The following compiled and worked fine with VC++ 2005. The code should be easy to understand that basically, reads a file line by line and tokenizes the lines assuming a space or punctuation as the seperator.

[code]
    //standard headers
    #include <iostream>
    #include <fstream>
    #include <string>

    //boost headers
    #include <boost/tokenizer.hpp>
    #include <boost/foreach.hpp>

    //make BOOST_FOREACH prettier! ;-) :-)
    #define foreach BOOST_FOREACH

    void tokenizeLines(std::istream& inputStream)
    {
        if(inputStream)
        {
            std::string line;
            while(std::getline(inputStream, line, '\n'))
            {
                boost::tokenizer<> tokens(line);
                foreach(const std::string & str, tokens)
                {
                    std::cout << str << "\n";
                }
            }
        }
        else
        {
            std::cerr << "Error: Invalid stream object\n";
        }
    }

    int main()
    {
        std::ifstream inputStream("C:\\testfiles\\myfile.txt");
        tokenizeLines(inputStream);
    }

Case insensitive string comparison

2008-04-16T19:56:00.004+05:30

While looking up for case insensitive comparison function, I came across this nice article by Matt Austern : Case Insensitive String Comparison). And decided to try to make a sample that does that. Below is the result, am not sure if it is perfect and has no issues but that is the best I could do. Atleast, better than ignoring the locale completely! Yes, ignoring it would work most of the times as it's not needed but just in case, a need came up, what would you do?

I tested the code with VS 2005 (couldn't test it with gcc as I found out that I did not have support for the german locale as I only had the sample strings for that language (out of the above article) and I felt lazy enough to find more sample to test) but if someone finds an issue with some other language words for which your compiler provides locale support, can you please point it out?

Code:

    #include<iostream>
    #include<locale>
    #include<string>
    #include<algorithm>
    #include<functional>
    //used boost::bind due to buggy bind2nd
    //#include<tr1/bind.hpp>
    #include<boost/bind.hpp>

    //using namespace std;
    //using namespace std::tr1;
    //using namespace std::tr1::placeholders;

    using namespace boost;

    struct CaseInsensitiveCompare
    {
        bool operator()(const std::string& lhs, const std::string& rhs)
        {
            std::string lhs_lower;
            std::string rhs_lower;
            //std::transform(lhs.begin(), lhs.end(), std::back_inserter(lhs_lower), std::bind2nd(std::ptr_fun(std::tolower<char>), loc));
            //std::transform(rhs.begin(), rhs.end(), std::back_inserter(rhs_lower), std::bind2nd(std::ptr_fun(std::tolower<char>), loc));
            std::transform(lhs.begin(), lhs.end(), std::back_inserter(lhs_lower), bind(std::tolower<char>, _1, loc));
            std::transform(rhs.begin(), rhs.end(), std::back_inserter(rhs_lower), bind(std::tolower<char>, _1, loc));
            return lhs_lower < rhs_lower;
        }
        CaseInsensitiveCompare(const std::locale& loc_): loc(loc_){}
    private:
        std::locale loc;
    };

    int main()
    {
        std::string lhs = "GEW\334RZTRAMINER";
        std::string rhs = "gew\374rztraminer";
        std::cout << "lhs : " << lhs << std::endl;
        std::cout << "rhs : " << rhs << std::endl;
        CaseInsensitiveCompare cis((std::locale("German_germany")));
        //CaseInsensitiveCompare cis((std::locale()));
        std::cout << "compare result : " << cis(lhs,rhs) << std::endl;
    }

One obvious improvement/alternative could be not copying the strings and instead doing a per character based tolower/toupper and compare them. This has a 2nd advantage as well that it will break out as soon as a mismatch happens for a character, without the need to convert the whole 2 strings into a common case.

Herb Sutter, in one of his Gotw's, writes about a case insensitive string class but also shows the basic problems that would have. Quite simply put, it doesn't work with iostreams (cout/cerr etc). Here: Strings: A case insensitive string class.

Remove duplicates from vector

2008-04-13T11:05:00.009+05:30

Q. How do you remove duplicates from a vector?

A. This is how:

    template<typename T>
    void removeDuplicates(std::vector<T>& vec)
    {
        std::sort(vec.begin(), vec.end());
        vec.erase(std::unique(vec.begin(), vec.end()), vec.end());
    }

If I needed a container to keep itself populated of only unique values, I would probably choose std::set but then choosing the right container depends on so many other different factors as well.

Edit Comment : Corrected above by replacing remove with erase as there isn't such a member function in std::vector. std::erase, however, is and the code works with just that replacement.

Copy constructor forms

2008-04-12T10:23:00.005+05:30

The copy constructor can have both forms(*) as below:

    A(A& rhs);
    A(const A& rhs);

Both are perfectly valid and it is pretty easy to forget the 'const' for the rhs argument. The compiler accepts it as a perfectly valid syntax thinking that is what your intent was. But the above two are a bit different from each other. The first one rejects to work with/copy from parameters that are not const objects of type A as well as temporaries. So, if you tried something like this:

    const A const_a;
    A copy_const_a(const_a); //ERROR!
    A copy_from_temp(A(/*some arguments*/)); //ERROR!
    A copy_from_return_val(somefunc_return_A_by_val); //ERROR!
//any other forms that might want to create copies out of const or temorary objects

the compiler will just shout at you at the appropriateness of the copy constructor you wrote. And if you by any chance overlooked the argument for your it assuming it be correct, you would most certainly lose some of your precious time thinking probably some of your member objects are not copy constructible or there's some issue of that sort.

This brings us to the primary point of const correctness. Make things const, declare them const unless you explicitly wanted them to be non-const. I know some people who have the opinion that this should have been implicit by the language and to make something non-const there should have been a keyword i.e. there were a keyword 'mutable' (not in the sense that it is used in the language currently) or something similar to let know that the object is non-const. But it's probably too late for it. :-)

(*) Or for that matter any of the 4 forms as mentioned below:

    A(A& rhs /*, either no other args or all default args*/);
    A(const A& rhs /*, either no other args or all default args*/);
    A(volatile A& rhs /*, either no other args or all default args*/);
    A(const volatile A& rhs /*, either no other args or all default args*/);

Zero-sized arrays

2008-02-17T21:19:00.004+05:30

It is valid to do the below:

    T * ptr = new T[0];

0 is a perfectly valid input to the array form of new expression. What is the use of it, you may ask. No use as far as the array is concerned. What use is an array if it does not have any members? What can you possibly do with it? Nothing! Right, you cannot do anything with it but the statement above being valid is atleast a little bit helpful.

It allows you to have code like this:

void f(size_t n)
{
     int * ptr = new int[n];
     //...
     delete[] ptr;
}

instead of:

void f(size_t n)
{
     if (n>0)
     {
         int * ptr = new int[n];
         //...
         delete[] ptr;
     }
}

No other use though as said earlier, because since it has zero elements, you cannot do anything with it.

This reminds of another peculiar extension related to zero sized/unsized arrays. VC++ has an extension which makes use of zero sized arrays as the last member of structures. For example, see this:

#include<cstdlib>
#include<iostream>

struct test
{
     int cb;
     int buf[];
};

int main()
{
     test* bb;
     int length = 10;
     bb = (test*) malloc(sizeof(test)+sizeof(int)*length);
     bb->cb = length;
     //fill buf with length int items or can copy from another array for length elements
     bb->buf[i]=10; //i should be less than length
     //OR--------
     test aa = {10, {1,10,22,32}};
     std::cout << aa.buf[2];
}

Since the zero size member is in there, there are few restrictions as well. You cannot create an array of the test struct. You can mimic that though like this:

    //create an array of length 10 of test pointers
    test * ptr[10];
    //set each of the pointers to individual elements created as above

Generally, you would be better off keeping a pointer member but it is
worth noting the presence of such an extension. See for details :
Unsized arrays.

The rationale as per msdn is saving the runtime pointer dereferences and that is not specific to C. How big that overhead is, with respect to the application in order to make a choice to this extension, is a different story altogether. You could even implement std::vector<T> using this extension rather than having a pointer to type T! That is, std::vector<T> implementation with VC++ might use this extension but they don't do so. :-)

Interesting one, this one... isn't it? :-)

const in C and C++

2008-02-17T11:30:00.003+05:30

Globals are usually bad but not always. Consider C code that is to be migrated to C++ and has a bunch of global constants. As soon as that code is worked upon and is compiled as C++, those const globals will cause the compiler to start emitting "undefined reference" or similar errors.

This is because of fundamental different between how const is treated in C and C++ in the context of linkage.

In C, apart from the fact that const are non-modifiable variables, they are the same as any other variables. In C++, const have different linkage as well. C++ const objects/variables have internal linkage and hence you get unresolved symbol error when you try to access something in a different compilation unit having iternal linkage from another compilation unit.

The solution is to include the extern declaration following right after you define the const variables, the same one that you put in another files or simply define the variable as extern const instead of just const.

#pragma once standardized?

2008-02-17T11:10:00.002+05:30

I have at a few places, where people have mis-heard/mis-read that that #pragma once has been standardized for C++0x. It's "not".

Even gcc has it labelled as an obsolete feature (for a couple of years now) - Obsolete once-only headers.

Since, it is not standard in the first place, one should avoid using it. The standard include guards "#ifndef" should the choice and with good compiler support, these are as efficient as the promise made by #pragma once. Plus they are guaranteed to be portable.

Reading file all at once

2008-02-17T10:58:00.002+05:30

Few times, you would want to read the whole file in one go, not line by line, not by a fixed buffer size. Here's a way to get that done:

    std::fstream ifs("filename.txt");
    if (!ifs)
    {
         std::stringstream oss;
         oss << ifs.rdbuf();
    }

As simple as that. The contents of the file are moved (re-directed) to the stringstream. The same code can be used to make copies of files. You would need to replace the stringstream object with an fstream one though.

Initialization lists and base class members

2007-11-29T18:44:00.000+05:30

Just some thoughts upon a question that I ran across, raised about, why you could not initialize base class members in derived classes. Put it another way, why could you not use the base class data members in derived class' initialization lists. Simplest reason - the standards, the language rules don't allow it. But let's have some fun with the "what-if"s.

One reason that struck me almost as a first thought, that the data member could be private in which case, you won't have access to it in the derived class. But what if it is public or protected? Let us take an example:

    class Base
    {
    public:
        Base(){}
        Base(int member_) : member (member_){}
        int member;
        //other members
    };

    class Derived : public Base
    {
    public:
        Derived(int member_) : member(member_){}
        //other members
    };

    int main()
    {
        Derived derivedObject(10);
    }

You would have expected it to work since the base member is accessible in the derived class, it being public. After all, it is perfectly okay if you used it in the derived class constructor body! What is so special about initialization lists that only direct base classes, virtual bases and the containing class' data members can only appear?

You might think that the base class object might not have been allocated or does not exist at all while in the initialization list of the derived class and hence it is not allowed to do that. But that reasoning would be flawed. Why? For the following reason (quoting section 12.6.2 (5) from the standards):

Initialization shall proceed in the following order:

    — First, and only for the constructor of the most derived class as
described below, virtual base classes shall be initialized in the
order they appear on a depth-first left-to-right traversal of the
directed acyclic graph of base classes, where “left-to-right” is
the order of appearance of the base class names in the derived
class base-specifierlist.

    — Then, direct base classes shall be initialized in declaration order
as they appear in the base-specifier-list (regardless of the order
of the mem-initializers).

    — Then, non-static data members shall be initialized in the order
they were declared in the class definition (again regardless of
the order of the mem-initializers).

    — Finally, the body of the constructor is executed.

    [ Note: the declaration order is mandated to ensure that base and
member subobjects are destroyed in the reverse order of initialization.
    —end note ]

So, the base is already initialized before anything else happens in the initialization list. What could be the reason then? The reason probably is that it does not make sense! Once the base constructor has initialized the base member, the derived class initializing it does not make sense. How can one thing be initialized twice? The second time, it has to be an assignment.

But again, that holds true just for non-POD members. For the object being constructed in the above code, via default constructor of the base class, the POD member "member" remains uninitialized! It will have an indeterminate value. So, it won't be double initialization, would it? It would be initialized just once and that from the derived class constructor (initialization list).

Now, consider there were a further derived class that publicly derived from the above "Derived" class having the same member initialization syntax. Now, that makes it two. This could probably have been dealt with some complication set of rules but why add that logical overhead?

That is not all though. The *rules* can get more complex. The consideration of different access specifiers (private/protected), different inheritance types (private/protected), an explicit constuctor call that too initializes the member, virtual bases, different treatment for non-POD and POD types and what not. Things just start to get too complex and dirty if you allow that.

Simply speaking, base class members should be the base class' responsibility and derived class should only be concerned with the construction abstraction provided by the base classes in form of the base constructors and their initialization lists. Making things more coupled is always a sign of bad design choice where things just start to fall apart as soon as something changes. That is not good code.

To make things clear and simpler, it's best said and accepted that the standard does not allow it for initialization lists to take up the responsibility of initializing base class members, just the immediate bases, virtual bases and class' members.

Have fun... Cheers!

Threading Building Blocks

2007-11-24T13:44:00.000+05:30

Just for a quick note. Intel recently made their TBB library open source and since it has a different task-based approach to incorporating parallism in C++, it felt interesting. It uses threads internally but keeps the user code away from threads themselves by parallelizing actions/tasks user performs in his/her code. Looks nice, sounds good, since threads are basically a low level detail to achieving benefits of parallel processing and if there can be laid a layer of abstraction that insulates programmers from those details, it could ease out and quicken the developement of parallel processing within applications without getting into the nitty-gritty of threads. Analogously, do we deal with the parallel processing across FPUs?

Few days back I downloaded the Open Sourced Intel Threading Building Blocks library and started to test a few samples with it.

One of the sample solution in there was using parallel_for algorithm (parallel_for.h). It was giving me a fatal error that the file affinity.h could not be found. It did not exist! This file was being included in parallel_for.h.

After much of searching and going quickly through the docs, I could not find the reason but I luckily bumped into a thread in the libraries discussion forum. Where one user complained of the file missing from the development release.

The suggestion to fix this was:

1. Either comment out the include.
2. Add an empty file in the include path.

This resolves the compilation issue but why keep such an include anyway? It wastes a bit of time of everyone who is new to the project and wants to get quickly building out samples and testing/debugging and seeing the library in action. Probably they will fix this soon.

More information can be found here - Latest Developer Release Missing affinity.h.

Hope this helps anyone who is starting out on TBB and falls upon the same problem until that header comes alive in the project while I will go back to experimenting more with it. Good luck and have fun! :)

boost::any

2007-09-14T09:57:00.000+05:30

boost::any is a strong concept and a much better replacement to void* to hold any type of data. You can make heterogenous containers using it as well. Let us see how it works in a very simplified way. The idea is to have a template class that can wrap all types and a value associated with that type. Something like this:

template<typename T>
class HoldData
{
    T t;
};

And then having a base class from which this wrapper would derive, so the above becomes adding a constructor that needs the type to be stored in it to be copy constructible:

class BaseHolder
{
    public:
        virtual ~BaseHolder(){}
};

template<typename T>
class HoldData : public BaseHolder
{
    public:
        HoldData(const T& t_) : t(t_){}
    private:
        T t;
};

Now, you would have a class, name it Variant that will take inputs of all types and then has a pointer to this wrapper's base type. So, now you have (including above classes):

class BaseHolder
{
    public:
        virtual ~BaseHolder(){}
};

template<typename T>
class HoldData : public BaseHolder
{
    public:
        HoldData(const T& t_) : t(t_){}
    private:
        T t;
};

class Variant
{
    public:
        template<typename T>
        Variant(const T& t) : data(new HoldData<T>(t)){}
        ~Variant(){delete data;}
    private:
        BaseHolder* data;
};

You construct the corresponding type's wrapper objects and save their pointer into the another class that you call variant, that can hold and help retrieve any data type and does not lose the respective type information. That is actually what boost::any does. Take a look at the code here - boost::any code.

The documentation on it can be found here - boost::any documentation.

Policies and Traits

2007-08-01T13:15:00.000+05:30

Policies - I got to know about them from Andrei's Modern C++ Design book. If there are different orthogonal (independent) ways to achieve a particular functionality, they are good candidates to be classified as policies and we can write types based on those policies. Policies, in general, are compile time variants of strategies as in Strategy pattern. For example, the allocator template parameter to STL classes could be said as an allocation policy - the default being std::allocator<T>.

Traits - I understand them as not achieve anything for the class or the type (policies do achieve some functionality for their host class). They basically tell something about the type.

For example, boost::type_traits (is_pod, is_fundamental, is_derived_of, is_polymorphic). All these help in knowing something about the type. They are not orthoganal (independent, de-coupled ) ways of doing something or exposing some functionality. They don't add something to the definition of the type rather they provide for a set of information.

If I may take another example : std::char_traits<charT>. They tell something about the type via a few typedefs but they also have functions that tell about how to compare, assign, find length, etc. These "add" to the definition of the type in the context (context meaning whatever char_traits is passed to make a string type out of basic_string). char_traits looks to include policies, looks like a collection of policies. It provides policies to compare, assign and find length. A basic_string of character type "char" can have a different definitions of (or ways to do) comparison. I can provide a specialization or a traits class of my own where I change the compare to be case insensitive. This seems like a policy because they are two different ways to achieve the same objective, to fulfil a requirement, to expose a functionality, to define the working in a specific context. I can define that policy as "A compare policy that must expose a Compare member function, callable with 2 char_type* types and a size_t argument signifying number of elements to compare and returns a boolean result".

As compared to char_traits if I take std::numeric_limits : this can be said to be a trait (or a collection of traits). They tell about what max() for a type is, what epsilon() for a type is. They are not policies. They don't achieve some behaviour but they may represent how types should/may behave or what properties they have. I cannot specialize traits. That would be wrong. Policies? Of course, specialize it, rename it.

Policies and traits are both compile time features. Type traits at runtime would be RTTI. Policies at runtime would be strategies. None of those need necessarily be templates though.

Based on the above understanding, I would be right in thinking that basic_string template would have been better defined as:

template
        <
                class CharT,
                template <class> CharTPolicyCollection,
                template <class> AllocationPolicy
        >
        class basic_string :
                public CharTPolicyCollection<CharT>,
                public AllocationPolicy<CharT>
{
        //members
};

because otherwise, if you wrote something like this:

        typedef std::basic_string
                <
                        char,
                        std::char_traits<wchar_t>,
                        std::allocator<wchar_t>
                >
        mystrtype;

.. and you would not be wrong. The only problem being it will not work as expected for a sequence of char (i.e. like std::string). This problem exists because the basic_string doesn't use template template parameters. Had they used it, incompatible policies could not be clubbed with the host class to form a wierd type.

You should have protected CharTPolicyCollection and AllocationPolicy destructors if you are worried about the public inheriatnce and destruction via the base policy class pointers. Their virtual destructor would be also a solution but would be an unwanted overhead of the v-table. The typedefs there in std::char_traits though can be said to be traits, may be.

This is another reason why std::basic_string is not a very good design. The first being an overly loaded public interface.

Cya!

Handling dynamic array allocations

2007-07-11T10:47:00.000+05:30

One of the recent questions on the forums, that I answered to recently, was related to using std::auto_ptr<> with allocations from array form of new. The need to know was - if the following would work?

std::auto_ptr<int> ptr(new int[100]);

if not then why not?

The answer was simple if one knows what std::auto_ptr<> is good for, what its deleter is. std::auto_ptr<> uses delete operator to destruct owned pointer (pointing to a dynamic allocation made via new operator). So, it comes down to mixing of constructs like array form of new and simple delete. That is undefined behaviour as per the standards. You can read up more about these operators here - Free New, Delete Malloc

By design, the standard auto_ptr<> smart pointer is not suitable for dynamic array allocations. There can be many alternatives though. Few of those are as listed below:

Avoid self memory management and instead use std::vector<> / std::deque<> for dynamic arrays.
Use boost::scoped_array<>/boost::shared_array<>/boost::shared_ptr<> with a custom deleter (delete[]) passed in.
Write your own smart pointer : auto_ptr_array<> (same implementation as std::auto_ptr<>) just that it uses array form of delete instead of delete.

For the second point above - you can read more about custom deleters and shared_ptr<> here - Custom deleters with smart pointers

A boost::shared_array<>/boost::shared_ptr<> might not be the right choice if you don't want the reference count overhead of shared ownership which really should not be required when talking about auto_ptr<>s but if that's not an issue to worry about, it should work fine.

Another confusion arose, why doesn't std::auto_ptr<> do a delete[] instead of delete? Well, again, because it is not intended for array allocations. It would hence not work for singular objects created on the free store. This is because of the way delete[] might be implemented by the compiler.

There can be many ways in which delete[] could be implemented. Two of those are explained here - How does delete[] know how many elements to destroy? It is important for delete[] to know how many elements to destroy particularly since it is used with non-POD types as well and there, the destructor calls are necessary to be made for each of the to-be-destructed elements of the array.

The first method listed in the C++ FAQ Lite uses an extra allocation to remember the size you ask for at the runtime, if you used delete[] for single allocations, the compiler might try to interpret the block before the pointer you call it on as being size but since that was not allocated in the first place (new[] was not used!) - expect anything to happen, a crash or any other form of runtime error (depending upon how that error is translated on a particular system).

For the second, where array length association might not exist, it could cause anything depending upon a number of factors about the compiler implementation. One such possibility is, it could leave the variable uninitialized (yeah, its a bad thing, may not actually be happening, but who knows for sure about all compilers? We are just talking of possibilities here) - in which case the size could be anything - even 2 which goes beyond the buffer you allocated and again can cause any fault to the system/system free store. If the size is initialized to 0, it could leave the memory untouched and hence lost resulting in a leak. Memory leaks can be really dangerous particularly on systems that don't reclaim the leaked blocks by a process.

So, when the standard says, its undefined behaviour, it can result in anything. Worse could happen and thinking about these issues beyond the statement of "undefined behaviour" is rather silly. There can be many such "interesting" stories that one can write up. The key is, use std::auto_ptr<> what it is suited for, use delete/delete[] what they are suited for. Mixing them is really dangerous.

There is a peculiarity to note though. If you do the allocation for the single element using array form of new - you could use delete[] for that single element. That is:

int * ptr = new int[1];
delete[] ptr; //OK

Well, not really a peculiarity, but yeah, something to take note of.

Forum reference : What's wrong with std::auto_ptr<int> ptr(new int[100]);?

Pointers or references (function arguments)

2007-07-03T12:05:00.000+05:30

There is always a long discussion whenever a choice between a pointer or a reference is to be made. Be it when deciding function arguments (part of the interfaces) or when creating objects and working with them.

The fundamental difference comes around the NULLability of the pointers that helps decide if a reference should be used or a pointers. Certain people are also of the mind that having a pointer in the interface is a good signal to tell the caller that the value can be modified. But so can a reference tell you (of course, you would need to look at the interface). The point is further weakened by the const-keyword. What if the pointer is to a const? There are certain more interesting points to think upon that I touch above here.

Pointers can point to raw memory and not just valid or invalid or NULL objects. In object construction, there is are two steps of memory allocation and then construction via the constructor call. You would not want pass the memory being referred/pointed to as a reference when the second phase is yet to complete. For example, with boost serialization:

    // load data required for construction and invoke constructor in place
    template<class Archive, class T>
    inline void load_construct_data(
    Archive & ar, T * t, const unsigned int file_version ){
        // default just uses the default constructor to initialize
        // previously allocated memory.
        ::new(t)T();
    }

In the above snippet, passing the second object by reference would not make sense because the object is not yet fully constructed. For such lazy construction scenarios, a pointer parameter type looks more clearer as I would not want to associate a reference to a not-fully-constructed object. And quite reasonably, I am yet to see any code doing this.

In addition to that, pointers support arithematic on them, references don't. So, if there is such a need in a function, passing a reference makes it much less clearer. A pointer is more intuitive and natural. A reference would mean a single object (atleast I haven't seen anyone working with a reference to the first element of an array - containers aside - but still we work with iterators or random access there which is closer to pointer semantics). To me, it would look really poor choice to have a reference passed as a start element for an array. I have never seen such code. In this context, think upon : why don't STL algorithms take references? They could have had got back to pointers? They take iterators (and pointers) and it is not that all of them tend to modify the objects always.

Whole of memory management constructs in C and C++ revolve around pointers. new returns a pointer, malloc returns a pointer, free and delete work on pointers. So, preserve the naturality of expressions/statements, a pointer is a better choice. Similarly, references can be the right choice in many cases based on the same ground.

For a piece of C++ code that has to deal with C, or for that matter with any other language interoperability, pointers have no alternative. Why make an unnecessary transformation from pointer to reference and then back to pointer in such scenarios?

There are certain restrictions sometimes, for example exception handling disallowed in the code. In those scenario' of nothrow(), there are operations that throw with references (for example, dynamic_cast<> as compared to pointers. What would be more natural choice - a pointer argument or a reference? Well, that could be argued
upon depending on how the object was being declared and used prior to it but if this happens inside a function (for the interface writer), I would expect it to take a pointer than a reference. When you return the result of the cast, you would not want to dereference it and pass it back. All this pointer to reference transformation makes it look a lot less cleaner. Not to mention the case of a NULL return if the cast fails.

Now, I wonder why boost::lexical_cast<> doesn't take a pointer. For example:

template<typename Target, typename Source>
Target lexical_cast(const Source &arg)
{
typedef typename detail::array_to_pointer_decay<Source>::type NewSource;
detail::lexical_stream<Target, NewSource> interpreter;
Target result;
if(!(interpreter << arg && interpreter >> result))
throw_exception(bad_lexical_cast(typeid(NewSource), typeid(Target)));
return result;
}

This template would generate multiple instantiations for a char array of different sizes. That is plain code bloat. Boost writers prevent the lexical_stream<> from bloating by that decay trick but the lexical_cast template itself isn't saved. It needs compiler optimizations to prevent that (with VS2005 and gcc 4.1 that I know
of). That would have had been avoided had it accepted the Source
argument as a pointer in which case, all arrays passed would have had
automatically decayed to pointer. No hacks would have had been
required!

On the initial point of if a pointer/reference signalling modification inside the function - what if pointers are themselves passed by reference? How clearer would the code be from the calling point (for the caller)? :-)

What I feel is the natural semantics should be respected. Be it a reference or a pointer, it does not matter as long as the code does what it needs to do (checking for non-NULL pointers, not change an object) and the restrictions can be implemented using any of those. References provide ease to accessing members and you don't always need the '->' operator which can be a typing pain sometimes. :) I am with the C++ FAQ Lite on this - "Use references where you can, pointers where you have to." A little juggling between them is not really a concern except when it becomes too much causing loss of code clarity/readability and may be performance at some point of time.

Conforming/Non-conforming non-standard extensions

2007-07-03T10:45:00.000+05:30

Recently, I came across this piece of code on the forums where the original poster was claiming to be compiling fine with VS2005 C++ compiler.

[CODE]
class X{};
X f(){
return X();
}
void g(X&){}
int main(){
g(f());
return 0;
}

Quite puzzling, since this is strictly not allowed as per the standards - a temporary cannot be bound to a non-const reference and that is what is actually happening here - the temporary X object returned from f() is being passed to g() that accepts a reference to non-const X.

Could it be because there is no assembly instruction generated for the call in main() since g() is empty? I think not. Any C++ code has to be legal first to get successfully compiled. Optimizations and code generation happens later. One cannot expect a non-compilable copy constructor to be optimized out owing to RVO/NRVO and hence compile fine. That is just wrong. The compiler has to pass the code for semantic validity. The C++ standard lays down the rules around the syntax of a valid C++ program and it must be respected by a conforming compiler. If a particular construct is ill-formed, the compiler may or may not proceed ahead. It would not generate the compiled code though, as the application has ill-formed C++, but it may proceed with the compilation in order to accumulate other errors that might be caught. Imagine a compiler that stopped compiling at the occurence of the very first error. It would make the compilation task so much more repeatative. Not that the following errors are always relevant to different errors but it helps.

Anyways, back to the topic - it came out to be a non-standard extension. Vendors can provide non-standard extensions as the standard allows it. Here is what the standard has to say around non-standard extensions [section : 1.4 (8)]:

"A conforming implementation may have extensions (including additional library functions), provided they do not alter the behavior of any well-formed program. Implementations are required to diagnose programs that use such extensions that are ill-formed according to this International Standard. Having done so, however, they can compile and execute such programs."

And this extension (that violates the standards rule directly) actually fulfils the above except that the diagnostic (error or warning) is not there until a warning level 4.

Here are some additional relevant quotes from the standards [section : 1.4 (2)]:

Although this International Standard states only requirements on C++ implementations, those requirements are often easier to understand if they are phrased as requirements on programs, parts of programs, or execution of programs. Such requirements have the following meaning:

    — If a program contains no violations of the rules in this International Standard, a conforming implementation shall, within its resource limits, accept and correctly execute that program.

    — If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this Standard as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message, except that

    — If a program contains a violation of a rule for which no diagnostic is required, this International Standard places no requirement on implementations with respect to that program.

This extension falls in the second category mentioned above in that it violates the rules of the IS and the IS does not suggest "no diagnosis required". So, the compiler becomes conforming around this extension at warning level 4 but non-conforming at less stricted levels. My recommendation is to never use this extension. If you are going to modify an object, making a named copy of it, would suffice.

References: Codeguru thread - Binding a temporary to a reference to non-const

Custom deleters with smart pointers

2007-05-07T10:30:00.001+05:30

There is just one smart pointer as part of the standard C++ library as of now (excluding the tr1 and proposals). That is the std::auto_ptr.

It is crucial to know that you can only use it for allocations made via the new operator. It neither handles, the allocations made via the array form of new or malloc or any other allocation routine provided, for that matter.

How can you extend it to be able to use it with those? Basically, you can't. There are an option though - you lay down your own version of auto_ptrs specific to those which have the delete call replaced by free/delete[]/or the relevant deleter. This will ask for writing down multiple classes for them and using them as appropriate. There is another way to extend it but before that let's look at how boost::shared_ptr handles it.

Boost shared_ptr has a concept for a custom deleter. The deleter would operate on the pointer (when the reference count drops to 0 - remembers the ownership is shared!) and the effect should be that of freeing the resource. The following is an illustration:

[CODE]

template<typename T>
struct mallocDeleter
{
    void operator() (T*& ptr)
    {
        if (ptr)
        {
            free(ptr);
            ptr=NULL;
        }
    }
};
void somefunction()
{
    MyType* ptr = getAllocatedPointer();//returns pointer to memory allocated by malloc
    shared_ptr<MyType, mallocDeleter<MyType> >object(ptr, mallocDeleter());
}

//scope ends shared_ptr's destructor gets called that then called mallocDeleter(ptr) - The default deleter is "delete".

Notice, how this expresses the flexibility. You could have acquired any other resource and would have wrapped it inside a shared_ptr and would provide the deleter to free that resource. For example, a File Handle - on which the custom deleter calls close (for C++ fstream objects, you don't need that - they already exploit RAII). Or, a db connection handle, for which the deleter would handle closing it. Just about anything that is manually allocated! Amazing how the ability to provide the deleter makes this smartness so generic.

I wonder why the auto_ptr or the boost scoped_ptr don't provide this ability. RAII is truely magic and takes care of resource leak issues so well.

Cheers!