@m_magalhaes
I agree that the last few replies to this thread are C++ and not SDK related.
The main topic lead to the HashSet, and for completeness of future reference I thought to mention the compiling issues.
I didn't know about the difference being the iterator initialization. To me it all looked the same.

Just for completeness, I never really realized the following two implementations had a complete different internal behaviour:

	// does compile
	maxon::HashSet<Int32>::Iterator it = hashset.Begin();

	// does not compile
	maxon::HashSet<Int32>::Iterator it;
	it = hashset.Begin();

I will set the topic as solved, since HashSet is the way to go, and I learned something new about iterator initialization in the process.

@m_magalhaes
Thanks for reminding me of the "auto" ...

Yesterday I had tried using the iterator, but got compiler error, then I tried the range-based loop, again hitting a compiler error.

I don't quite get the difference between following two implementations

	maxon::HashSet<Int32>::Iterator it;
	for (it = hashset.Begin(); it != hashset.End(); ++it)
		GePrint("HashSet value " + String::IntToString(*it));

	for (auto it = hashset.Begin(); it != hashset.End(); ++it)
		GePrint("HashSet value " + String::IntToString(*it));

The first implementation (which I tried using ... not thinking about using "auto") gives me following errors:

error C2512: 'maxon::HashSet<Int32,maxon::DefaultHash,maxon::DefaultAllocator>::Iterator': no appropriate default constructor available

error C2248: 'maxon::HashSet<Int32,maxon::DefaultHash,maxon::DefaultAllocator>::Iterator::operator =': cannot access private member declared in class 'maxon::HashSet<Int32,maxon::DefaultHash,maxon::DefaultAllocator>::Iterator'

I am confused that using "auto" does work.
Especially that when hovering over "auto" in Visual Studio does show a popup, containing "class maxon::HashSet<Int32>::Iterator" ... exactly what the first implementation does.

@m_magalhaes said in Getting the State of Modifier Keys (ctrl/cmd, shift, alt):

Regarding the pre-R20 and r20 code i don't have any idea instead that storing bool in a bool (0 or 1) make more sense.
In your code pre-R20 you were sending value > 1 to a bool

I see, I got it all wrong all those years.
My implementation came from reading the examples users posted on the forum (now the legacy forum).
Most uses of modifiers keys were checking inside an if-statement, as such I assumed I could move the checking outside of the if and assign it to a Bool instead, to then check on multiple locations in a function.

Here's an example found in the legacy forum

On 06/09/2005 at 12:55, xxxxxxxx wrote:

Hi

the qualifiers are combined bitwise. So you can check each one by

if( key&QSHIFT; )
{
// shift down
}
if( key&CTRL; )
{
// ctrl down
}
..

Notice the original message is full of typos, but the idea is what it is. Similar solutions have been posted since, all with this same idea ... that's where I got the bad habit from.
Thanks for clarifying the use. Will try to remember it for future plugins.

@m_magalhaes
Hi,
HashSet seems indeed what I need. From the name I assumed its functionality was similar to std::set which is not what I wanted. But I have tested out HashSet in R20 and it does provide the result I was looking for.
Unfortunately, I could not get to compile the test in R19.
The Insert() function in R20 was to be replaced by an Add(), no problems there.
But iterating (using iterator or range based loop) does not compile, as it seems the iterators are derived privately from the base class HashMap

