Alf P. Steinbach wrote:
* Steven T. Hatton:
>This is not a big deal. It just bothers me that I don't see a way around
including the header for QVariant in the following:
#ifndef _XML_IMPL_INTER NAL_H_
#define _XML_IMPL_INTER NAL_H_
class QString;
class QVariant;
namespace xml_impl {
void unknownType(con st QString& functionName, const QVariant::Type&
type); void ni(const QString& functionName);
}
#endif
/*************** **************
* compiler error messages
../../include/xml_impl/xml_impl_intern al.h:7: error: expected
unqualified-id before ?&? token
../../include/xml_impl/xml_impl_intern al.h:7: error: expected ?,? or
?...? before ?&? token
../../include/xml_impl/xml_impl_intern al.h:7: error: ISO C++ forbids
declaration of ?parameter? with no type
************** ***************/
Is there any way to get around providing the definition of QVariant::Type
prior to the function declaration?
Assuming it's your own thing, just do
Sorry, after I sent the message I realized I had not been very clear about
the situation. QVariant is a class in Qt. It's kind of like an OO
extension of a union that uses a type property to communicate it's content
type. The variable of type QVariant::Type I was trying to pass is
actualized by one of the enumerators.
Here's the doc on QVariant if you happen to be interested:
http://doc.trolltech.com/4.2/qvariant.html
class QVariantType;
and in your function (which smells of non-OO)
You are quite perceptive. I have a stateless translator function which has
no legitimate reason to be in a class. I put it and it's cousins in a
small namespace, and exposed it through an interface namespace.
http://bridgewater.wordpress.com/200...nguage-item-1/
void unknownType(
QString const& functionName, QVariantType const& type
);
and wherever you're definining class QVariant
class QVariantType { ... };
class QVariant
{
public:
typedef QVariantType Type;
};
Something crossed my mind today, but I'm not sure I should really admit I
entertained the notion. Following Peano one might construct enumerated
types as
struct Integer{};
struct Zero: public Integer{};
struct One: public Zero{};
struct Two: public One{};
....
struct NPlusOne: public N{};
That, in itself weighs nothing at runtime because there are no virtual
functions. OTOH, the ordering is lost at runtime. It has the advantage
over enumerations that you cannot use a value you have not explicitly
specified. One could do something similar to what Robe did with r++
http://websvn.kde.org/branches/work/...25&view=markup
And for grins you could even throw in a static const char* so you could dump
the name if you needed it for something like an XML builder.
Yet another option might be to use template metaprogramming to recursively
enumerate the items. Yet another would be to do some kind of
initialization at load time assigning the value of an incremented counter
to each instance sequentially. Why don't I like enums? Mostly because the
aren't really enumerations.
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath.
www.bartleby.com/61/ 
