isConst - Loki

[skscpp]

I copied this from several sources online. Why doesn't it work?

// ================================================================
#include <iostream>

using namespace std;

namespace utl
{
template <typename T>
class TypeTraits
{
private:
template<class U>
struct UnConst
{
typedef U Result;
enum { isConst = false };
};

template<class U>
struct UnConst<const U>
{
typedef U Result;
enum { isConst = true };
};

public:

enum { isConst = UnConst<T>::isConst };
};
}

class Object
{
public:
Object(int a) { i = a; }
int i;
};

int main()
{
Object test(10);
const Object* t = &test;

if ( utl::TypeTraits<const Object*>::isConst )
cout << "Hooray - it's a const \n";
else
cout << "It's NOT a const \n";

if ( utl::TypeTraits<Object*>::isConst )
cout << "it's a const \n";
else
cout << "Hooray - It's NOT a const \n";

cout << endl;
}

// ================================================================


Here is the output:

It's NOT a const
Hooray - It's NOT a const

 

[Andrey Tarasevich]

I copied this from several sources online. Why doesn't it work?
...
int main()
{
Object test(10);
const Object* t = &test;

if ( utl::TypeTraits<const Object*>::isConst )
cout << "Hooray - it's a const \n";
else
cout << "It's NOT a const \n";

if ( utl::TypeTraits<Object*>::isConst )
cout << "it's a const \n";
else
cout << "Hooray - It's NOT a const \n";

cout << endl;
}
...
Here is the output:

It's NOT a const
Hooray - It's NOT a const

"Doesn't work"? Where? I don't seen any problems with it. Neither 'const
Object*' nor 'Object*' is 'const' type so the output should be 'It's NOT
a const' in both cases. That's exactly what you got.

 

[sks_cpp]

If you consistently refrain from placing 'const' in front of the
type name, which is a special case syntax, then you'll probably not
get confused about this again.

How is that a special case syntax? In other words, what is that special
case?

So I should always use:
Object const * (pointer to constant object)
OR
Object * const (const pointer to object)

 

[Kevin Wan]

I copied this from several sources online. Why doesn't it work?

// ================================================================
#include <iostream>

using namespace std;

namespace utl
{
template <typename T>
class TypeTraits
{
private:
template<class U>
struct UnConst
{
typedef U Result;
enum { isConst = false };
};

template<class U>
struct UnConst<const U>
{
typedef U Result;
enum { isConst = true };
};

public:

enum { isConst = UnConst<T>::isConst };
};
}

class Object
{
public:
Object(int a) { i = a; }
int i;
};

int main()
{
Object test(10);
const Object* t = &test;

if ( utl::TypeTraits<const Object*>::isConst )
cout << "Hooray - it's a const \n";
else
cout << "It's NOT a const \n";

if ( utl::TypeTraits<Object*>::isConst )
cout << "it's a const \n";
else
cout << "Hooray - It's NOT a const \n";

cout << endl;
}

// ================================================================


Here is the output:

It's NOT a const
Hooray - It's NOT a const

Try the following, you'll get a const!

if ( utl::TypeTraits<Object * const>::isConst )
cout << "Hooray - it's a const \n";
else
cout << "It's NOT a const \n";

 

[Shane Beasley]

Special case is allowing 'const' before type:

const int a;

is allowed along with more proper

int const a;

"Proper" makes it sound like the latter is objectively better than the
former. Where to put "const" is just as much a style issue as where to
put curly braces, the most significant byte, the big end of the egg,
etc.

I still look at "int const a;" funny. There's nothing inherently wrong
with it, I understand what it means, and I know that "right-constians"
do it that way in an attempt to mimic the way C++ seems to interpret
it (right-to-left). However, it's not my style, and it wouldn't
improve my ability to read or write C++ or the compiler's ability to
interpret and translate it.

Beyond understanding the difference between "before *" and "after *",
it really doesn't matter what order specifiers come in. Really.

That's one of the causes of confusion among those who haven't
got used to reading declarations.

I think the confusion is almost entirely the result of C declarator
syntax, described by Stroustrup as an "experiment that failed." Since
we're stuck with what we've got, and a *lot* of code which takes
advantage of what we've got, the only viable solution is to get used
to reading it.

- Shane