error C2247: 'maxon::HashMap<V,maxon::EmptyClass,HASH,maxon::HashMapKeyValuePair,ALLOCATOR>::begin' not accessible because 'maxon::HashSet<Int32,maxon::DefaultHash,maxon::DefaultAllocator>' uses 'private' to inherit from 'maxon::HashMap<V,maxon::EmptyClass,HASH,maxon::HashMapKeyValuePair,ALLOCATOR>'
```.

Not sure if I am right, but I think something changed in R20 (at least for C++).
These are 2 code snippets of the same functionality in one of my plugins, which had to be changed in R20 to make it work as expected. Again ... not sure if this applies to Python.

pre-R20

	BaseContainer channels;
	GetInputState(BFM_INPUT_KEYBOARD, BFM_INPUT_CHANNEL, channels);
	Bool shiftModifier = channels.GetInt32(BFM_INPUT_QUALIFIER) & QSHIFT;
	Bool ctrlModifier = channels.GetInt32(BFM_INPUT_QUALIFIER) & QCTRL;

R20

	BaseContainer channels;
	GetInputState(BFM_INPUT_KEYBOARD, BFM_INPUT_CHANNEL, channels);
	Bool shiftModifier = (channels.GetInt32(BFM_INPUT_QUALIFIER) & QSHIFT) != 0;
	Bool ctrlModifier = (channels.GetInt32(BFM_INPUT_QUALIFIER) & QCTRL) != 0;

I am looking for a storage type which would allow me to hold a sequence of values, but would avoid duplicate values.
I was originally looking at BaseArray but when appending a new value I would like to avoid iterating over all entries to find out if this new value is already present.
An HashMap doesn't preserve the order of items being inserted (as far as I know).
As such I was more thinking about a custom class containing:

• a BaseArray to hold the values in the order they are appended.
• an HashMap to hold the values (as key) in order to perform an easy Find, knowing if the value should be appended or not.

But having the values stored twice this would mean this custom class takes up twice the memory.
Since I intend to share implementation between R20 and pre-R20 I cannot rely on the new maxon::Data or maxon::DataDictionnary.

Anyone having a better idea than the BaseArray-HashMap combination?
The storage type should be able to handle any type of data, from Int32, Float, Strings, custom class instances, ...

Example with Int32:
input = 0, 1, 2, 0, 3, 1, 5, 4
The data storage should hold:
0, 1, 2, 3, 5, 4

@r_gigante
Thanks for the headsup about FindOrCreateEntry.
Since Put does use that method internally, I didn't even consider about trying to use it, as I simply assumed it would have the same issue. Guess I was wrong about not trying it.

Problem solved.

With R20 I had no problem using a HashMap with a BaseArray<Int32> as value. All compiling fine, and working as expected.
Porting that implementation to R19 (for users having not upgraded to R20), I encounter a compiler error, mentioning that the operator= cannot be accessed, since private.
Obviously, I had to replace the R20 HashMap::Insert for an R19 HashMap::Put and there seems to lie the problem

	// key is an integer and value an array of integers
	maxon::HashMap<Int32, maxon::BaseArray<Int32>> dataKeyValue;

	const Int32 key = 1;

	maxon::HashMap<Int32, maxon::BaseArray<Int32>>::Entry* e = dataKeyValue.FindEntry(key);
	if (e)
	{
		maxon::BaseArray<Int32>& values = e->GetValue();

		// ...
	}
	else
	{
		maxon::BaseArray<Int32> newValues;
		
		// ...
		
		dataKeyValue.Put(key, newValues);
	}

The compiler error:

error C2248: 'maxon::BaseArray<Bool,16,maxon::BASEARRAYFLAGS_0,maxon::DefaultAllocator>::operator =': cannot access private member declared in class 'maxon::BaseArray<Bool,16,maxon::BASEARRAYFLAGS_0,maxon::DefaultAllocator>'

Any hint what I could do in order to have the same functionality compiled in R19?
Thanks in advance.

Only thing I have to add is that when trying out the provided example code I removed the double const in the static function declaration.

From:

static Bool BaseContainerCompare(const BaseContainer& const bc1, const BaseContainer& const bc2)

To:

static Bool BaseContainerCompare(const BaseContainer& bc1, const BaseContainer& bc2)

as the original line resulted in a:

warning C4227: anachronism used: qualifiers on reference are ignored

The geometry of an object is stored in hidden tags (points and polygons, namely)
These are not visible, nor selectable ... and thus can theoretically not be deleted by user. But you still can access these via Python, or C++. As such, when removing all tags you also remove critical ones, that are needed by the object in order to exist.