.TH "kdb::Key" 3elektra "Sun May 29 2016" "Version 0.8.14" "Elektra" \" -*- nroff -*- .ad l .nh .SH NAME kdb::Key \- \fBKey\fP is an essential class that encapsulates key \fBname \fP, \fBvalue \fP and \fBmetainfo \fP\&. .SH SYNOPSIS .br .PP .PP \fC#include \fP .SS "Public Member Functions" .in +1c .ti -1c .RI "\fBKey\fP ()" .br .RI "\fIConstructs an empty, invalid key\&. \fP" .ti -1c .RI "\fBKey\fP (ckdb::Key *k)" .br .RI "\fIConstructs a key out of a C key\&. \fP" .ti -1c .RI "\fBKey\fP (\fBKey\fP &k)" .br .RI "\fITakes a reference of another key\&. \fP" .ti -1c .RI "\fBKey\fP (\fBKey\fP const &k)" .br .RI "\fITakes a reference of another key\&. \fP" .ti -1c .RI "\fBKey\fP (const char *\fBkeyName\fP,\&.\&.\&.)" .br .RI "\fIA practical way to fully create a \fBKey\fP object in one step\&. \fP" .ti -1c .RI "\fBKey\fP (const std::string \fBkeyName\fP,\&.\&.\&.)" .br .RI "\fIA practical way to fully create a \fBKey\fP object in one step\&. \fP" .ti -1c .RI "\fBKey\fP (const char *\fBkeyName\fP, va_list ap)" .br .RI "\fIA practical way to fully create a \fBKey\fP object in one step\&. \fP" .ti -1c .RI "void \fBoperator++\fP (int) const " .br .RI "\fIIncrement the viability of a key object\&. \fP" .ti -1c .RI "void \fBoperator++\fP () const " .br .RI "\fIIncrement the viability of a key object\&. \fP" .ti -1c .RI "void \fBoperator\-\-\fP (int) const " .br .RI "\fIDecrement the viability of a key object\&. \fP" .ti -1c .RI "void \fBoperator\-\-\fP () const " .br .RI "\fIDecrement the viability of a key object\&. \fP" .ti -1c .RI "ssize_t \fBgetReferenceCounter\fP () const " .br .RI "\fIReturn how many references the key has\&. \fP" .ti -1c .RI "\fBKey\fP & \fBoperator=\fP (ckdb::Key *k)" .br .RI "\fIAssign a C key\&. \fP" .ti -1c .RI "\fBKey\fP & \fBoperator=\fP (const \fBKey\fP &k)" .br .RI "\fIAssign a key\&. \fP" .ti -1c .RI "void \fBcopy\fP (const \fBKey\fP &other)" .br .RI "\fICopy or Clear a key\&. \fP" .ti -1c .RI "void \fBclear\fP ()" .br .RI "\fIClears/Invalidates a key\&. \fP" .ti -1c .RI "\fBKey\fP * \fBoperator\->\fP ()" .br .ti -1c .RI "ckdb::Key * \fBgetKey\fP () const " .br .RI "\fIPasses out the raw key pointer\&. \fP" .ti -1c .RI "ckdb::Key * \fBoperator*\fP () const " .br .RI "\fIIs a abbreviation for getKey\&. \fP" .ti -1c .RI "ckdb::Key * \fBrelease\fP ()" .br .RI "\fIPasses out the raw key pointer and resets internal key handle\&. \fP" .ti -1c .RI "ckdb::Key * \fBdup\fP () const " .br .RI "\fIReturn a duplicate of a key\&. \fP" .ti -1c .RI "\fB~Key\fP ()" .br .RI "\fIDestructs the key\&. \fP" .ti -1c .RI "std::string \fBgetName\fP () const " .br .RI "\fIReturns a pointer to the abbreviated real internal \fCkey\fP name\&. \fP" .ti -1c .RI "ssize_t \fBgetNameSize\fP () const " .br .RI "\fIBytes needed to store the key name without owner\&. \fP" .ti -1c .RI "std::string \fBgetBaseName\fP () const " .br .RI "\fIReturns a pointer to the internal unescaped key name where the \fCbasename\fP starts\&. \fP" .ti -1c .RI "ssize_t \fBgetBaseNameSize\fP () const " .br .RI "\fICalculates number of bytes needed to store basename of \fCkey\fP\&. \fP" .ti -1c .RI "void \fBsetName\fP (const std::string &newName)" .br .RI "\fISet a new name to a key\&. \fP" .ti -1c .RI "void \fBsetBaseName\fP (const std::string &baseName)" .br .RI "\fISets a base name for a key\&. \fP" .ti -1c .RI "void \fBaddBaseName\fP (const std::string &baseName)" .br .RI "\fIAdds a base name for a key\&. \fP" .ti -1c .RI "ssize_t \fBgetFullNameSize\fP () const " .br .RI "\fIBytes needed to store the key name including user domain and ending NULL\&. \fP" .ti -1c .RI "std::string \fBgetFullName\fP () const " .br .RI "\fIGet key full name, including the user domain name\&. \fP" .ti -1c .RI "bool \fBoperator==\fP (const \fBKey\fP &k) const " .br .RI "\fICompare the name of two keys\&. \fP" .ti -1c .RI "bool \fBoperator!=\fP (const \fBKey\fP &k) const " .br .RI "\fICompare the name of two keys\&. \fP" .ti -1c .RI "bool \fBoperator<\fP (const \fBKey\fP &other) const " .br .RI "\fICompare the name of two keys\&. \fP" .ti -1c .RI "bool \fBoperator<=\fP (const \fBKey\fP &other) const " .br .RI "\fICompare the name of two keys\&. \fP" .ti -1c .RI "bool \fBoperator>\fP (const \fBKey\fP &other) const " .br .RI "\fICompare the name of two keys\&. \fP" .ti -1c .RI "bool \fBoperator>=\fP (const \fBKey\fP &other) const " .br .RI "\fICompare the name of two keys\&. \fP" .ti -1c .RI "bool \fBisNull\fP () const " .br .RI "\fIChecks if C++ wrapper has an underlying key\&. \fP" .ti -1c .RI "\fBoperator bool\fP () const " .br .RI "\fIThis is for loops and lookups only\&. \fP" .ti -1c .RI "bool \fBneedSync\fP () const " .br .RI "\fITest if a key needs to be synced to backend storage\&. \fP" .ti -1c .RI "template T \fBget\fP () const " .br .RI "\fIGet a key value\&. \fP" .ti -1c .RI "template void \fBset\fP (T x)" .br .RI "\fISet a key value\&. \fP" .ti -1c .RI "std::string \fBgetString\fP () const " .br .ti -1c .RI "void \fBsetString\fP (std::string newString)" .br .RI "\fISet the value for \fCkey\fP as \fCnewStringValue\fP\&. \fP" .ti -1c .RI "ssize_t \fBgetStringSize\fP () const " .br .RI "\fIReturns the number of bytes needed to store the key value, including the NULL terminator\&. \fP" .ti -1c .RI "func_t \fBgetFunc\fP () const " .br .RI "\fIElektra can store function pointers as binary\&. \fP" .ti -1c .RI "const void * \fBgetValue\fP () const " .br .RI "\fIReturn a pointer to the real internal \fCkey\fP value\&. \fP" .ti -1c .RI "std::string \fBgetBinary\fP () const " .br .RI "\fIGet the value of a key as a binary\&. \fP" .ti -1c .RI "ssize_t \fBgetBinarySize\fP () const " .br .RI "\fIReturns the number of bytes needed to store the key value, including the NULL terminator\&. \fP" .ti -1c .RI "ssize_t \fBsetBinary\fP (const void *newBinary, size_t dataSize)" .br .RI "\fISet the value of a key as a binary\&. \fP" .ti -1c .RI "bool \fBhasMeta\fP (const std::string &metaName) const " .br .ti -1c .RI "template T \fBgetMeta\fP (const std::string &metaName) const " .br .RI "\fIReturns the Value of a Meta-Information given by name\&. \fP" .ti -1c .RI "template void \fBsetMeta\fP (const std::string &metaName, T x)" .br .RI "\fISet metadata for key\&. \fP" .ti -1c .RI "void \fBdelMeta\fP (const std::string &metaName)" .br .RI "\fIDelete metadata for key\&. \fP" .ti -1c .RI "void \fBcopyMeta\fP (const \fBKey\fP &other, const std::string &metaName)" .br .RI "\fIDo a shallow copy of meta data from source to dest\&. \fP" .ti -1c .RI "void \fBcopyAllMeta\fP (const \fBKey\fP &other)" .br .RI "\fIDo a shallow copy of all meta data from source to dest\&. \fP" .ti -1c .RI "void \fBrewindMeta\fP () const " .br .RI "\fIRewind the internal iterator to first meta data\&. \fP" .ti -1c .RI "const \fBKey\fP \fBnextMeta\fP ()" .br .RI "\fIIterate to the next meta information\&. \fP" .ti -1c .RI "const \fBKey\fP \fBcurrentMeta\fP () const " .br .RI "\fIReturns the Value of a Meta-Information which is current\&. \fP" .ti -1c .RI "bool \fBisValid\fP () const " .br .ti -1c .RI "std::string \fBgetNamespace\fP () const " .br .ti -1c .RI "bool \fBisSystem\fP () const " .br .RI "\fIName starts with 'system'\&. \fP" .ti -1c .RI "bool \fBisUser\fP () const " .br .RI "\fIName starts with 'user'\&. \fP" .ti -1c .RI "bool \fBisString\fP () const " .br .RI "\fICheck if a key is string type\&. \fP" .ti -1c .RI "bool \fBisBinary\fP () const " .br .RI "\fICheck if a key is binary type\&. \fP" .ti -1c .RI "bool \fBisInactive\fP () const " .br .RI "\fICheck whether a key is inactive\&. \fP" .ti -1c .RI "bool \fBisBelow\fP (const \fBKey\fP &k) const " .br .RI "\fICheck if the key check is below the key key or not\&. \fP" .ti -1c .RI "bool \fBisBelowOrSame\fP (const \fBKey\fP &k) const " .br .ti -1c .RI "bool \fBisDirectBelow\fP (const \fBKey\fP &k) const " .br .RI "\fICheck if the key check is direct below the key key or not\&. \fP" .in -1c .SH "Detailed Description" .PP \fBKey\fP is an essential class that encapsulates key \fBname \fP, \fBvalue \fP and \fBmetainfo \fP\&. To use it include: .PP .nf #include .fi .PP .PP \fBKey\fP properties are: .IP "\(bu" 2 \fBKey name \fP .IP "\(bu" 2 \fBKey value \fP .IP "\(bu" 2 \fBKey meta data \fP, including but not limited to: .IP " \(bu" 4 \fBKey comment \fP .IP " \(bu" 4 \fBKey owner \fP .IP " \(bu" 4 \fBUID, GID and filesystem-like mode permissions \fP .IP " \(bu" 4 \fBMode, change and modification times \fP .PP .PP .PP \fBABI\fP .RS 4 Due to ABI compatibility, the \fC\fBKey\fP\fP structure is not defined in kdb\&.h, only declared\&. So you can only declare \fCpointers\fP to \fCKeys\fP in your program, and allocate and free memory for them with \fBkeyNew()\fP and \fBkeyDel()\fP respectively\&. .RE .PP \fBReference Counting\fP .RS 4 Every key has its reference counter (see \fBkeyGetRef()\fP for longer explanation) that will be initialized with 0, that means a subsequent call of \fBkeyDel()\fP will delete the key\&. If you append the key to a keyset the reference counter will be incremented by one (see \fBkeyIncRef()\fP) and the key can't be be deleted by a \fBkeyDel()\fP\&. .RE .PP \fB\fP .RS 4 As you can imagine this refcounting allows you to put the \fBKey\fP in your own datastructures\&. It can be a very powerful feature, e\&.g\&. if you need your own-defined ordering or different Models of your configuration\&. .RE .PP This class is an wrapper for an optional, refcounted ckdb::Key\&. It is like an shared_ptr, but the shared_ptr functionality is already within the \fBKey\fP and exposed with this wrapper\&. .PP \fBoptional\fP .RS 4 A key can be constructed with an null pointer, by using \fBKey\fP (static_cast(0)); or made empty afterwards by using \fBrelease()\fP or assign a null key\&. To check if there is an associated managed object the user can use \fBisNull()\fP\&. .RE .PP \fBreferences\fP .RS 4 Copies of keys are cheap because they are only flat\&. If you really need a deep copy, you can use \fBcopy()\fP or \fBdup()\fP\&. If you \fBrelease()\fP an object, the reference counter will stay All other operations operate on references\&. .RE .PP \fBdocumentation\fP .RS 4 Note that the documentation is typically copied from the underlying function which is wrapped and sometimes extended with C++ specific details\&. So you might find C examples within the C++ documentation\&. .RE .PP \fBInvariant:\fP .RS 4 \fBKey\fP either has a working underlying Elektra \fBKey\fP object or a null pointer\&. The \fBKey\fP, however, might be invalid (see \fBisValid()\fP) or null (see \fBisNull()\fP)\&. .RE .PP \fBNote:\fP .RS 4 that the reference counting in the keys is mutable, so that const keys can be passed around by value\&. .RE .PP .SH "Constructor & Destructor Documentation" .PP .SS "kdb::Key::Key ()\fC [inline]\fP" .PP Constructs an empty, invalid key\&. .PP \fBNote:\fP .RS 4 That this is not a null key, so the key will evaluate to true\&. .RE .PP \fBSee also:\fP .RS 4 \fBisValid()\fP, \fBisNull()\fP .RE .PP .SS "kdb::Key::Key (ckdb::Key * k)\fC [inline]\fP" .PP Constructs a key out of a C key\&. .PP \fBNote:\fP .RS 4 If you pass a null pointer here, the key will evaluate to false\&. .RE .PP \fBParameters:\fP .RS 4 \fIk\fP the key to work with .RE .PP \fBSee also:\fP .RS 4 \fBisValid()\fP, \fBisNull()\fP .RE .PP .SS "kdb::Key::Key (\fBKey\fP & k)\fC [inline]\fP" .PP Takes a reference of another key\&. The key will not be copied, but the reference counter will be increased\&. .PP \fBParameters:\fP .RS 4 \fIk\fP the key to work with .RE .PP .SS "kdb::Key::Key (\fBKey\fP const & k)\fC [inline]\fP" .PP Takes a reference of another key\&. The key will not be copied, but the reference counter will be increased\&. .PP \fBParameters:\fP .RS 4 \fIk\fP the key to work with .RE .PP .SS "kdb::Key::Key (const char * keyName, \&.\&.\&.)\fC [inline]\fP, \fC [explicit]\fP" .PP A practical way to fully create a \fBKey\fP object in one step\&. To just get a key object, simple do: .PP .PP .nf Key *k = keyNew(0); // work with it keyDel (k); .fi .PP If you want the key object to contain a name, value, comment and other meta info read on\&. .PP \fBNote:\fP .RS 4 When you already have a key with similar properties its easier to \fBkeyDup()\fP the key\&. .RE .PP You can call it in many different ways depending on the attribute tags you pass as parameters\&. Tags are represented as the \fBkeyswitch_t\fP values, and tell \fBkeyNew()\fP which \fBKey\fP attribute comes next\&. .PP We can also give an empty key name and a KEY_END tag with the same effect as before: .PP .PP .nf Key *k =keyNew("", KEY_END); // Has the same effect as above // work with it keyDel (k); .fi .PP But we can also give the key a proper name right from the start: .PP .PP .nf // Create and initialize a key with a name and nothing else Key *k=keyNew("user/some/example", KEY_END); // work with it keyDel (k); .fi .PP So, \fBkeyNew()\fP allocates memory for a key object and \fBkeyDel()\fP cleans everything up\&. .PP \fBkeyNew()\fP processes the given argument list even further\&. The \fBKey\fP attribute tags are the following: .IP "\(bu" 2 \fBKEY_VALUE\fP .br Next parameter is a pointer to the value that will be used\&. If no \fBKEY_BINARY\fP was used before, a string is assumed\&. .PP .nf // Create and initialize a key with a name and nothing else Key *k=keyNew("user/tmp/ex0", KEY_VALUE, "some data", // set a string value KEY_END); // end of args .fi .PP .IP "\(bu" 2 \fBKEY_SIZE\fP .br Define a maximum length of the value\&. This is only used when setting a binary key\&. .PP .nf // Create and initialize a key with a name and nothing else Key *k=keyNew("user/tmp/ex1", KEY_SIZE, 4, // has no effect on strings KEY_VALUE, "some data", // set a string value KEY_END); // end of args .fi .PP .IP "\(bu" 2 \fBKEY_META\fP .br Next two parameter is a meta name and a meta value\&. See \fBkeySetMeta()\fP\&. .PP .nf Key *k=keyNew("user/tmp/ex3", KEY_META, "comment", "a comment", // with a commet KEY_META, "owner", "root", // and an owner KEY_META, "special", "yes", // and any other meta data KEY_END); // end of args .fi .PP .IP "\(bu" 2 \fBKEY_END\fP .br Must be the last parameter passed to \fBkeyNew()\fP\&. It is always required, unless the \fCkeyName\fP is 0\&. .IP "\(bu" 2 ::KEY_FLAGS .br Bitwise disjunction of flags, which don't require one or more values\&. recommended way to set multiple flags\&. overrides previously defined flags\&. .PP .nf Key *k=keyNew("user/tmp/ex3", KEY_FLAGS, KEY_BINARY | KEY_CASCADING_NAME, // flags KEY_SIZE, 7, // assume binary length 7 KEY_VALUE, "some data", // value that will be truncated in 7 bytes KEY_END); // end of args .fi .PP .IP "\(bu" 2 \fBKEY_BINARY\fP .br Allows one to change the key to a binary key\&. Make sure that you also pass \fBKEY_SIZE\fP before you set the value\&. Otherwise it will be cut off with first \\0 in the string\&. So this flag toggle from \fBkeySetString()\fP to \fBkeySetBinary()\fP\&. If no value (nor size) is given, it will be a NULL key\&. .PP .nf // Create and initialize a key with a name and nothing else Key *k=keyNew("user/tmp/ex2", KEY_BINARY, KEY_SIZE, 4, // now the size is important KEY_VALUE, "some data", // sets the binary value ("some") KEY_END); // end of args .fi .PP .IP "\(bu" 2 ::KEY_CASCADING_NAME allow the name to start with / useful for \fBksLookup()\fP and \fBkdbGet()\fP parent/lookup keys .IP "\(bu" 2 ::KEY_META_NAME allow the name to start with arbitrary namespaces useful to compare with meta keys .PP .PP \fBDeprecated\fP .RS 4 These other flags deprecated and \fBKEY_META\fP should be preferred\&. They remain some time, however, for compatibility: .IP "\(bu" 2 \fBKEY_DIR\fP .br Define that the key is a directory rather than a ordinary key\&. This means its executable bits in its mode are set\&. But even without this option the key can have subkeys\&. See \fBkeySetDir()\fP\&. .IP "\(bu" 2 \fBKEY_OWNER\fP .br Next parameter is the owner\&. See \fBkeySetOwner()\fP\&. .IP "\(bu" 2 \fBKEY_UID\fP, \fBKEY_GID\fP .br Next parameter is taken as the UID (uid_t) or GID (gid_t) that will be defined on the key\&. See \fBkeySetUID()\fP and \fBkeySetGID()\fP\&. .IP "\(bu" 2 \fBKEY_MODE\fP .br Next parameter is taken as mode permissions (int) to the key\&. See \fBkeySetMode()\fP\&. .PP .nf Key *k=keyNew("user/tmp/ex3", KEY_VALUE, "some data", // with a simple value KEY_MODE, 0777, // permissions KEY_END); // end of args .fi .PP .IP "\(bu" 2 \fBKEY_COMMENT\fP .br Next parameter is a comment\&. See \fBkeySetComment()\fP\&. .PP .nf Key *k=keyNew("user/tmp/ex4", KEY_BINARY, // key type KEY_SIZE, 7, // assume binary length 7 KEY_VALUE, "some data", // value that will be truncated in 7 bytes KEY_COMMENT, "value is truncated", KEY_OWNER, "root", // owner (not uid) is root KEY_UID, 0, // root uid KEY_END); // end of args .fi .PP .PP .RE .PP .PP \fBParameters:\fP .RS 4 \fIname\fP a valid name to the key, or NULL to get a simple initialized, but really empty, object .RE .PP \fBSee also:\fP .RS 4 \fBkeyDel()\fP .RE .PP \fBReturns:\fP .RS 4 a pointer to a new allocated and initialized \fBKey\fP object\&. .RE .PP \fBReturn values:\fP .RS 4 \fINULL\fP on malloc error or if an invalid \fCname\fP was passed (see \fBkeySetName()\fP)\&. .RE .PP \fBExceptions:\fP .RS 4 \fIbad_alloc\fP if key could not be constructed (allocation problems) .RE .PP \fBParameters:\fP .RS 4 \fIkeyName\fP the name of the new key .RE .PP .SS "kdb::Key::Key (const std::string keyName, \&.\&.\&.)\fC [inline]\fP, \fC [explicit]\fP" .PP A practical way to fully create a \fBKey\fP object in one step\&. To just get a key object, simple do: .PP .PP .nf Key *k = keyNew(0); // work with it keyDel (k); .fi .PP If you want the key object to contain a name, value, comment and other meta info read on\&. .PP \fBNote:\fP .RS 4 When you already have a key with similar properties its easier to \fBkeyDup()\fP the key\&. .RE .PP You can call it in many different ways depending on the attribute tags you pass as parameters\&. Tags are represented as the \fBkeyswitch_t\fP values, and tell \fBkeyNew()\fP which \fBKey\fP attribute comes next\&. .PP We can also give an empty key name and a KEY_END tag with the same effect as before: .PP .PP .nf Key *k =keyNew("", KEY_END); // Has the same effect as above // work with it keyDel (k); .fi .PP But we can also give the key a proper name right from the start: .PP .PP .nf // Create and initialize a key with a name and nothing else Key *k=keyNew("user/some/example", KEY_END); // work with it keyDel (k); .fi .PP So, \fBkeyNew()\fP allocates memory for a key object and \fBkeyDel()\fP cleans everything up\&. .PP \fBkeyNew()\fP processes the given argument list even further\&. The \fBKey\fP attribute tags are the following: .IP "\(bu" 2 \fBKEY_VALUE\fP .br Next parameter is a pointer to the value that will be used\&. If no \fBKEY_BINARY\fP was used before, a string is assumed\&. .PP .nf // Create and initialize a key with a name and nothing else Key *k=keyNew("user/tmp/ex0", KEY_VALUE, "some data", // set a string value KEY_END); // end of args .fi .PP .IP "\(bu" 2 \fBKEY_SIZE\fP .br Define a maximum length of the value\&. This is only used when setting a binary key\&. .PP .nf // Create and initialize a key with a name and nothing else Key *k=keyNew("user/tmp/ex1", KEY_SIZE, 4, // has no effect on strings KEY_VALUE, "some data", // set a string value KEY_END); // end of args .fi .PP .IP "\(bu" 2 \fBKEY_META\fP .br Next two parameter is a meta name and a meta value\&. See \fBkeySetMeta()\fP\&. .PP .nf Key *k=keyNew("user/tmp/ex3", KEY_META, "comment", "a comment", // with a commet KEY_META, "owner", "root", // and an owner KEY_META, "special", "yes", // and any other meta data KEY_END); // end of args .fi .PP .IP "\(bu" 2 \fBKEY_END\fP .br Must be the last parameter passed to \fBkeyNew()\fP\&. It is always required, unless the \fCkeyName\fP is 0\&. .IP "\(bu" 2 ::KEY_FLAGS .br Bitwise disjunction of flags, which don't require one or more values\&. recommended way to set multiple flags\&. overrides previously defined flags\&. .PP .nf Key *k=keyNew("user/tmp/ex3", KEY_FLAGS, KEY_BINARY | KEY_CASCADING_NAME, // flags KEY_SIZE, 7, // assume binary length 7 KEY_VALUE, "some data", // value that will be truncated in 7 bytes KEY_END); // end of args .fi .PP .IP "\(bu" 2 \fBKEY_BINARY\fP .br Allows one to change the key to a binary key\&. Make sure that you also pass \fBKEY_SIZE\fP before you set the value\&. Otherwise it will be cut off with first \\0 in the string\&. So this flag toggle from \fBkeySetString()\fP to \fBkeySetBinary()\fP\&. If no value (nor size) is given, it will be a NULL key\&. .PP .nf // Create and initialize a key with a name and nothing else Key *k=keyNew("user/tmp/ex2", KEY_BINARY, KEY_SIZE, 4, // now the size is important KEY_VALUE, "some data", // sets the binary value ("some") KEY_END); // end of args .fi .PP .IP "\(bu" 2 ::KEY_CASCADING_NAME allow the name to start with / useful for \fBksLookup()\fP and \fBkdbGet()\fP parent/lookup keys .IP "\(bu" 2 ::KEY_META_NAME allow the name to start with arbitrary namespaces useful to compare with meta keys .PP .PP \fBDeprecated\fP .RS 4 These other flags deprecated and \fBKEY_META\fP should be preferred\&. They remain some time, however, for compatibility: .IP "\(bu" 2 \fBKEY_DIR\fP .br Define that the key is a directory rather than a ordinary key\&. This means its executable bits in its mode are set\&. But even without this option the key can have subkeys\&. See \fBkeySetDir()\fP\&. .IP "\(bu" 2 \fBKEY_OWNER\fP .br Next parameter is the owner\&. See \fBkeySetOwner()\fP\&. .IP "\(bu" 2 \fBKEY_UID\fP, \fBKEY_GID\fP .br Next parameter is taken as the UID (uid_t) or GID (gid_t) that will be defined on the key\&. See \fBkeySetUID()\fP and \fBkeySetGID()\fP\&. .IP "\(bu" 2 \fBKEY_MODE\fP .br Next parameter is taken as mode permissions (int) to the key\&. See \fBkeySetMode()\fP\&. .PP .nf Key *k=keyNew("user/tmp/ex3", KEY_VALUE, "some data", // with a simple value KEY_MODE, 0777, // permissions KEY_END); // end of args .fi .PP .IP "\(bu" 2 \fBKEY_COMMENT\fP .br Next parameter is a comment\&. See \fBkeySetComment()\fP\&. .PP .nf Key *k=keyNew("user/tmp/ex4", KEY_BINARY, // key type KEY_SIZE, 7, // assume binary length 7 KEY_VALUE, "some data", // value that will be truncated in 7 bytes KEY_COMMENT, "value is truncated", KEY_OWNER, "root", // owner (not uid) is root KEY_UID, 0, // root uid KEY_END); // end of args .fi .PP .PP .RE .PP .PP \fBParameters:\fP .RS 4 \fIname\fP a valid name to the key, or NULL to get a simple initialized, but really empty, object .RE .PP \fBSee also:\fP .RS 4 \fBkeyDel()\fP .RE .PP \fBReturns:\fP .RS 4 a pointer to a new allocated and initialized \fBKey\fP object\&. .RE .PP \fBReturn values:\fP .RS 4 \fINULL\fP on malloc error or if an invalid \fCname\fP was passed (see \fBkeySetName()\fP)\&. .RE .PP \fBExceptions:\fP .RS 4 \fIbad_alloc\fP if key could not be constructed (allocation problems) .RE .PP \fBWarning:\fP .RS 4 Not supported on some compilers, e\&.g\&. clang which require you to only pass non-POD in varg lists\&. .RE .PP \fBParameters:\fP .RS 4 \fIkeyName\fP the name of the new key .RE .PP .SS "kdb::Key::Key (const char * keyName, va_list ap)\fC [inline]\fP, \fC [explicit]\fP" .PP A practical way to fully create a \fBKey\fP object in one step\&. To just get a key object, simple do: .PP .PP .nf Key *k = keyNew(0); // work with it keyDel (k); .fi .PP If you want the key object to contain a name, value, comment and other meta info read on\&. .PP \fBNote:\fP .RS 4 When you already have a key with similar properties its easier to \fBkeyDup()\fP the key\&. .RE .PP You can call it in many different ways depending on the attribute tags you pass as parameters\&. Tags are represented as the \fBkeyswitch_t\fP values, and tell \fBkeyNew()\fP which \fBKey\fP attribute comes next\&. .PP We can also give an empty key name and a KEY_END tag with the same effect as before: .PP .PP .nf Key *k =keyNew("", KEY_END); // Has the same effect as above // work with it keyDel (k); .fi .PP But we can also give the key a proper name right from the start: .PP .PP .nf // Create and initialize a key with a name and nothing else Key *k=keyNew("user/some/example", KEY_END); // work with it keyDel (k); .fi .PP So, \fBkeyNew()\fP allocates memory for a key object and \fBkeyDel()\fP cleans everything up\&. .PP \fBkeyNew()\fP processes the given argument list even further\&. The \fBKey\fP attribute tags are the following: .IP "\(bu" 2 \fBKEY_VALUE\fP .br Next parameter is a pointer to the value that will be used\&. If no \fBKEY_BINARY\fP was used before, a string is assumed\&. .PP .nf // Create and initialize a key with a name and nothing else Key *k=keyNew("user/tmp/ex0", KEY_VALUE, "some data", // set a string value KEY_END); // end of args .fi .PP .IP "\(bu" 2 \fBKEY_SIZE\fP .br Define a maximum length of the value\&. This is only used when setting a binary key\&. .PP .nf // Create and initialize a key with a name and nothing else Key *k=keyNew("user/tmp/ex1", KEY_SIZE, 4, // has no effect on strings KEY_VALUE, "some data", // set a string value KEY_END); // end of args .fi .PP .IP "\(bu" 2 \fBKEY_META\fP .br Next two parameter is a meta name and a meta value\&. See \fBkeySetMeta()\fP\&. .PP .nf Key *k=keyNew("user/tmp/ex3", KEY_META, "comment", "a comment", // with a commet KEY_META, "owner", "root", // and an owner KEY_META, "special", "yes", // and any other meta data KEY_END); // end of args .fi .PP .IP "\(bu" 2 \fBKEY_END\fP .br Must be the last parameter passed to \fBkeyNew()\fP\&. It is always required, unless the \fCkeyName\fP is 0\&. .IP "\(bu" 2 ::KEY_FLAGS .br Bitwise disjunction of flags, which don't require one or more values\&. recommended way to set multiple flags\&. overrides previously defined flags\&. .PP .nf Key *k=keyNew("user/tmp/ex3", KEY_FLAGS, KEY_BINARY | KEY_CASCADING_NAME, // flags KEY_SIZE, 7, // assume binary length 7 KEY_VALUE, "some data", // value that will be truncated in 7 bytes KEY_END); // end of args .fi .PP .IP "\(bu" 2 \fBKEY_BINARY\fP .br Allows one to change the key to a binary key\&. Make sure that you also pass \fBKEY_SIZE\fP before you set the value\&. Otherwise it will be cut off with first \\0 in the string\&. So this flag toggle from \fBkeySetString()\fP to \fBkeySetBinary()\fP\&. If no value (nor size) is given, it will be a NULL key\&. .PP .nf // Create and initialize a key with a name and nothing else Key *k=keyNew("user/tmp/ex2", KEY_BINARY, KEY_SIZE, 4, // now the size is important KEY_VALUE, "some data", // sets the binary value ("some") KEY_END); // end of args .fi .PP .IP "\(bu" 2 ::KEY_CASCADING_NAME allow the name to start with / useful for \fBksLookup()\fP and \fBkdbGet()\fP parent/lookup keys .IP "\(bu" 2 ::KEY_META_NAME allow the name to start with arbitrary namespaces useful to compare with meta keys .PP .PP \fBDeprecated\fP .RS 4 These other flags deprecated and \fBKEY_META\fP should be preferred\&. They remain some time, however, for compatibility: .IP "\(bu" 2 \fBKEY_DIR\fP .br Define that the key is a directory rather than a ordinary key\&. This means its executable bits in its mode are set\&. But even without this option the key can have subkeys\&. See \fBkeySetDir()\fP\&. .IP "\(bu" 2 \fBKEY_OWNER\fP .br Next parameter is the owner\&. See \fBkeySetOwner()\fP\&. .IP "\(bu" 2 \fBKEY_UID\fP, \fBKEY_GID\fP .br Next parameter is taken as the UID (uid_t) or GID (gid_t) that will be defined on the key\&. See \fBkeySetUID()\fP and \fBkeySetGID()\fP\&. .IP "\(bu" 2 \fBKEY_MODE\fP .br Next parameter is taken as mode permissions (int) to the key\&. See \fBkeySetMode()\fP\&. .PP .nf Key *k=keyNew("user/tmp/ex3", KEY_VALUE, "some data", // with a simple value KEY_MODE, 0777, // permissions KEY_END); // end of args .fi .PP .IP "\(bu" 2 \fBKEY_COMMENT\fP .br Next parameter is a comment\&. See \fBkeySetComment()\fP\&. .PP .nf Key *k=keyNew("user/tmp/ex4", KEY_BINARY, // key type KEY_SIZE, 7, // assume binary length 7 KEY_VALUE, "some data", // value that will be truncated in 7 bytes KEY_COMMENT, "value is truncated", KEY_OWNER, "root", // owner (not uid) is root KEY_UID, 0, // root uid KEY_END); // end of args .fi .PP .PP .RE .PP .PP \fBParameters:\fP .RS 4 \fIname\fP a valid name to the key, or NULL to get a simple initialized, but really empty, object .RE .PP \fBSee also:\fP .RS 4 \fBkeyDel()\fP .RE .PP \fBReturns:\fP .RS 4 a pointer to a new allocated and initialized \fBKey\fP object\&. .RE .PP \fBReturn values:\fP .RS 4 \fINULL\fP on malloc error or if an invalid \fCname\fP was passed (see \fBkeySetName()\fP)\&. .RE .PP \fBExceptions:\fP .RS 4 \fIbad_alloc\fP if key could not be constructed (allocation problems) .RE .PP \fBParameters:\fP .RS 4 \fIkeyName\fP the name of the new key .br \fIap\fP the variable argument list pointer .RE .PP .SS "kdb::Key::~Key ()\fC [inline]\fP" .PP Destructs the key\&. .PP \fBSee also:\fP .RS 4 del() .RE .PP .SH "Member Function Documentation" .PP .SS "void kdb::Key::addBaseName (const std::string & baseName)\fC [inline]\fP" .PP Adds a base name for a key\&. Adds \fCbaseName\fP (that will be escaped) to the current key name\&. A new baseName will be added, no other part of the key name will be affected\&. .PP Assumes that \fCkey\fP is a directory and will append \fCbaseName\fP to it\&. The function adds the path separator for concatenating\&. .PP So if \fCkey\fP has name \fC'system/dir1/dir2'\fP and this method is called with \fCbaseName\fP \fC'mykey'\fP, the resulting key will have the name \fC'system/dir1/dir2/mykey'\fP\&. .PP When \fCbaseName\fP is 0 nothing will happen and the size of the name is returned\&. .PP The escaping rules apply as in \fBabove \fP\&. .PP A simple example is: .PP .nf Key * k = keyNew("user/my/long", KEY_END); keyAddBaseName(k, "myname"); printf ("%s\n", keyName(k)); // will print user/my/long/myname keyDel(k); .fi .PP E\&.g\&. if you add \&. it will be escaped: .PP .nf keySetName (k, "system/valid"); succeed_if (keyAddBaseName (k, "\&.") >= 0, "could not add a base name"); succeed_if_same_string(keyName(k), "system/valid/\\\&."); succeed_if_same_string(keyBaseName(k), "\&."); .fi .PP .PP \fBSee also:\fP .RS 4 \fBkeySetBaseName()\fP to \fBset\fP a base name .PP \fBkeySetName()\fP to \fBset\fP a new name\&. .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .br \fIbaseName\fP the string to append to the name .RE .PP \fBReturns:\fP .RS 4 the size in bytes of the new key name including the ending NULL .RE .PP \fBReturn values:\fP .RS 4 \fI-1\fP if the key had no name .br \fI-1\fP on NULL pointers .br \fI-1\fP if key was inserted to a keyset before .RE .PP \fBExceptions:\fP .RS 4 \fIKeyInvalidName\fP if the name is not valid .RE .PP .SS "void kdb::Key::clear ()\fC [inline]\fP" .PP Clears/Invalidates a key\&. Afterwards the object is empty again\&. .PP \fBNote:\fP .RS 4 This is not a null key, so it will evaluate to true\&. \fBisValid()\fP will, however, be false\&. .RE .PP \fBSee also:\fP .RS 4 \fBrelease()\fP .PP \fBisValid()\fP, \fBisNull()\fP .RE .PP \fBKey\fP Object Cleaner\&. Will reset all internal data\&. .PP After this call you will receive a fresh key\&. .PP The reference counter will stay unmodified\&. .PP \fBNote:\fP .RS 4 that you might also \fBclear()\fP all aliases with this operation\&. .RE .PP .PP .nf int f (Key *k) { keyClear (k); // you have a fresh key k here keySetString (k, "value"); // the caller will get an empty key k with an value } .fi .PP .PP \fBReturn values:\fP .RS 4 \fIreturns\fP 0 on success .br \fI-1\fP on null pointer .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP .SS "void kdb::Key::copy (const \fBKey\fP & other)\fC [inline]\fP" .PP Copy or Clear a key\&. Most often you may prefer \fBkeyDup()\fP which allocates a new key and returns a duplication of another key\&. .PP But when you need to copy into an existing key, e\&.g\&. because it was passed by a pointer in a function you can do so: .PP .PP .nf void h (Key *k) { // receive key c keyCopy (k, c); // the caller will see the changed key k } .fi .PP The reference counter will not be changed for both keys\&. Affiliation to keysets are also not affected\&. .PP The meta data will be duplicated for the destination key\&. So it will not take much additional space, even with lots of metadata\&. .PP When you pass a NULL-pointer as source the data of dest will be cleaned completely (except reference counter, see \fBkeyClear()\fP) and you get a fresh dest key: .PP .PP .nf void g (Key *k) { keyCopy (k, 0); // k is now an empty and fresh key } .fi .PP If you want to copy everything, except e\&.g\&. the value you can use \fBkeyCopy()\fP too: .PP .PP .nf void j (Key *k) { size_t size = keyGetValueSize (k); char *value = malloc (size); int bstring = keyIsString (k); // receive key c memcpy (value, keyValue(k), size); keyCopy (k, c); if (bstring) keySetString (k, value); else keySetBinary (k, value, size); free (value); // the caller will see the changed key k // with the name and metadata from c (except // metadata "binary", which stayed the same) } .fi .PP Restrain from coping everything yourself, because it will lead to wrong metadata and is not able to copy empty or cascading names: .PP .PP .nf void i (Key *k) { keySetName(k, keyName(c)); keySetString(k, keyString(c)); keyCopyAllMeta(k, c); // k is not a copy of c even if everything was successfully, // because it still contains meta data from k } .fi .PP .PP \fBParameters:\fP .RS 4 \fIdest\fP the key which will be written to .br \fIsource\fP the key which should be copied or NULL to clean the destination key .RE .PP \fBReturn values:\fP .RS 4 \fI-1\fP on failure when a NULL pointer was passed for dest or a dynamic property could not be written\&. The content will be unmodified then\&. .br \fI0\fP when dest was cleaned .br \fI1\fP when source was successfully copied .RE .PP \fBSee also:\fP .RS 4 \fBkeyDup()\fP to \fBget\fP a duplication of a \fBKey\fP .RE .PP .SS "void kdb::Key::copyAllMeta (const \fBKey\fP & other)\fC [inline]\fP" .PP Do a shallow copy of all meta data from source to dest\&. The key dest will additionally have all meta data the source had\&. Meta data not present in source will not be changed\&. Meta data which was present in source and dest will be overwritten\&. .PP For example the meta data type is copied into the \fBKey\fP k: .PP .PP .nf void l(Key *k) { // receive c keyCopyAllMeta(k, c); // the caller will see the changed key k // with all the metadata from c } .fi .PP The main purpose of this function is for plugins or applications which want to add the same meta data to n keys\&. When you do that with \fBkeySetMeta()\fP it will take n times the memory for the key\&. This can be considerable amount of memory for many keys with some meta data for each\&. .PP To avoid that problem you can use \fBkeyCopyAllMeta()\fP or \fBkeyCopyMeta()\fP: .PP .PP .nf void o(KeySet *ks) { Key *current; Key *shared = keyNew (0); keySetMeta(shared, "shared1", "this meta data should be shared among many keys"); keySetMeta(shared, "shared2", "this meta data should be shared among many keys also"); keySetMeta(shared, "shared3", "this meta data should be shared among many keys too"); ksRewind(ks); while ((current = ksNext(ks)) != 0) { if (needsSharedData(current)) keyCopyAllMeta(current, shared); } keyDel(shared); } .fi .PP .PP \fBPostcondition:\fP .RS 4 for every metaName present in source: keyGetMeta(source, metaName) == keyGetMeta(dest, metaName) .RE .PP \fBReturn values:\fP .RS 4 \fI1\fP if was successfully copied .br \fI0\fP if source did not have any meta data .br \fI-1\fP on null pointer of dest or source .br \fI-1\fP on memory problems .RE .PP \fBParameters:\fP .RS 4 \fIdest\fP the destination where the meta data should be copied too .br \fIsource\fP the key where the meta data should be copied from .RE .PP \fBSee also:\fP .RS 4 \fBgetMeta()\fP, \fBsetMeta()\fP, \fBcopyMeta()\fP .RE .PP .SS "void kdb::Key::copyMeta (const \fBKey\fP & other, const std::string & metaName)\fC [inline]\fP" .PP Do a shallow copy of meta data from source to dest\&. The key dest will have the same meta data referred with metaName afterwards then source\&. .PP For example the meta data type is copied into the \fBKey\fP k\&. .PP .PP .nf void l(Key *k) { // receive c keyCopyMeta(k, c, "type"); // the caller will see the changed key k // with the metadata "type" from c } .fi .PP .PP The main purpose of this function is for plugins or applications which want to add the same meta data to n keys\&. When you do that with \fBkeySetMeta()\fP it will take n times the memory for the key\&. This can be considerable amount of memory for many keys with some meta data for each\&. .PP To avoid that problem you can use \fBkeyCopyAllMeta()\fP or \fBkeyCopyMeta()\fP\&. .PP .PP .nf void o(KeySet *ks) { Key *current; Key *shared = keyNew (0); keySetMeta(shared, "shared", "this meta data should be shared among many keys"); ksRewind(ks); while ((current = ksNext(ks)) != 0) { if (needs_shared_data(current)) keyCopyMeta(current, shared, "shared"); } } .fi .PP .PP \fBPostcondition:\fP .RS 4 keyGetMeta(source, metaName) == keyGetMeta(dest, metaName) .RE .PP \fBReturn values:\fP .RS 4 \fI1\fP if was successfully copied .br \fI0\fP if the meta data in dest was removed too .br \fI-1\fP on null pointers (source or dest) .br \fI-1\fP on memory problems .RE .PP \fBParameters:\fP .RS 4 \fIdest\fP the destination where the meta data should be copied too .br \fIsource\fP the key where the meta data should be copied from .br \fImetaName\fP the name of the meta data which should be copied .RE .PP \fBSee also:\fP .RS 4 \fBgetMeta()\fP, \fBsetMeta()\fP, \fBcopyAllMeta()\fP .RE .PP .SS "const \fBKey\fP kdb::Key::currentMeta () const\fC [inline]\fP" .PP Returns the Value of a Meta-Information which is current\&. The pointer is NULL if you reached the end or after \fBksRewind()\fP\&. .PP \fBNote:\fP .RS 4 You must not delete or change the returned key, use \fBkeySetMeta()\fP if you want to delete or change it\&. .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturns:\fP .RS 4 a buffer to the value pointed by \fCkey's\fP cursor .RE .PP \fBReturn values:\fP .RS 4 \fI0\fP on NULL pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeyNextMeta()\fP, \fBkeyRewindMeta()\fP .PP \fBksCurrent()\fP for pedant in iterator interface of \fBKeySet\fP .RE .PP \fBNote:\fP .RS 4 that the key will be null if last meta data is found\&. .RE .PP .PP .nf k\&.rewindMeta(); while (meta = k\&.nextMeta()) { cout << meta\&.getName() << " " << meta\&.getString() << endl; } .fi .PP .PP \fBSee also:\fP .RS 4 \fBrewindMeta()\fP, \fBnextMeta()\fP .RE .PP .SS "void kdb::Key::delMeta (const std::string & metaName)\fC [inline]\fP" .PP Delete metadata for key\&. .PP \fBSee also:\fP .RS 4 \fBsetMeta()\fP, \fBgetMeta()\fP, \fBcopyMeta()\fP, \fBcopyAllMeta()\fP .RE .PP .SS "ckdb::Key * kdb::Key::dup () const\fC [inline]\fP" .PP Return a duplicate of a key\&. Memory will be allocated as needed for dynamic properties\&. .PP The new key will not be member of any \fBKeySet\fP and will start with a new reference counter at 0\&. A subsequent \fBkeyDel()\fP will delete the key\&. .PP .PP .nf int f (const Key * source) { Key * dup = keyDup (source); // work with duplicate keyDel (dup); // everything related to dup is freed // and source is unchanged } .fi .PP .PP Like for a new key after \fBkeyNew()\fP a subsequent \fBksAppend()\fP makes a \fBKeySet\fP to take care of the lifecycle of the key\&. .PP .PP .nf int g (const Key * source, KeySet * ks) { Key * dup = keyDup (source); // work with duplicate ksAppendKey (ks, dup); // ksDel(ks) will also free the duplicate // source remains unchanged\&. } .fi .PP .PP Duplication of keys should be preferred to \fBkeyNew()\fP, because data like owner can be filled with a copy of the key instead of asking the environment\&. It can also be optimized in the checks, because the keyname is known to be valid\&. .PP \fBParameters:\fP .RS 4 \fIsource\fP has to be an initialized source \fBKey\fP .RE .PP \fBReturn values:\fP .RS 4 \fI0\fP failure or on NULL pointer .RE .PP \fBReturns:\fP .RS 4 a fully copy of source on success .RE .PP \fBSee also:\fP .RS 4 \fBksAppend()\fP, \fBkeyDel()\fP, \fBkeyNew()\fP .RE .PP .SS "template T kdb::Key::get () const\fC [inline]\fP" .PP Get a key value\&. You can write your own template specialication, e\&.g\&.: .PP .nf template <> inline QColor Key::get() const { if (getStringSize() < 1) { throw KeyTypeConversion(); } std::string str = getString(); QColor c(str\&.c_str()); return c; } .fi .PP .PP \fBReturns:\fP .RS 4 the string directly from the key\&. .RE .PP It should be the same as \fBget()\fP\&. .PP \fBReturns:\fP .RS 4 empty string on null pointers .RE .PP \fBExceptions:\fP .RS 4 \fIKeyException\fP on null key or not a valid size .br \fIKeyTypeMismatch\fP if key holds binary data and not a string .RE .PP \fBNote:\fP .RS 4 unlike in the C version, it is safe to change the returned string\&. .RE .PP \fBSee also:\fP .RS 4 \fBisString()\fP, \fBgetBinary()\fP .RE .PP This method tries to serialise the string to the given type\&. .SS "std::string kdb::Key::getBaseName () const\fC [inline]\fP" .PP Returns a pointer to the internal unescaped key name where the \fCbasename\fP starts\&. This is a much more efficient version of \fBkeyGetBaseName()\fP and you should use it if you are responsible enough to not mess up things\&. The name might change or even point to a wrong place after a \fBkeySetName()\fP\&. So make sure to copy the memory before the name changes\&. .PP \fBkeyBaseName()\fP returns '' when there is no keyBaseName\&. The reason is .PP .nf keySetName(k,""); succeed_if_same_string(keyBaseName(k), ""); keySetName(k,"user"); succeed_if_same_string(keyBaseName(k), ""); .fi .PP And there is also support for really empty basenames: .PP .nf keySetName (k, "system/valid"); succeed_if (keyAddBaseName (k, "") >= 0, "could not add a base name"); succeed_if_same_string(keyName(k), "system/valid/%"); succeed_if_same_string(keyBaseName(k), ""); .fi .PP .PP \fBNote:\fP .RS 4 You must never use the pointer returned by \fBkeyBaseName()\fP method to change the name, but you should use \fBkeySetBaseName()\fP instead\&. .PP Do not assume that \fBkeyBaseName()\fP points to the same region as \fBkeyName()\fP does\&. .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the object to obtain the basename from .RE .PP \fBReturns:\fP .RS 4 a pointer to the basename .RE .PP \fBReturn values:\fP .RS 4 \fI''\fP when the key has no (base)name .br \fI0\fP on NULL pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetBaseName()\fP, \fBkeyGetBaseNameSize()\fP .PP \fBkeyName()\fP to \fBget\fP a pointer to the name .PP \fBkeyOwner()\fP to \fBget\fP a pointer to the owner .RE .PP .SS "ssize_t kdb::Key::getBaseNameSize () const\fC [inline]\fP" .PP Calculates number of bytes needed to store basename of \fCkey\fP\&. \fBKey\fP names that have only root names (e\&.g\&. \fC'system'\fP or \fC'user'\fP or \fC'user:domain'\fP ) does not have basenames, thus the function will return 1 bytes to store ''\&. .PP Basenames are denoted as: .IP "\(bu" 2 \fCsystem/some/thing/basename\fP -> \fCbasename\fP .IP "\(bu" 2 \fCuser:domain/some/thing/base\\/name\fP > \fCbase\\/name\fP .PP .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturns:\fP .RS 4 size in bytes of \fCkey's\fP basename including ending NULL .RE .PP \fBSee also:\fP .RS 4 \fBkeyBaseName()\fP, \fBkeyGetBaseName()\fP .PP \fBkeyName()\fP, \fBkeyGetName()\fP, \fBkeySetName()\fP .RE .PP .SS "std::string kdb::Key::getBinary () const\fC [inline]\fP" .PP Get the value of a key as a binary\&. .PP \fBReturns:\fP .RS 4 the binary Value of the key\&. .RE .PP \fBReturn values:\fP .RS 4 \fI''\fP on null pointers (size == 0) and on data only containing \\0 .RE .PP \fBNote:\fP .RS 4 if you need to distinguish between null pointers and data containing \\0 you can use \fBgetValue()\fP\&. .RE .PP \fBExceptions:\fP .RS 4 \fIKeyException\fP on invalid binary size .br \fIKeyTypeMismatch\fP if key is string and not a binary .RE .PP If the type is not binary -1 will be returned\&. .PP When the binary data is empty (this is not the same as ''!) 0 will be returned and the returnedBinary will not be changed\&. .PP For string values see \fBkeyGetString()\fP and \fBkeyIsString()\fP\&. .PP When the returnedBinary is to small to hold the data (its maximum size is given by maxSize), the returnedBinary will not be changed and -1 is returned\&. .PP \fBExample:\fP .RS 4 .PP .nf Key *key = keyNew ("user/keyname", KEY_TYPE, KEY_TYPE_BINARY, KEY_END); char buffer[300]; if (keyGetBinary(key,buffer,sizeof(buffer)) == -1) { // handle error } .fi .PP .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the object to gather the value from .br \fIreturnedBinary\fP pre-allocated memory to store a copy of the key value .br \fImaxSize\fP number of bytes of pre-allocated memory in \fCreturnedBinary\fP .RE .PP \fBReturns:\fP .RS 4 the number of bytes actually copied to \fCreturnedBinary\fP .RE .PP \fBReturn values:\fP .RS 4 \fI0\fP if the binary is empty .br \fI-1\fP on NULL pointers .br \fI-1\fP if maxSize is 0 .br \fI-1\fP if maxSize is too small for string .br \fI-1\fP if maxSize is larger than SSIZE_MAX .br \fI-1\fP on type mismatch: binary expected, but found string .RE .PP \fBSee also:\fP .RS 4 \fBkeyValue()\fP, \fBkeyGetValueSize()\fP, \fBkeySetBinary()\fP .PP \fBkeyGetString()\fP and \fBkeySetString()\fP as preferred alternative to binary .PP \fBkeyIsBinary()\fP to see how to check for binary type .PP \fBisBinary()\fP, \fBgetString()\fP, \fBgetValue()\fP .RE .PP .SS "ssize_t kdb::Key::getBinarySize () const\fC [inline]\fP" .PP Returns the number of bytes needed to store the key value, including the NULL terminator\&. It returns the correct size, independent of the \fBKey\fP Type\&. If it is a binary there might be '\\0' values in it\&. .PP For an empty string you need one byte to store the ending NULL\&. For that reason 1 is returned\&. This is not true for binary data, so there might be returned 0 too\&. .PP A binary key has no '\\0' termination\&. String types have it, so to there length will be added 1 to have enough space to store it\&. .PP This method can be used with malloc() before \fBkeyGetString()\fP or \fBkeyGetBinary()\fP is called\&. .PP .PP .nf char *buffer; buffer = malloc (keyGetValueSize (key)); // use this buffer to store the value (binary or string) // pass keyGetValueSize (key) for maxSize .fi .PP .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturns:\fP .RS 4 the number of bytes needed to store the key value .RE .PP \fBReturn values:\fP .RS 4 \fI1\fP when there is no data and type is not binary .br \fI0\fP when there is no data and type is binary .br \fI-1\fP on null pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetString()\fP, \fBkeyGetBinary()\fP, \fBkeyValue()\fP .RE .PP .SS "std::string kdb::Key::getFullName () const\fC [inline]\fP" .PP Get key full name, including the user domain name\&. .PP \fBReturns:\fP .RS 4 number of bytes written .RE .PP \fBReturn values:\fP .RS 4 \fI1\fP on empty name .br \fI-1\fP on NULL pointers .br \fI-1\fP if maxSize is 0 or larger than SSIZE_MAX .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object .br \fIreturnedName\fP pre-allocated memory to write the key name .br \fImaxSize\fP maximum number of bytes that will fit in returnedName, including the final NULL .RE .PP \fBExceptions:\fP .RS 4 \fIKeyException\fP if key is null .RE .PP .SS "ssize_t kdb::Key::getFullNameSize () const\fC [inline]\fP" .PP Bytes needed to store the key name including user domain and ending NULL\&. .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturns:\fP .RS 4 number of bytes needed to store key name including user domain .RE .PP \fBReturn values:\fP .RS 4 \fI1\fP on empty name .br \fI-1\fP on NULL pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetFullName()\fP, \fBkeyGetNameSize()\fP .RE .PP .SS "Key::func_t kdb::Key::getFunc () const\fC [inline]\fP" .PP Elektra can store function pointers as binary\&. This function returns such a function pointer\&. .PP \fBExceptions:\fP .RS 4 \fIKeyTypeMismatch\fP if no binary data found, or binary data has not correct length .RE .PP \fBReturns:\fP .RS 4 a function pointer stored with \fBsetBinary()\fP .RE .PP .SS "ckdb::Key * kdb::Key::getKey () const\fC [inline]\fP" .PP Passes out the raw key pointer\&. This pointer can be used to directly change the underlying key object\&. .PP \fBNote:\fP .RS 4 that the ownership remains in the object .RE .PP .SS "template T kdb::Key::getMeta (const std::string & metaName) const\fC [inline]\fP" .PP Returns the Value of a Meta-Information given by name\&. This is a much more efficient version of \fBkeyGetMeta()\fP\&. But unlike with keyGetMeta you are not allowed to modify the resulting string\&. .PP .PP .nf int f(Key *k) { if (!strcmp(keyValue(keyGetMeta(k, "type")), "boolean")) { // the type of the key is boolean } } .fi .PP .PP \fBNote:\fP .RS 4 You must not delete or change the returned key, use \fBkeySetMeta()\fP if you want to delete or change it\&. .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .br \fImetaName\fP the name of the meta information you want the value from .RE .PP \fBReturn values:\fP .RS 4 \fI0\fP if the key or metaName is 0 .br \fI0\fP if no such metaName is found .RE .PP \fBReturns:\fP .RS 4 value of Meta-Information if Meta-Information is found .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetMeta()\fP, \fBkeySetMeta()\fP .RE .PP You can specify your own template specialisation: .PP .nf template<> inline yourtype Key::getMeta(const std::string &name) const { yourtype x; std::string str; str = std::string( static_cast( ckdb::keyValue( ckdb::keyGetMeta(key, name\&.c_str()) ) ) ); return yourconversion(str); } .fi .PP .PP \fBExceptions:\fP .RS 4 \fIKeyTypeConversion\fP if meta data could not be parsed .RE .PP \fBNote:\fP .RS 4 No exception will be thrown if a const \fBKey\fP or char* is requested, but don't forget the const: getMeta, otherwise you will get an compiler error\&. .RE .PP If no meta is available: .IP "\(bu" 2 char* is null (evaluates to 0) .IP "\(bu" 2 const \fBKey\fP is null (evaluate to false) .IP "\(bu" 2 otherwise the default constructed type will be returned .PP \fBSee also:\fP .RS 4 \fBhasMeta\fP .PP \fBdelMeta()\fP, \fBsetMeta()\fP, \fBcopyMeta()\fP, \fBcopyAllMeta()\fP .RE .PP .PP .SS "std::string kdb::Key::getName () const\fC [inline]\fP" .PP Returns a pointer to the abbreviated real internal \fCkey\fP name\&. This is a much more efficient version of \fBkeyGetName()\fP and can use it if you are responsible enough to not mess up things\&. You are not allowed to change anything in the returned array\&. The content of that string may change after \fBkeySetName()\fP and similar functions\&. If you need a copy of the name, consider using \fBkeyGetName()\fP\&. .PP The name will be without owner, see \fBkeyGetFullName()\fP if you need the name with its owner\&. .PP \fBReturn values:\fP .RS 4 \fI''\fP when there is no keyName\&. The reason is .PP .nf key=keyNew(0); keySetName(key,""); keyName(key); // you would expect "" here keyDel(key); .fi .PP .RE .PP Valid key names are: .PP .IP "\(bu" 2 \fCspec/something\fP for specification of other keys\&. .IP "\(bu" 2 \fCproc/something\fP for in-memory keys, e\&.g\&. commandline\&. .IP "\(bu" 2 \fCdir/something\fP for dir keys in current working directory .IP "\(bu" 2 \fCsystem/something\fP for system keys in /etc or / .IP "\(bu" 2 \fCuser/something\fP for user keys in home directory .IP "\(bu" 2 \fCuser:username/something\fP for other users (deprecated: \fBkdbGet()\fP + \fBkdbSet()\fP currently unsupported) .IP "\(bu" 2 \fC/something\fP for cascading keys (actually refers to one of the above, see also \fBksLookup()\fP) .PP \fBNote:\fP .RS 4 Note that the \fBKey\fP structure keeps its own size field that is calculated by library internal calls, so to avoid inconsistencies, you must never use the pointer returned by \fBkeyName()\fP method to set a new value\&. Use \fBkeySetName()\fP instead\&. .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturns:\fP .RS 4 a pointer to the keyname which must not be changed\&. .RE .PP \fBReturn values:\fP .RS 4 \fI''\fP when there is no (a empty) keyname .br \fI0\fP on NULL pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetNameSize()\fP for the string length .PP \fBkeyGetFullName()\fP, \fBkeyGetFullNameSize()\fP to \fBget\fP the full name .PP \fBkeyGetName()\fP as alternative to \fBget\fP a \fBcopy\fP .PP \fBkeyOwner()\fP to \fBget\fP a pointer to owner .PP \fBkeyUnescapedName\fP to \fBget\fP an unescaped \fBKey\fP name .RE .PP \fBExceptions:\fP .RS 4 \fIKeyException\fP if key is null .RE .PP \fBNote:\fP .RS 4 unlike in the C version, it is safe to change the returned string\&. .RE .PP .PP .SS "ssize_t kdb::Key::getNameSize () const\fC [inline]\fP" .PP Bytes needed to store the key name without owner\&. For an empty key name you need one byte to store the ending NULL\&. For that reason 1 is returned\&. .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturns:\fP .RS 4 number of bytes needed, including ending NULL, to store key name without owner .RE .PP \fBReturn values:\fP .RS 4 \fI1\fP if there is is no key Name .br \fI-1\fP on NULL pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetName()\fP, \fBkeyGetFullNameSize()\fP .PP \fBkeyGetUnescapedNameSize\fP to \fBget\fP size of unescaped name .RE .PP .SS "std::string kdb::Key::getNamespace () const\fC [inline]\fP" .PP \fBReturns:\fP .RS 4 namespace as string .RE .PP Will return slash for cascading names\&. .PP \fBSee also:\fP .RS 4 \fBgetName()\fP, \fBisUser()\fP, \fBisSystem()\fP .RE .PP .SS "ssize_t kdb::Key::getReferenceCounter () const\fC [inline]\fP" .PP Return how many references the key has\&. The reference counting is the essential property of keys to make sure that they can be put safely into data structures\&. E\&.g\&. if you put a \fBKey\fP into a \fBKeySet\fP: .PP .PP .nf Key *k = keyNew("user/proper_name", KEY_END); // ref counter = 0 KeySet *ks = ksNew (1, k, KS_END); keyDel(k); // key will not be deleted, because its in the keyset ksDel(ks); // now the key will be deleted .fi .PP You can even add the key to more KeySets: .PP .PP .nf Key *k = keyNew("user/proper_name", KEY_END); // ref counter 0 KeySet *ks1 = ksNew(1, k, KS_END); // ref counter of k 1 KeySet *ks2 = ksNew(1, k, KS_END); // ref counter of k 2 ksDel(ks1); // ref counter of k 1 ksDel(ks2); // k is now deleted .fi .PP If you increment only by one with \fBkeyIncRef()\fP the same as said above is valid: .PP .PP .nf Key *k = keyNew(0); // ref counter = 0 keyIncRef(k); // ref counter = 1 keyDel(k); // key will not be deleted keyDecRef(k); keyDel(k); .fi .PP or use \fBkeyIncRef()\fP more than once: .PP .PP .nf Key *k = keyNew(0); // ref counter 0 keyIncRef(k); // ref counter of key 1 keyDel (k); // has no effect keyIncRef(k); // ref counter of key 2 keyDel (k); // has no effect keyDecRef(k); // ref counter of key 1 keyDel (k); // has no effect keyDecRef(k); // ref counter is now 0 keyDel (k); // k is now deleted .fi .PP The key won't be deleted by a \fBkeyDel()\fP as long refcounter is not 0\&. .PP The references will be incremented on successful calls to \fBksAppendKey()\fP or \fBksAppend()\fP\&. .PP \fBNote:\fP .RS 4 \fBkeyDup()\fP will reset the references for dupped key\&. .RE .PP For your own applications you can use \fBkeyIncRef()\fP and \fBkeyDecRef()\fP for reference counting, too\&. .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturns:\fP .RS 4 the number of references .RE .PP \fBReturn values:\fP .RS 4 \fI-1\fP on null pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeyIncRef()\fP and \fBkeyDecRef()\fP .RE .PP .SS "std::string kdb::Key::getString () const\fC [inline]\fP" .PP \fBReturns:\fP .RS 4 the string directly from the key\&. .RE .PP It should be the same as \fBget()\fP\&. .PP \fBReturns:\fP .RS 4 empty string on null pointers .RE .PP \fBExceptions:\fP .RS 4 \fIKeyException\fP on null key or not a valid size .br \fIKeyTypeMismatch\fP if key holds binary data and not a string .RE .PP \fBNote:\fP .RS 4 unlike in the C version, it is safe to change the returned string\&. .RE .PP \fBSee also:\fP .RS 4 \fBisString()\fP, \fBgetBinary()\fP .RE .PP .SS "ssize_t kdb::Key::getStringSize () const\fC [inline]\fP" .PP Returns the number of bytes needed to store the key value, including the NULL terminator\&. It returns the correct size, independent of the \fBKey\fP Type\&. If it is a binary there might be '\\0' values in it\&. .PP For an empty string you need one byte to store the ending NULL\&. For that reason 1 is returned\&. This is not true for binary data, so there might be returned 0 too\&. .PP A binary key has no '\\0' termination\&. String types have it, so to there length will be added 1 to have enough space to store it\&. .PP This method can be used with malloc() before \fBkeyGetString()\fP or \fBkeyGetBinary()\fP is called\&. .PP .PP .nf char *buffer; buffer = malloc (keyGetValueSize (key)); // use this buffer to store the value (binary or string) // pass keyGetValueSize (key) for maxSize .fi .PP .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturns:\fP .RS 4 the number of bytes needed to store the key value .RE .PP \fBReturn values:\fP .RS 4 \fI1\fP when there is no data and type is not binary .br \fI0\fP when there is no data and type is binary .br \fI-1\fP on null pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetString()\fP, \fBkeyGetBinary()\fP, \fBkeyValue()\fP .RE .PP .SS "const void * kdb::Key::getValue () const\fC [inline]\fP" .PP Return a pointer to the real internal \fCkey\fP value\&. This is a much more efficient version of \fBkeyGetString()\fP \fBkeyGetBinary()\fP, and you should use it if you are responsible enough to not mess up things\&. You are not allowed to modify anything in the returned string\&. If you need a copy of the Value, consider to use \fBkeyGetString()\fP or \fBkeyGetBinary()\fP instead\&. .SH "String Handling" .PP If \fCkey\fP is string (\fBkeyIsString()\fP), you may cast the returned as a \fC'char *'\fP because you'll get a NULL terminated regular string\&. .PP \fBkeyValue()\fP returns '' in string mode when there is no value\&. The reason is .PP .nf key=keyNew(0); keySetString(key,""); keyValue(key); // you would expect "" here keyDel(key); .fi .PP .SH "Binary Data Handling" .PP If the data is binary, the size of the value must be determined by \fBkeyGetValueSize()\fP, any strlen() operations are not suitable to determine the size\&. .PP \fBkeyValue()\fP returns 0 in binary mode when there is no value\&. The reason is .PP .nf key=keyNew(0); keySetBinary(key, 0, 0); keyValue(key); // you would expect 0 here keySetBinary(key,"", 1); keyValue(key); // you would expect "" (a pointer to '\0') here int i=23; keySetBinary(key, (void*)&i, 4); (int*)keyValue(key); // you would expect a pointer to (int)23 here keyDel(key); .fi .PP .PP \fBNote:\fP .RS 4 Note that the \fBKey\fP structure keeps its own size field that is calculated by library internal calls, so to avoid inconsistencies, you must never use the pointer returned by \fBkeyValue()\fP method to set a new value\&. Use \fBkeySetString()\fP or \fBkeySetBinary()\fP instead\&. .RE .PP \fBWarning:\fP .RS 4 Binary keys will return a NULL pointer when there is no data in contrast to \fBkeyName()\fP, \fBkeyBaseName()\fP, \fBkeyOwner()\fP and \fBkeyComment()\fP\&. For string value the behaviour is the same\&. .RE .PP \fBExample:\fP .RS 4 .PP .nf KDB *handle = kdbOpen(); KeySet *ks=ksNew(0, KS_END); Key *current=0; kdbGetByName(handle,ks,"system/sw/my",KDB_O_SORT|KDB_O_RECURSIVE); ksRewind(ks); while(current=ksNext(ks)) { size_t size=0; if (keyIsBin(current)) { size=keyGetValueSize(current); printf("Key %s has a value of size %d bytes\&. Value: \nComment: %s", keyName(current), size, keyComment(current)); } else { size=elektraStrLen((char *)keyValue(current)); printf("Key %s has a value of size %d bytes\&. Value: %s\nComment: %s", keyName(current), size, (char *)keyValue(current), keyComment(current)); } } ksDel (ks); kdbClose (handle); .fi .PP .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturns:\fP .RS 4 a pointer to internal value .RE .PP \fBReturn values:\fP .RS 4 \fI''\fP when there is no data and key is not binary .br \fI0\fP where there is no data and key is binary .br \fI0\fP on NULL pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetValueSize()\fP, \fBkeyGetString()\fP, \fBkeyGetBinary()\fP .RE .PP \fBReturns:\fP .RS 4 the value of the key .RE .PP \fBSee also:\fP .RS 4 \fBgetBinary()\fP .RE .PP .SS "bool kdb::Key::hasMeta (const std::string & metaName) const\fC [inline]\fP" .PP \fBReturn values:\fP .RS 4 \fItrue\fP if there is a metadata with given name .br \fIfalse\fP if no such metadata exists .RE .PP \fBSee also:\fP .RS 4 \fBgetMeta()\fP .RE .PP .SS "bool kdb::Key::isBelow (const \fBKey\fP & k) const\fC [inline]\fP" .PP Check if the key check is below the key key or not\&. .PP \fBParameters:\fP .RS 4 \fIk\fP the other key .RE .PP \fBReturns:\fP .RS 4 true if our key is below k .RE .PP Example: .PP .nf key user/sw/app check user/sw/app/key .fi .PP .PP returns true because check is below key .PP Example: .PP .nf key user/sw/app check user/sw/app/folder/key .fi .PP .PP returns also true because check is indirect below key .PP Obviously, there is no key above a namespace (e\&.g\&. user, system, /): .PP .PP .nf key * check user .fi .PP .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .br \fIcheck\fP the key to find the relative position of .RE .PP \fBReturn values:\fP .RS 4 \fI1\fP if check is below key .br \fI0\fP if it is not below or if it is the same key .RE .PP \fBSee also:\fP .RS 4 \fBkeySetName()\fP, \fBkeyGetName()\fP, \fBkeyIsDirectBelow()\fP .RE .PP .SS "bool kdb::Key::isBelowOrSame (const \fBKey\fP & k) const\fC [inline]\fP" .PP .PP \fBParameters:\fP .RS 4 \fIk\fP the other key .RE .PP \fBReturns:\fP .RS 4 true if our key is below k or the same as k .RE .PP .SS "bool kdb::Key::isBinary () const\fC [inline]\fP" .PP Check if a key is binary type\&. The function checks if the key is a binary\&. Opposed to string values binary values can have '\\0' inside the value and may not be terminated by a null character\&. Their disadvantage is that you need to pass their size\&. .PP Make sure to use this function and don't test the binary type another way to ensure compatibility and to write less error prone programs\&. .PP \fBReturn values:\fP .RS 4 \fI1\fP if it is binary .br \fI0\fP if it is not .br \fI-1\fP on NULL pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetBinary()\fP, \fBkeySetBinary()\fP .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key to check .RE .PP .SS "bool kdb::Key::isDirectBelow (const \fBKey\fP & k) const\fC [inline]\fP" .PP Check if the key check is direct below the key key or not\&. .PP \fBParameters:\fP .RS 4 \fIk\fP the other key .RE .PP \fBReturns:\fP .RS 4 true if our key is direct below k .RE .PP .PP .nf Example: key user/sw/app check user/sw/app/key returns true because check is below key Example: key user/sw/app check user/sw/app/folder/key does not return true, because there is only a indirect relation .fi .PP .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .br \fIcheck\fP the key to find the relative position of .RE .PP \fBReturn values:\fP .RS 4 \fI1\fP if check is below key .br \fI0\fP if it is not below or if it is the same key .br \fI-1\fP on null pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeyIsBelow()\fP, \fBkeySetName()\fP, \fBkeyGetName()\fP .RE .PP .SS "bool kdb::Key::isInactive () const\fC [inline]\fP" .PP Check whether a key is inactive\&. In Elektra terminology a hierarchy of keys is inactive if the rootkey's basename starts with '\&.'\&. So a key is also inactive if it is below an inactive key\&. For example, user/key/\&.hidden is inactive and so is user/\&.hidden/below\&. .PP Inactive keys should not have any meaning to applications, they are only a convention reserved for users and administrators\&. To automatically remove all inactive keys for an application, consider to use the hidden plugin\&. .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturn values:\fP .RS 4 \fI1\fP if the key is inactive .br \fI0\fP if the key is active .br \fI-1\fP on NULL pointer or when key has no name .RE .PP .SS "bool kdb::Key::isNull () const\fC [inline]\fP" .PP Checks if C++ wrapper has an underlying key\&. .PP \fBSee also:\fP .RS 4 operator bool(), \fBisValid()\fP .RE .PP \fBReturns:\fP .RS 4 true if no underlying key exists .RE .PP .SS "bool kdb::Key::isString () const\fC [inline]\fP" .PP Check if a key is string type\&. String values are null terminated and are not allowed to have any '\\0' characters inside the string\&. .PP Make sure to use this function and don't test the string type another way to ensure compatibility and to write less error prone programs\&. .PP \fBReturn values:\fP .RS 4 \fI1\fP if it is string .br \fI0\fP if it is not .br \fI-1\fP on NULL pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetString()\fP, \fBkeySetString()\fP .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key to check .RE .PP .SS "bool kdb::Key::isSystem () const\fC [inline]\fP" .PP Name starts with 'system'\&. .PP \fBReturn values:\fP .RS 4 \fItrue\fP if it is a system key .br \fIfalse\fP otherwise .RE .PP .SS "bool kdb::Key::isUser () const\fC [inline]\fP" .PP Name starts with 'user'\&. .PP \fBReturn values:\fP .RS 4 \fItrue\fP if it is a user key .br \fIfalse\fP otherwise .RE .PP .SS "bool kdb::Key::isValid () const\fC [inline]\fP" .PP \fBReturns:\fP .RS 4 if the key is valid .RE .PP An invalid key has no name\&. The name of valid keys either start with user or system\&. .PP \fBReturn values:\fP .RS 4 \fItrue\fP if the key has a valid name .br \fIfalse\fP if the key has an invalid name .RE .PP \fBSee also:\fP .RS 4 \fBgetName()\fP, \fBisUser()\fP, \fBisSystem()\fP, \fBgetNamespace()\fP .RE .PP .SS "bool kdb::Key::needSync () const\fC [inline]\fP" .PP Test if a key needs to be synced to backend storage\&. If any key modification took place the key will be flagged so that \fBkdbSet()\fP knows which keys were modified and which not\&. .PP After \fBkeyNew()\fP the flag will normally be set, but after \fBkdbGet()\fP and \fBkdbSet()\fP the flag will be removed\&. When you modify the key the flag will be set again\&. .PP In your application you can make use of that flag to know if you changed something in a key after a \fBkdbGet()\fP or \fBkdbSet()\fP\&. .PP \fBNote:\fP .RS 4 Note that the sync status will be updated on any change, including meta data\&. .RE .PP \fBDeprecated\fP .RS 4 The handling of synchronization is done internally and does not need to be checked by neither application nor plugins\&. .RE .PP .PP \fBSee also:\fP .RS 4 after \fBkeyNew()\fP, \fBkeyDup()\fP keys need sync .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturn values:\fP .RS 4 \fI1\fP if \fCkey\fP was changed in memory, 0 otherwise .br \fI-1\fP on NULL pointer .RE .PP .SS "const \fBKey\fP kdb::Key::nextMeta ()\fC [inline]\fP" .PP Iterate to the next meta information\&. Keys have an internal cursor that can be reset with \fBkeyRewindMeta()\fP\&. Every time \fBkeyNextMeta()\fP is called the cursor is incremented and the new current Name of Meta Information is returned\&. .PP You'll get a NULL pointer if the meta information after the end of the \fBKey\fP was reached\&. On subsequent calls of \fBkeyNextMeta()\fP it will still return the NULL pointer\&. .PP The \fCkey\fP internal cursor will be changed, so it is not const\&. .PP \fBNote:\fP .RS 4 That the resulting key is guaranteed to have a value, because meta information has no binary or null pointer semantics\&. .PP You must not delete or change the returned key, use \fBkeySetMeta()\fP if you want to delete or change it\&. .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturns:\fP .RS 4 a key representing meta information .RE .PP \fBReturn values:\fP .RS 4 \fI0\fP when the end is reached .br \fI0\fP on NULL pointer .RE .PP \fBSee also:\fP .RS 4 \fBksNext()\fP for pedant in iterator interface of \fBKeySet\fP .PP \fBrewindMeta()\fP, \fBcurrentMeta()\fP .RE .PP .SS "kdb::Key::operator bool () const\fC [inline]\fP" .PP This is for loops and lookups only\&. Opposite of \fBisNull()\fP .PP For loops it checks if there are still more keys\&. For lookups it checks if a key could be found\&. .PP \fBWarning:\fP .RS 4 you should not construct or use null keys .RE .PP \fBSee also:\fP .RS 4 \fBisNull()\fP, \fBisValid()\fP .RE .PP \fBReturns:\fP .RS 4 false on null keys .PP true otherwise .RE .PP .SS "bool kdb::Key::operator!= (const \fBKey\fP & k) const\fC [inline]\fP" .PP Compare the name of two keys\&. .PP \fBReturns:\fP .RS 4 a number less than, equal to or greater than zero if k1 is found, respectively, to be less than, to match, or be greater than k2\&. .RE .PP The comparison is based on a strcmp of the keynames, and iff they match a strcmp of the owner will be used to distuingish\&. If even this matches the keys are found to be exactly the same and 0 is returned\&. These two keys can't be used in the same \fBKeySet\fP\&. .PP \fBkeyCmp()\fP defines the sorting order for a \fBKeySet\fP\&. .PP The following 3 points are the rules for null values: .PP .IP "\(bu" 2 A null pointer will be found to be smaller than every other key\&. If both are null pointers, 0 is returned\&. .IP "\(bu" 2 A null name will be found to be smaller than every other name\&. If both are null names, 0 is returned\&. .PP .PP If the name is equal then: .PP .IP "\(bu" 2 No owner will be found to be smaller then every other owner\&. If both don't have a owner, 0 is returned\&. .PP .PP \fBNote:\fP .RS 4 the owner will only be used if the names are equal\&. .RE .PP Often is enough to know if the other key is less then or greater then the other one\&. But Sometimes you need more precise information, see \fBkeyRel()\fP\&. .PP Given any Keys k1 and k2 constructed with \fBkeyNew()\fP, following equation hold true: .PP .PP .nf .fi .PP Here are some more examples: .PP .nf Key *k1 = keyNew("user/a", KEY_END); Key *k2 = keyNew("user/b", KEY_END); // keyCmp(k1,k2) < 0 // keyCmp(k2,k1) > 0 .fi .PP .PP And even more: .PP .nf Key *k1 = keyNew("user/a", KEY_OWNER, "markus", KEY_END); Key *k2 = keyNew("user/a", KEY_OWNER, "max", KEY_END); // keyCmp(k1,k2) < 0 // keyCmp(k2,k1) > 0 .fi .PP .PP Do not strcmp the \fBkeyName()\fP yourself because the result differs from simple ascii comparison\&. .PP \fBParameters:\fP .RS 4 \fIk1\fP the first key object to compare with .br \fIk2\fP the second key object to compare with .RE .PP \fBSee also:\fP .RS 4 \fBksAppendKey()\fP, \fBksAppend()\fP will compare keys when appending .PP \fBksLookup()\fP will compare keys during searching .RE .PP \fBReturn values:\fP .RS 4 \fItrue\fP != 0 .RE .PP .SS "ckdb::Key * kdb::Key::operator* () const\fC [inline]\fP" .PP Is a abbreviation for getKey\&. Passes out the raw key pointer\&. This pointer can be used to directly change the underlying key object\&. .PP \fBNote:\fP .RS 4 that the ownership remains in the object .RE .PP \fBSee also:\fP .RS 4 \fBgetKey()\fP .RE .PP .SS "void kdb::Key::operator++ (int) const\fC [inline]\fP" .PP Increment the viability of a key object\&. This function is intended for applications using their own reference counter for key objects\&. With it you can increment the reference and thus avoid destruction of the object in a subsequent \fBkeyDel()\fP\&. .PP The reference counter can't be incremented once it reached SSIZE_MAX\&. In that situation nothing will happen and SSIZE_MAX will be returned\&. .PP \fBNote:\fP .RS 4 \fBkeyDup()\fP will reset the references for dupped key\&. .RE .PP \fBReturns:\fP .RS 4 the value of the new reference counter .RE .PP \fBReturn values:\fP .RS 4 \fI-1\fP on null pointer .br \fISSIZE_MAX\fP when maximum exceeded .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetRef()\fP for longer explanation, \fBkeyDecRef()\fP, \fBkeyDel()\fP .RE .PP .SS "void kdb::Key::operator++ () const\fC [inline]\fP" .PP Increment the viability of a key object\&. This function is intended for applications using their own reference counter for key objects\&. With it you can increment the reference and thus avoid destruction of the object in a subsequent \fBkeyDel()\fP\&. .PP The reference counter can't be incremented once it reached SSIZE_MAX\&. In that situation nothing will happen and SSIZE_MAX will be returned\&. .PP \fBNote:\fP .RS 4 \fBkeyDup()\fP will reset the references for dupped key\&. .RE .PP \fBReturns:\fP .RS 4 the value of the new reference counter .RE .PP \fBReturn values:\fP .RS 4 \fI-1\fP on null pointer .br \fISSIZE_MAX\fP when maximum exceeded .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetRef()\fP for longer explanation, \fBkeyDecRef()\fP, \fBkeyDel()\fP .RE .PP .SS "void kdb::Key::operator\-\- (int) const\fC [inline]\fP" .PP Decrement the viability of a key object\&. The references will be decremented for \fBksPop()\fP or successful calls of \fBksLookup()\fP with the option KDB_O_POP\&. It will also be decremented with an following \fBkeyDel()\fP in the case that an old key is replaced with another key with the same name\&. .PP The reference counter can't be decremented once it reached 0\&. In that situation nothing will happen and 0 will be returned\&. .PP \fBNote:\fP .RS 4 \fBkeyDup()\fP will reset the references for dupped key\&. .RE .PP \fBReturns:\fP .RS 4 the value of the new reference counter .RE .PP \fBReturn values:\fP .RS 4 \fI-1\fP on null pointer .br \fI0\fP when the key is ready to be freed .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetRef()\fP for longer explanation, \fBkeyDel()\fP, \fBkeyIncRef()\fP .RE .PP .SS "void kdb::Key::operator\-\- () const\fC [inline]\fP" .PP Decrement the viability of a key object\&. The references will be decremented for \fBksPop()\fP or successful calls of \fBksLookup()\fP with the option KDB_O_POP\&. It will also be decremented with an following \fBkeyDel()\fP in the case that an old key is replaced with another key with the same name\&. .PP The reference counter can't be decremented once it reached 0\&. In that situation nothing will happen and 0 will be returned\&. .PP \fBNote:\fP .RS 4 \fBkeyDup()\fP will reset the references for dupped key\&. .RE .PP \fBReturns:\fP .RS 4 the value of the new reference counter .RE .PP \fBReturn values:\fP .RS 4 \fI-1\fP on null pointer .br \fI0\fP when the key is ready to be freed .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetRef()\fP for longer explanation, \fBkeyDel()\fP, \fBkeyIncRef()\fP .RE .PP .SS "\fBKey\fP * kdb::Key::operator\-> ()\fC [inline]\fP" .PP \fBReturns:\fP .RS 4 a pointer to this object .RE .PP Needed for \fBKeySet\fP iterators\&. .PP \fBSee also:\fP .RS 4 \fBKeySetIterator\fP .RE .PP .SS "bool kdb::Key::operator< (const \fBKey\fP & other) const\fC [inline]\fP" .PP Compare the name of two keys\&. .PP \fBReturns:\fP .RS 4 a number less than, equal to or greater than zero if k1 is found, respectively, to be less than, to match, or be greater than k2\&. .RE .PP The comparison is based on a strcmp of the keynames, and iff they match a strcmp of the owner will be used to distuingish\&. If even this matches the keys are found to be exactly the same and 0 is returned\&. These two keys can't be used in the same \fBKeySet\fP\&. .PP \fBkeyCmp()\fP defines the sorting order for a \fBKeySet\fP\&. .PP The following 3 points are the rules for null values: .PP .IP "\(bu" 2 A null pointer will be found to be smaller than every other key\&. If both are null pointers, 0 is returned\&. .IP "\(bu" 2 A null name will be found to be smaller than every other name\&. If both are null names, 0 is returned\&. .PP .PP If the name is equal then: .PP .IP "\(bu" 2 No owner will be found to be smaller then every other owner\&. If both don't have a owner, 0 is returned\&. .PP .PP \fBNote:\fP .RS 4 the owner will only be used if the names are equal\&. .RE .PP Often is enough to know if the other key is less then or greater then the other one\&. But Sometimes you need more precise information, see \fBkeyRel()\fP\&. .PP Given any Keys k1 and k2 constructed with \fBkeyNew()\fP, following equation hold true: .PP .PP .nf .fi .PP Here are some more examples: .PP .nf Key *k1 = keyNew("user/a", KEY_END); Key *k2 = keyNew("user/b", KEY_END); // keyCmp(k1,k2) < 0 // keyCmp(k2,k1) > 0 .fi .PP .PP And even more: .PP .nf Key *k1 = keyNew("user/a", KEY_OWNER, "markus", KEY_END); Key *k2 = keyNew("user/a", KEY_OWNER, "max", KEY_END); // keyCmp(k1,k2) < 0 // keyCmp(k2,k1) > 0 .fi .PP .PP Do not strcmp the \fBkeyName()\fP yourself because the result differs from simple ascii comparison\&. .PP \fBParameters:\fP .RS 4 \fIk1\fP the first key object to compare with .br \fIk2\fP the second key object to compare with .RE .PP \fBSee also:\fP .RS 4 \fBksAppendKey()\fP, \fBksAppend()\fP will compare keys when appending .PP \fBksLookup()\fP will compare keys during searching .RE .PP \fBReturn values:\fP .RS 4 \fItrue\fP < 0 .RE .PP .SS "bool kdb::Key::operator<= (const \fBKey\fP & other) const\fC [inline]\fP" .PP Compare the name of two keys\&. .PP \fBReturns:\fP .RS 4 a number less than, equal to or greater than zero if k1 is found, respectively, to be less than, to match, or be greater than k2\&. .RE .PP The comparison is based on a strcmp of the keynames, and iff they match a strcmp of the owner will be used to distuingish\&. If even this matches the keys are found to be exactly the same and 0 is returned\&. These two keys can't be used in the same \fBKeySet\fP\&. .PP \fBkeyCmp()\fP defines the sorting order for a \fBKeySet\fP\&. .PP The following 3 points are the rules for null values: .PP .IP "\(bu" 2 A null pointer will be found to be smaller than every other key\&. If both are null pointers, 0 is returned\&. .IP "\(bu" 2 A null name will be found to be smaller than every other name\&. If both are null names, 0 is returned\&. .PP .PP If the name is equal then: .PP .IP "\(bu" 2 No owner will be found to be smaller then every other owner\&. If both don't have a owner, 0 is returned\&. .PP .PP \fBNote:\fP .RS 4 the owner will only be used if the names are equal\&. .RE .PP Often is enough to know if the other key is less then or greater then the other one\&. But Sometimes you need more precise information, see \fBkeyRel()\fP\&. .PP Given any Keys k1 and k2 constructed with \fBkeyNew()\fP, following equation hold true: .PP .PP .nf .fi .PP Here are some more examples: .PP .nf Key *k1 = keyNew("user/a", KEY_END); Key *k2 = keyNew("user/b", KEY_END); // keyCmp(k1,k2) < 0 // keyCmp(k2,k1) > 0 .fi .PP .PP And even more: .PP .nf Key *k1 = keyNew("user/a", KEY_OWNER, "markus", KEY_END); Key *k2 = keyNew("user/a", KEY_OWNER, "max", KEY_END); // keyCmp(k1,k2) < 0 // keyCmp(k2,k1) > 0 .fi .PP .PP Do not strcmp the \fBkeyName()\fP yourself because the result differs from simple ascii comparison\&. .PP \fBParameters:\fP .RS 4 \fIk1\fP the first key object to compare with .br \fIk2\fP the second key object to compare with .RE .PP \fBSee also:\fP .RS 4 \fBksAppendKey()\fP, \fBksAppend()\fP will compare keys when appending .PP \fBksLookup()\fP will compare keys during searching .RE .PP \fBReturn values:\fP .RS 4 \fItrue\fP <= 0 .RE .PP .SS "\fBKey\fP & kdb::Key::operator= (ckdb::Key * k)\fC [inline]\fP" .PP Assign a C key\&. Will call del() on the old key\&. .SS "\fBKey\fP & kdb::Key::operator= (const \fBKey\fP & k)\fC [inline]\fP" .PP Assign a key\&. Will call del() on the old key\&. .SS "bool kdb::Key::operator== (const \fBKey\fP & k) const\fC [inline]\fP" .PP Compare the name of two keys\&. .PP \fBReturns:\fP .RS 4 a number less than, equal to or greater than zero if k1 is found, respectively, to be less than, to match, or be greater than k2\&. .RE .PP The comparison is based on a strcmp of the keynames, and iff they match a strcmp of the owner will be used to distuingish\&. If even this matches the keys are found to be exactly the same and 0 is returned\&. These two keys can't be used in the same \fBKeySet\fP\&. .PP \fBkeyCmp()\fP defines the sorting order for a \fBKeySet\fP\&. .PP The following 3 points are the rules for null values: .PP .IP "\(bu" 2 A null pointer will be found to be smaller than every other key\&. If both are null pointers, 0 is returned\&. .IP "\(bu" 2 A null name will be found to be smaller than every other name\&. If both are null names, 0 is returned\&. .PP .PP If the name is equal then: .PP .IP "\(bu" 2 No owner will be found to be smaller then every other owner\&. If both don't have a owner, 0 is returned\&. .PP .PP \fBNote:\fP .RS 4 the owner will only be used if the names are equal\&. .RE .PP Often is enough to know if the other key is less then or greater then the other one\&. But Sometimes you need more precise information, see \fBkeyRel()\fP\&. .PP Given any Keys k1 and k2 constructed with \fBkeyNew()\fP, following equation hold true: .PP .PP .nf .fi .PP Here are some more examples: .PP .nf Key *k1 = keyNew("user/a", KEY_END); Key *k2 = keyNew("user/b", KEY_END); // keyCmp(k1,k2) < 0 // keyCmp(k2,k1) > 0 .fi .PP .PP And even more: .PP .nf Key *k1 = keyNew("user/a", KEY_OWNER, "markus", KEY_END); Key *k2 = keyNew("user/a", KEY_OWNER, "max", KEY_END); // keyCmp(k1,k2) < 0 // keyCmp(k2,k1) > 0 .fi .PP .PP Do not strcmp the \fBkeyName()\fP yourself because the result differs from simple ascii comparison\&. .PP \fBParameters:\fP .RS 4 \fIk1\fP the first key object to compare with .br \fIk2\fP the second key object to compare with .RE .PP \fBSee also:\fP .RS 4 \fBksAppendKey()\fP, \fBksAppend()\fP will compare keys when appending .PP \fBksLookup()\fP will compare keys during searching .RE .PP \fBReturn values:\fP .RS 4 \fItrue\fP == 0 .RE .PP .SS "bool kdb::Key::operator> (const \fBKey\fP & other) const\fC [inline]\fP" .PP Compare the name of two keys\&. .PP \fBReturns:\fP .RS 4 a number less than, equal to or greater than zero if k1 is found, respectively, to be less than, to match, or be greater than k2\&. .RE .PP The comparison is based on a strcmp of the keynames, and iff they match a strcmp of the owner will be used to distuingish\&. If even this matches the keys are found to be exactly the same and 0 is returned\&. These two keys can't be used in the same \fBKeySet\fP\&. .PP \fBkeyCmp()\fP defines the sorting order for a \fBKeySet\fP\&. .PP The following 3 points are the rules for null values: .PP .IP "\(bu" 2 A null pointer will be found to be smaller than every other key\&. If both are null pointers, 0 is returned\&. .IP "\(bu" 2 A null name will be found to be smaller than every other name\&. If both are null names, 0 is returned\&. .PP .PP If the name is equal then: .PP .IP "\(bu" 2 No owner will be found to be smaller then every other owner\&. If both don't have a owner, 0 is returned\&. .PP .PP \fBNote:\fP .RS 4 the owner will only be used if the names are equal\&. .RE .PP Often is enough to know if the other key is less then or greater then the other one\&. But Sometimes you need more precise information, see \fBkeyRel()\fP\&. .PP Given any Keys k1 and k2 constructed with \fBkeyNew()\fP, following equation hold true: .PP .PP .nf .fi .PP Here are some more examples: .PP .nf Key *k1 = keyNew("user/a", KEY_END); Key *k2 = keyNew("user/b", KEY_END); // keyCmp(k1,k2) < 0 // keyCmp(k2,k1) > 0 .fi .PP .PP And even more: .PP .nf Key *k1 = keyNew("user/a", KEY_OWNER, "markus", KEY_END); Key *k2 = keyNew("user/a", KEY_OWNER, "max", KEY_END); // keyCmp(k1,k2) < 0 // keyCmp(k2,k1) > 0 .fi .PP .PP Do not strcmp the \fBkeyName()\fP yourself because the result differs from simple ascii comparison\&. .PP \fBParameters:\fP .RS 4 \fIk1\fP the first key object to compare with .br \fIk2\fP the second key object to compare with .RE .PP \fBSee also:\fP .RS 4 \fBksAppendKey()\fP, \fBksAppend()\fP will compare keys when appending .PP \fBksLookup()\fP will compare keys during searching .RE .PP \fBReturn values:\fP .RS 4 \fItrue\fP > 0 .RE .PP .SS "bool kdb::Key::operator>= (const \fBKey\fP & other) const\fC [inline]\fP" .PP Compare the name of two keys\&. .PP \fBReturns:\fP .RS 4 a number less than, equal to or greater than zero if k1 is found, respectively, to be less than, to match, or be greater than k2\&. .RE .PP The comparison is based on a strcmp of the keynames, and iff they match a strcmp of the owner will be used to distuingish\&. If even this matches the keys are found to be exactly the same and 0 is returned\&. These two keys can't be used in the same \fBKeySet\fP\&. .PP \fBkeyCmp()\fP defines the sorting order for a \fBKeySet\fP\&. .PP The following 3 points are the rules for null values: .PP .IP "\(bu" 2 A null pointer will be found to be smaller than every other key\&. If both are null pointers, 0 is returned\&. .IP "\(bu" 2 A null name will be found to be smaller than every other name\&. If both are null names, 0 is returned\&. .PP .PP If the name is equal then: .PP .IP "\(bu" 2 No owner will be found to be smaller then every other owner\&. If both don't have a owner, 0 is returned\&. .PP .PP \fBNote:\fP .RS 4 the owner will only be used if the names are equal\&. .RE .PP Often is enough to know if the other key is less then or greater then the other one\&. But Sometimes you need more precise information, see \fBkeyRel()\fP\&. .PP Given any Keys k1 and k2 constructed with \fBkeyNew()\fP, following equation hold true: .PP .PP .nf .fi .PP Here are some more examples: .PP .nf Key *k1 = keyNew("user/a", KEY_END); Key *k2 = keyNew("user/b", KEY_END); // keyCmp(k1,k2) < 0 // keyCmp(k2,k1) > 0 .fi .PP .PP And even more: .PP .nf Key *k1 = keyNew("user/a", KEY_OWNER, "markus", KEY_END); Key *k2 = keyNew("user/a", KEY_OWNER, "max", KEY_END); // keyCmp(k1,k2) < 0 // keyCmp(k2,k1) > 0 .fi .PP .PP Do not strcmp the \fBkeyName()\fP yourself because the result differs from simple ascii comparison\&. .PP \fBParameters:\fP .RS 4 \fIk1\fP the first key object to compare with .br \fIk2\fP the second key object to compare with .RE .PP \fBSee also:\fP .RS 4 \fBksAppendKey()\fP, \fBksAppend()\fP will compare keys when appending .PP \fBksLookup()\fP will compare keys during searching .RE .PP \fBReturn values:\fP .RS 4 \fItrue\fP >= 0 .RE .PP .SS "ckdb::Key * kdb::Key::release ()\fC [inline]\fP" .PP Passes out the raw key pointer and resets internal key handle\&. .PP \fBNote:\fP .RS 4 that the ownership is moved outside\&. .RE .PP \fBReturn values:\fP .RS 4 \fI0\fP if no key is held (null pointer), no action is done then\&. .RE .PP .SS "void kdb::Key::rewindMeta () const\fC [inline]\fP" .PP Rewind the internal iterator to first meta data\&. Use it to set the cursor to the beginning of the \fBKey\fP Meta Infos\&. \fBkeyCurrentMeta()\fP will then always return NULL afterwards\&. So you want to \fBkeyNextMeta()\fP first\&. .PP .PP .nf Key *key; const Key *meta; keyRewindMeta (key); while ((meta = keyNextMeta (key))!=0) { printf ("name: %s, value: %s", keyName(meta), (const char*)keyValue(meta)); } .fi .PP .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturn values:\fP .RS 4 \fI0\fP on success .br \fI0\fP if there is no meta information for that key (\fBkeyNextMeta()\fP will always return 0 in that case) .br \fI-1\fP on NULL pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeyNextMeta()\fP, \fBkeyCurrentMeta()\fP .PP \fBksRewind()\fP for pedant in iterator interface of \fBKeySet\fP .PP \fBnextMeta()\fP, \fBcurrentMeta()\fP .RE .PP .SS "template void kdb::Key::set (T x)\fC [inline]\fP" .PP Set a key value\&. Set the value for \fCkey\fP as \fCnewStringValue\fP\&. The function will allocate and save a private copy of \fCnewStringValue\fP, so the parameter can be freed after the call\&. .PP String values will be saved in backend storage, when kdbSetKey() will be called, in UTF-8 universal encoding, regardless of the program's current encoding, when iconv plugin is present\&. .PP \fBNote:\fP .RS 4 The type will be set to KEY_TYPE_STRING\&. When the type of the key is already a string type it won't be changed\&. .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key to set the string value .br \fInewStringValue\fP NULL-terminated text string to be set as \fCkey's\fP value .RE .PP \fBReturns:\fP .RS 4 the number of bytes actually saved in private struct including final NULL .RE .PP \fBReturn values:\fP .RS 4 \fI1\fP if newStringValue is a NULL pointer, this will make the string empty (string only containing null termination) .br \fI-1\fP if key is a NULL pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetString()\fP, \fBkeyValue()\fP, \fBkeyString()\fP .RE .PP This method tries to deserialise the string to the given type\&. .SS "void kdb::Key::setBaseName (const std::string & baseName)\fC [inline]\fP" .PP Sets a base name for a key\&. Sets \fCbaseName\fP as the new basename for \fCkey\fP\&. Only the baseName will be affected and no other part of the key\&. .PP All text after the last \fC'/'\fP in the \fCkey\fP keyname is erased and \fCbaseName\fP is appended\&. .PP So let us suppose \fCkey\fP has name \fC'system/dir1/dir2/key1'\fP\&. If \fCbaseName\fP is \fC'key2'\fP, the resulting key name will be \fC'system/dir1/dir2/key2'\fP\&. If \fCbaseName\fP is empty or NULL, the resulting key name will be \fC'system/dir1/dir2'\fP\&. .PP This function does proper escaping on the supplied name argument\&. .PP You can use all names to set as basename (e\&.g\&. \&. (dot), \&.\&. (dot-dot), % and '' (empty))\&. They will be properly escaped\&. .PP A simple example is: .PP .nf Key * k = keyNew("user/my/long/name", KEY_END); keySetBaseName(k, "myname"); printf ("%s\n", keyName(k)); // will print user/my/long/myname keyDel(k); .fi .PP If you want to add and not change the basename, use \fBkeyAddBaseName()\fP instead\&. If you do not want escaping, use \fBkeyAddName()\fP instead\&. .PP To add an inactive key name, use: .PP .nf keySetName (k, "system/valid"); keySetBaseName(k, "\&.hiddenkey"); succeed_if_same_string(keyName(k), "system/\&.hiddenkey"); succeed_if_same_string(keyBaseName(k), "\&.hiddenkey"); .fi .PP When you want to add an array item, use: .PP .nf keySetName (k, "system/valid"); keySetBaseName(k, ""); succeed_if_same_string(keyName(k), "system/%"); succeed_if_same_string(keyBaseName(k), ""); .fi .PP .PP \fBSee also:\fP .RS 4 \fBName Manipulation Methods\fP for more details on special names .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .br \fIbaseName\fP the string used to overwrite the basename of the key .RE .PP \fBReturns:\fP .RS 4 the size in bytes of the new key name .RE .PP \fBReturn values:\fP .RS 4 \fI-1\fP on NULL pointers .br \fI-1\fP if key was inserted to a keyset before .RE .PP \fBSee also:\fP .RS 4 \fBkeyAddBaseName()\fP .PP \fBkeySetName()\fP to \fBset\fP a new name .RE .PP \fBExceptions:\fP .RS 4 \fIKeyInvalidName\fP if the name is not valid .RE .PP .SS "ssize_t kdb::Key::setBinary (const void * newBinary, size_t dataSize)\fC [inline]\fP" .PP Set the value of a key as a binary\&. A private copy of \fCnewBinary\fP will allocated and saved inside \fCkey\fP, so the parameter can be deallocated after the call\&. .PP Binary values might be encoded in another way then string values depending on the plugin\&. Typically character encodings should not take place on binary data\&. Consider using a string key instead\&. .PP When newBinary is a NULL pointer the binary will be freed and 0 will be returned\&. .PP \fBNote:\fP .RS 4 The meta data 'binary' will be set to mark that the key is binary from now on\&. When the key is already binary the meta data won't be changed\&. This will only happen in the successful case, but not when -1 is returned\&. .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the object on which to set the value .br \fInewBinary\fP is a pointer to any binary data or NULL to free the previous set data .br \fIdataSize\fP number of bytes to copy from \fCnewBinary\fP .RE .PP \fBReturns:\fP .RS 4 the number of bytes actually copied to internal struct storage .RE .PP \fBReturn values:\fP .RS 4 \fI0\fP when the internal binary was freed and is now a null pointer .br \fI-1\fP if key is a NULL pointer .br \fI-1\fP when dataSize is 0 (but newBinary not NULL) or larger than SSIZE_MAX .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetBinary()\fP .PP \fBkeyIsBinary()\fP to check if the type is binary .PP \fBkeyGetString()\fP and \fBkeySetString()\fP as preferred alternative to binary .RE .PP .SS "template void kdb::Key::setMeta (const std::string & metaName, T x)\fC [inline]\fP" .PP Set metadata for key\&. Set a new Meta-Information\&. Will set a new Meta-Information pair consisting of metaName and newMetaString\&. .PP Will add a new Pair for Meta-Information if metaName was not added up to now\&. .PP It will modify a existing Pair of Meta-Information if the the metaName was inserted already\&. .PP It will remove a meta information if newMetaString is 0\&. .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .br \fImetaName\fP the name of the meta information where you want to change the value .br \fInewMetaString\fP the new value for the meta information .RE .PP \fBReturn values:\fP .RS 4 \fI-1\fP on error if key or metaName is 0, out of memory or names are not valid .br \fI0\fP if the Meta-Information for metaName was removed .RE .PP \fBReturns:\fP .RS 4 size (>0) of newMetaString if Meta-Information was successfully added .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetMeta()\fP .RE .PP \fBWarning:\fP .RS 4 unlike the C Interface, it is not possible to remove metadata with this method\&. k\&.setMeta('something', NULL) will lead to set the number 0 or to something different (may depend on compiler definition of NULL)\&. See discussion in Issue https://github.com/ElektraInitiative/libelektra/issues/8 .RE .PP Use \fBdelMeta()\fP to avoid these issues\&. .PP \fBSee also:\fP .RS 4 \fBdelMeta()\fP, \fBgetMeta()\fP, \fBcopyMeta()\fP, \fBcopyAllMeta()\fP .RE .PP .SS "void kdb::Key::setName (const std::string & newName)\fC [inline]\fP" .PP Set a new name to a key\&. A valid name is one of the forms: .IP "\(bu" 2 \fCspec/something\fP for specification of other keys\&. .IP "\(bu" 2 \fCproc/something\fP for in-memory keys, e\&.g\&. commandline\&. .IP "\(bu" 2 \fCdir/something\fP for dir keys in current working directory .IP "\(bu" 2 \fCsystem/something\fP for system keys in /etc or / .IP "\(bu" 2 \fCuser/something\fP for user keys in home directory .IP "\(bu" 2 \fCuser:username/something\fP for other users (deprecated: \fBkdbGet()\fP + \fBkdbSet()\fP currently unsupported) .IP "\(bu" 2 \fC/something\fP for cascading keys (actually refers to one of the above, see also \fBksLookup()\fP) .PP .PP An invalid name either has an invalid namespace or a wrongly escaped \\ at the end of the name\&. .PP See \fBkey names \fP for the exact rules\&. .PP The last form has explicitly set the owner, to let the library know in which user folder to save the key\&. A owner is a user name\&. If it is not defined (the second form) current user is used\&. .PP You should always follow the guidelines for key tree structure creation\&. .PP A private copy of the key name will be stored, and the \fCnewName\fP parameter can be freed after this call\&. .PP \&.\&., \&. and / will be handled as in filesystem pathes\&. A valid name will be build out of the (valid) name what you pass, e\&.g\&. user///sw/\&.\&./sw//\&./\&./MyApp -> user/sw/MyApp .PP On invalid names, NULL or '' the name will be '' afterwards\&. .PP \fBReturn values:\fP .RS 4 \fIsize\fP in bytes of this new key name including ending NULL .br \fI0\fP if newName is an empty string or a NULL pointer (name will be empty afterwards) .br \fI-1\fP if newName is invalid (name will be empty afterwards) .br \fI-1\fP if key was inserted to a keyset before .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .br \fInewName\fP the new key name .RE .PP \fBSee also:\fP .RS 4 \fBkeyNew()\fP, \fBkeySetOwner()\fP .PP \fBkeyGetName()\fP, \fBkeyGetFullName()\fP, \fBkeyName()\fP .PP \fBkeySetBaseName()\fP, \fBkeyAddBaseName()\fP to manipulate a name .RE .PP \fBExceptions:\fP .RS 4 \fIKeyInvalidName\fP if the name is not valid .RE .PP .SS "void kdb::Key::setString (std::string newString)\fC [inline]\fP" .PP Set the value for \fCkey\fP as \fCnewStringValue\fP\&. The function will allocate and save a private copy of \fCnewStringValue\fP, so the parameter can be freed after the call\&. .PP String values will be saved in backend storage, when kdbSetKey() will be called, in UTF-8 universal encoding, regardless of the program's current encoding, when iconv plugin is present\&. .PP \fBNote:\fP .RS 4 The type will be set to KEY_TYPE_STRING\&. When the type of the key is already a string type it won't be changed\&. .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key to set the string value .br \fInewStringValue\fP NULL-terminated text string to be set as \fCkey's\fP value .RE .PP \fBReturns:\fP .RS 4 the number of bytes actually saved in private struct including final NULL .RE .PP \fBReturn values:\fP .RS 4 \fI1\fP if newStringValue is a NULL pointer, this will make the string empty (string only containing null termination) .br \fI-1\fP if key is a NULL pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetString()\fP, \fBkeyValue()\fP, \fBkeyString()\fP .RE .PP .SH "Author" .PP Generated automatically by Doxygen for Elektra from the source code\&.