Partial const on struct

[muse1987]

Hi. I have a problem with const data types. I have a template structure named pair

template <class K, class V>
struct pair
{
	K key;
	V value;

	pair() : key(), value() {}
	pair( K const& k, V const& v ) : key(k), value(v) {}
};

Then, I wanted to declare a variable where only 'key' member is constant. So I wrote

pair<int const, int> X;

The problem is, I can't assign pair<int, int> to that variable. So I changed the structure like this

template <class K, class V>
struct pair
{
	K key;
	V value;

	pair() : key(), value() {}
	pair( K const& k, V const& v ) : key(k), value(v) {}

	operator pair<K const, V> const& () const
		{ return *reinterpret_cast<pair<K const, V> const*>(this); }

	operator pair<K const, V>& ()
		{ return *reinterpret_cast<pair<K const, V>*>(this); }
};


pair<int, int> P;
pair<int const, int>& X = P;	// Now I can do this

My question is : Is this regular way? And if not, what would be better? So far I tried to avoid reinterpret_cast as long as possible.

Any information would be much appreciated.
Thanks

[souldog]

ahh.... std::pair

[souldog]

and declaring the key member constant means you can not change it so you can not assign it. That is what it means to be constant. Did you mean to implement a copy constructor? In which case you could use a template copy constructor just like std:air does

template <class K, class V>
struct pair
{
	K key;
	V value;

	pair() : key(), value() {}
	pair( K const& k, V const& v ) : key(k), value(v) {}
 	template <class _U1, class _U2>
 	pair(const pair<_U1, _U2>& p) : key(p.key), value(p.value) {}
};

[muse1987]

and declaring the key member constant means you can not change it so you can not assign it. That is what it means to be constant. Did you mean to implement a copy constructor? In which case you could use a template copy constructor just like std:air does

Thanks for your information. Actually I need to pass the variable to function. The function can change value, but not key.

template <class K, class V>
void func( pair<K const, V>& );

.....
pair<int, int> X;
func( X );

But if I make copy constructor instead, I cannot pass X as reference.

Moreover, I want

template <class K, class V>
void func( pair<K const, V>* pArray, int Count );

.....
pair<int, int> X[100];
func( X, 100 );  // <---- error, but I want to do this

I think copy constructor doesn't benefit in this case as it will have to copy the entire array.

I hope you understand my needs.
Thanks

[souldog]

is there some reason why you don't just use a std::map?

[muse1987]

is there some reason why you don't just use a std::map?

It's a long story. When I was learning C++, I implemented common data structures using templates, for learning purpose. Unfortunately I didn't delete them. I kept using those classes and felt "proud". As I already attached myself to them so much, I continued updating it. Well, I think my classes aren't too bad, though they may not replace STL. There're some neat features also. For example, my map classes can be treated as collection of pair of (key, value). Thus they can be converted to array (my version of std::vector) or list by one-line code.

hash_map<ansi_string, int> Map;

... ... ...
array< map_pair<ansi_string, int> > Array ( Map );

And also, it has keySet() and valueSet() functions, which makes it possible to iterate key/value individually.

hash_map<int, int> Map;

... ... ...
array< ansi_string > Array ( Map.keySet() );

The collection classes can be joined together, to form more complex collections. (I call it "collection family") For example, hash_map's declaration looks like this

template <
	class _key_,
	class _val_,
	u32 _tblsize_		= 16,
	class _base_family_	= linear_map_family<list_family>,
	class _func_		= default_hash_func<_key_>,
	class _alloc_		= cDefaultAllocator
>
class hash_map

Here, if I change list_family into array_family, then the hash map will be storing collision entries in vector-style rather than list-style.

...

Now the problem arises : to treat map as collection of (key, value), I need to force the key not changed. My current solution works somehow, but I'd like to avoid reinterpret_cast if possible.

And by the way, I have an impression that sets are special case of map, of which value type is 'void'. I'd like to hear advices on it also.

Thanks

[Paul McKenzie]

It's a long story. When I was learning C++, I implemented common data structures using templates, for learning purpose. Unfortunately I didn't delete them. I kept using those classes and felt "proud". As I already attached myself to them so much, I continued updating it.

The bad part is that not learning STL containers properly hinders your development in learning C++. Not only that, lack of knowledge of STL containers, algorithms, iterators, etc. severly limits you in terms of employment in a C++ position.

As to your general question, why not look at how the STL containers are implemented?

Well, I think my classes aren't too bad, though they may not replace STL.

I see no iterators or algorithms. Therefore it comes well short of what the STL offers.

There're some neat features also. For example, my map classes can be treated as collection of pair of (key, value). Thus they can be converted to array (my version of std::vector) or list by one-line code.

The same can be done with STL using iterators.

#include <map>
#include <vector>
#include <string>

using namespace std;

int main()
{
    map<string, int> StringMap;
    //...
    vector<pair<string, int> > Vect(StringMap.begin(),  StringMap.end());
}

And by the way, I have an impression that sets are special case of map, of which value type is 'void'. I'd like to hear advices on it also.

You have STL containers already coded with full source. You can see how they're implemented.

Regards,

Paul McKenzie

[muse1987]

The bad part is that not learning STL containers properly hinders your development in learning C++. Not only that, lack of knowledge of STL containers, algorithms, iterators, etc. severly limits you in terms of employment in a C++ position.

I totally agree with that. That's what I say "unfortunate". I heard people saying "If you don't know STL, you don't know C++". So I don't know C++? lol
Umm, however, now I know a little about STL, though not quite and not using as much as others do. So I can say I know C++ a little, can't I?

BTW, the thing is, my occupation is Java programmer for now, though I know much less in Java than I do in C++. Maybe that's another misfortune.

As to your general question, why not look at how the STL containers are implemented?

I'm looking over the damned complicated STL implementation. I'm asking here if there was no answer...

I see no iterators or algorithms. Therefore it comes well short of what the STL offers.

I'm not sure what you're saying. My classes do have iterators. I thought it's fundamental in collections.

The same can be done with STL using iterators.
...

Right. Well, keySet() and valueSet() can be implemented by trivial code as well. I regret that STL map doesn't support that function while Java does.


Also, I regret that no C++ book written in my language was telling about STL when I was learning C++.

Thanks for your information.

[Paul McKenzie]

I'm not sure what you're saying. My classes do have iterators. I thought it's fundamental in collections.

Iterators in terms of STL means that you can apply operations such as ++, --, +=, -=, etc. to get to certain elements in the container. This allows generic algorithms to be coded that iterate through any container supporting these operators. Even if the container is a plain old array, they work using the iterator concept as described by STL.

Since I don't know the rest of your code, if you're talking about functions called something like "nextInMap" or "gotoElement", then these are not iterators, at least in the sense that an STL algorithm defines an iterator. They would be part of the iterator mechanism, but to make them true iterators, they need to be wrapped with the apppropriate operators (++, --, etc.)

Regards,

Paul McKenzie

[muse1987]

Oh I see. In my case, there're 2 types of iterators, one unwrapped and one wrapped. So it' OK ->

[Peter_APIIT]

The constant declaration look weird to me at least.

const Fred* const p.

[JohnW@Wessex]

p is a constant pointer that points to a constant value.
Neither can be changed.

[Peter_APIIT]

I learn something.

Pair can be downgrade to less specialize version which is vector or array like.

By the way, how there achieved this ?

Thanks for your help.