[Kde-bindings] Smoke TypeFlags in types

[Richard Dale]

On Saturday 15 August 2009 07:19:48 pm Petr Vanek wrote:
> hi all,
>
> question about Smoke TypeFlags: There is a doc comment: "Always only
> one of the next three flags should be set" for tf_stack, tf_ptr, tf_ref.
>
> But when I list types with a sample for-loop I'm getting.
> QObject::qt_metacall (QMetaObject::Call STACK REF, int STACK REF,
> void** PTR REF)
> QObject::QObject (QObject* PTR REF)
> etc.
>
> It does not make too much sense to me. Or is it only my
> misunderstanding of meanings of these flags?
>
>
> sample code is just a slightly modified techbase example
>          std::string name;
>          Smoke::Index *idx = qt_Smoke->argumentList + method.args;
>          while (*idx) {
>              name += qt_Smoke->types[*idx].name;
>              if (qt_Smoke->types[*idx].flags & Smoke::tf_stack) name
> += " STACK";
>              if (qt_Smoke->types[*idx].flags & Smoke::tf_ptr) name +=
> " PTR";
>              if (qt_Smoke->types[*idx].flags & Smoke::tf_ref) name +=
> " REF";
>              idx++;
>              if (*idx) name += ", ";
>          }
>          std::cout << m_class.className << "::" << methodName << " ("
> << name << ")" << std::endl;
As we discussed on irc yesterday, this is a problem with the way you are 
interpreting the bits set for the three options. If anyone else is confused by 
how it works, I'll explain a bit. The type flags are defined like this in 
smoke.h:

    enum TypeFlags {
        // The first 4 bits indicate the TypeId value, i.e. which field
        // of the StackItem union is used.
        tf_elem = 0x0F,

	// Always only one of the next three flags should be set
	tf_stack = 0x10, 	// Stored on the stack, 'type'
	tf_ptr = 0x20,   	// Pointer, 'type*'
	tf_ref = 0x30,   	// Reference, 'type&'
	// Can | whatever ones of these apply
	tf_const = 0x40		// const argument
    };

So if a TypeFlags value has tf_ref is set to 0x30, the bit pattern will be 
0011 0000, which means that it will have the bits set for both the tf_stack 
(0001 0000) and tf_ptr (0010 0000) options. But that doesn't mean a tf_ref is 
always both a tf_stack and a tf_ptr because you aren't supposed to interpret 
the indiividual bits to mean that. So if you test first for a tf_ref and find 
one, you can assume you don't need to look for tf_stack or tf_ptr.

std::string name;
Smoke::Index *idx = qt_Smoke->argumentList + method.args;
while (*idx) {
  name += qt_Smoke->types[*idx].name;
  if ((qt_Smoke->types[*idx].flags & Smoke::tf_ref) == Smoke::tf_ref) {
    name +=  " REF";
  } else if (qt_Smoke->types[*idx].flags & Smoke::tf_stack) {
    name += " STACK";
  } else if (qt_Smoke->types[*idx].flags & Smoke::tf_ptr) {
    name += " PTR";
  }
  dx++;
  if (*idx) name += ", ";
}
td::cout << m_class.className << "::" << methodName << " (" << name << ")" << 
std::endl;

-- Richard