.TH "kdb::Key" 3elektra "Tue Aug 19 2014" "Version 0.8.7" "Elektra" \" -*- nroff -*- .ad l .nh .SH NAME kdb::Key \- .PP A \fBKey\fP is the 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 .ti -1c .RI "\fBKey\fP (ckdb::Key *k)" .br .ti -1c .RI "\fBKey\fP (\fBKey\fP &k)" .br .ti -1c .RI "\fBKey\fP (\fBKey\fP const &k)" .br .ti -1c .RI "\fBKey\fP (const char *\fBkeyName\fP,\&.\&.\&.)" .br .ti -1c .RI "\fBKey\fP (const std::string \fBkeyName\fP,\&.\&.\&.)" .br .ti -1c .RI "\fBKey\fP (const char *\fBkeyName\fP, va_list ap)" .br .ti -1c .RI "void \fBoperator++\fP (int) const " .br .ti -1c .RI "void \fBoperator++\fP () const " .br .ti -1c .RI "void \fBoperator--\fP (int) const " .br .ti -1c .RI "void \fBoperator--\fP () const " .br .ti -1c .RI "ssize_t \fBgetReferenceCounter\fP () const " .br .ti -1c .RI "\fBKey\fP & \fBoperator=\fP (ckdb::Key *k)" .br .ti -1c .RI "\fBKey\fP & \fBoperator=\fP (const \fBKey\fP &k)" .br .ti -1c .RI "void \fBcopy\fP (const \fBKey\fP &other)" .br .ti -1c .RI "void \fBclear\fP ()" .br .ti -1c .RI "\fBKey\fP * \fBoperator->\fP ()" .br .ti -1c .RI "ckdb::Key * \fBgetKey\fP () const " .br .ti -1c .RI "ckdb::Key * \fBoperator*\fP () const " .br .ti -1c .RI "ckdb::Key * \fBrelease\fP ()" .br .ti -1c .RI "ckdb::Key * \fBdup\fP () const " .br .ti -1c .RI "\fB~Key\fP ()" .br .ti -1c .RI "std::string \fBgetName\fP () const " .br .ti -1c .RI "ssize_t \fBgetNameSize\fP () const " .br .ti -1c .RI "std::string \fBgetBaseName\fP () const " .br .ti -1c .RI "ssize_t \fBgetBaseNameSize\fP () const " .br .ti -1c .RI "std::string \fBgetDirName\fP () const " .br .ti -1c .RI "void \fBsetName\fP (const std::string &newName)" .br .ti -1c .RI "void \fBsetBaseName\fP (const std::string &baseName)" .br .ti -1c .RI "void \fBaddBaseName\fP (const std::string &baseName)" .br .ti -1c .RI "ssize_t \fBgetFullNameSize\fP () const " .br .ti -1c .RI "std::string \fBgetFullName\fP () const " .br .ti -1c .RI "\fBKey\fP & \fBoperator=\fP (const std::string &newName)" .br .ti -1c .RI "\fBKey\fP & \fBoperator+=\fP (const std::string &baseName)" .br .ti -1c .RI "\fBKey\fP & \fBoperator-=\fP (const std::string &baseName)" .br .ti -1c .RI "\fBKey\fP & \fBoperator=\fP (const char *newName)" .br .RI "\fI(const std::string &newName) \fP" .ti -1c .RI "\fBKey\fP & \fBoperator+=\fP (const char *baseName)" .br .RI "\fI(const std::string &) \fP" .ti -1c .RI "\fBKey\fP & \fBoperator-=\fP (const char *baseName)" .br .RI "\fI(const std::string &) \fP" .ti -1c .RI "bool \fBoperator==\fP (const \fBKey\fP &k) const " .br .ti -1c .RI "bool \fBoperator!=\fP (const \fBKey\fP &k) const " .br .ti -1c .RI "bool \fBoperator<\fP (const \fBKey\fP &other) const " .br .ti -1c .RI "bool \fBoperator<=\fP (const \fBKey\fP &other) const " .br .ti -1c .RI "bool \fBoperator>\fP (const \fBKey\fP &other) const " .br .ti -1c .RI "bool \fBoperator>=\fP (const \fBKey\fP &other) const " .br .ti -1c .RI "\fBoperator bool\fP () const " .br .ti -1c .RI "template T \fBget\fP () const " .br .ti -1c .RI "template void \fBset\fP (T x)" .br .ti -1c .RI "std::string \fBgetString\fP () const " .br .ti -1c .RI "void \fBsetString\fP (std::string newString)" .br .ti -1c .RI "ssize_t \fBgetStringSize\fP () const " .br .ti -1c .RI "func_t \fBgetFunc\fP () const " .br .ti -1c .RI "const void * \fBgetValue\fP () const " .br .ti -1c .RI "std::string \fBgetBinary\fP () const " .br .ti -1c .RI "ssize_t \fBgetBinarySize\fP () const " .br .ti -1c .RI "ssize_t \fBsetBinary\fP (const void *newBinary, size_t dataSize)" .br .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 .ti -1c .RI "template void \fBsetMeta\fP (const std::string &metaName, T x)" .br .ti -1c .RI "void \fBdelMeta\fP (const std::string &metaName)" .br .ti -1c .RI "void \fBcopyMeta\fP (const \fBKey\fP &other, const std::string &metaName)" .br .ti -1c .RI "void \fBcopyAllMeta\fP (const \fBKey\fP &other)" .br .ti -1c .RI "void \fBrewindMeta\fP () const " .br .ti -1c .RI "const \fBKey\fP \fBnextMeta\fP ()" .br .ti -1c .RI "const \fBKey\fP \fBcurrentMeta\fP () const " .br .ti -1c .RI "bool \fBisValid\fP () const " .br .ti -1c .RI "bool \fBisSystem\fP () const " .br .ti -1c .RI "bool \fBisUser\fP () const " .br .ti -1c .RI "bool \fBisString\fP () const " .br .ti -1c .RI "bool \fBisBinary\fP () const " .br .ti -1c .RI "bool \fBisInactive\fP () const " .br .ti -1c .RI "bool \fBisBelow\fP (const \fBKey\fP &k) const " .br .ti -1c .RI "bool \fBisBelowOrSame\fP (const \fBKey\fP &k) const " .br .ti -1c .RI "bool \fBisDirectBelow\fP (const \fBKey\fP &k) const " .br .in -1c .SH "Detailed Description" .PP A \fBKey\fP is the essential class that encapsulates key \fBname \fP, \fBvalue \fP and \fBmetainfo \fP\&. 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 operator bool()\&. .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 operator bool())\&. .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" 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, operator bool() .RE .PP .SS "kdb::Key::Key (ckdb::Key *k)\fC [inline]\fP" 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, operator bool() .RE .PP .SS "kdb::Key::Key (\fBKey\fP &k)\fC [inline]\fP" Takes a reference of another key\&. .PP 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" Takes a reference of another key\&. .PP 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\&. .PP This function tries to mimic the C++ way for constructors\&. .PP To just get a key object, simple do: .PP .nf Key *k = keyNew(0); // work with it keyDel (k); .fi .PP .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 and cheaper to \fBkeyDup()\fP the key\&. .RE .PP 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\&. See http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN135 .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 The simplest and minimum way to use it is with no tags, only a key name: .PP .nf Key *nullKey,*emptyNamedKey; // Create a key that has no name, is completely empty, but is initialized nullKey=keyNew(0); keyDel (nullKey); // Is the same as above nullKey=keyNew("", KEY_END); keyDel (nullKey); // Create and initialize a key with a name and nothing else emptyNamedKey=keyNew("user/some/example",KEY_END); keyDel (emptyNamedKey); .fi .PP .PP \fBkeyNew()\fP allocates memory for a key object and cleans everything up\&. After that, it processes the given argument list\&. .PP The \fBKey\fP attribute tags are the following: .IP "\(bu" 2 keyswitch_t::KEY_TYPE .br Next parameter is a type of the value\&. Default assumed is KEY_TYPE_UNDEFINED\&. Set this attribute so that a subsequent KEY_VALUE can toggle to \fBkeySetString()\fP or \fBkeySetBinary()\fP regarding to \fBkeyIsString()\fP or \fBkeyIsBinary()\fP\&. If you don't use KEY_TYPE but a KEY_VALUE follows afterwards, KEY_TYPE_STRING will be used\&. .IP "\(bu" 2 keyswitch_t::KEY_SIZE .br Define a maximum length of the value\&. This is especially useful for setting a binary key\&. So make sure you use that before you KEY_VALUE for binary keys\&. .IP "\(bu" 2 keyswitch_t::KEY_VALUE .br Next parameter is a pointer to the value that will be set to the key If no keyswitch_t::KEY_TYPE was used before, keyswitch_t::KEY_TYPE_STRING is assumed\&. If KEY_TYPE was previously passed with a KEY_TYPE_BINARY, you should have passed KEY_SIZE before! Otherwise it will be cut of with first \\0 in string! .IP "\(bu" 2 keyswitch_t::KEY_UID, \fCkeyswitch_t::KEY_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 keyswitch_t::KEY_MODE .br Next parameter is taken as mode permissions (int) to the key\&. See \fBkeySetMode()\fP\&. .IP "\(bu" 2 keyswitch_t::KEY_DIR .br Define that the key is a directory rather than a ordinary key\&. This means its executable bits in its mode are set\&. This option allows the key to have subkeys\&. See \fBkeySetDir()\fP\&. .IP "\(bu" 2 keyswitch_t::KEY_OWNER .br Next parameter is the owner\&. See \fBkeySetOwner()\fP\&. .IP "\(bu" 2 keyswitch_t::KEY_COMMENT .br Next parameter is a comment\&. See \fBkeySetComment()\fP\&. .IP "\(bu" 2 keyswitch_t::KEY_END .br Must be the last parameter passed to \fBkeyNew()\fP\&. It is always required, unless the \fCkeyName\fP is 0\&. .PP .PP \fBExample:\fP .RS 4 .PP .nf KeySet *ks=ksNew(0); ksAppendKey(ks,keyNew(0)); // an empty key ksAppendKey(ks,keyNew("user/sw", // the name of the key KEY_END)); // no more args ksAppendKey(ks,keyNew("user/tmp/ex1", KEY_VALUE,"some data", // set a string value KEY_END)); // end of args ksAppendKey(ks,keyNew("user/tmp/ex2", KEY_VALUE,"some data", // with a simple value KEY_MODE,0777, // permissions KEY_END)); // end of args ksAppendKey(ks,keyNew("user/tmp/ex4", KEY_TYPE,KEY_TYPE_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 ksAppendKey(ks,keyNew("user/tmp/ex5", KEY_TYPE, KEY_TYPE_DIR | KEY_TYPE_BINARY,// dir key with a binary value KEY_SIZE,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 ksDel(ks); .fi .PP .RE .PP The reference counter (see \fBkeyGetRef()\fP) 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 keyInc()) and the key can't be be deleted by a \fBkeyDel()\fP\&. .PP .PP .nf Key *k = keyNew(0); // ref counter 0 ksAppendKey(ks, k); // ref counter of key 1 ksDel(ks); // key will be deleted with keyset .fi .PP .PP If you increment only by one with keyInc() the same as said above is valid: .PP .PP .nf Key *k = keyNew(0); // ref counter 0 keyIncRef(k); // ref counter of key 1 keyDel(k); // has no effect keyDecRef(k); // ref counter back to 0 keyDel(k); // key is now deleted .fi .PP .PP If you add the key to more keySets: .PP .PP .nf Key *k = keyNew(0); // ref counter 0 ksAppendKey(ks1, k); // ref counter of key 1 ksAppendKey(ks2, k); // ref counter of key 2 ksDel(ks1); // ref counter of key 1 ksDel(ks2); // k is now deleted .fi .PP .PP or use keyInc() 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 .PP they key won't be deleted by a \fBkeyDel()\fP as long refcounter is not 0\&. .PP The key's sync bit will always be set for any call, except: .PP .nf Key *k = keyNew(0); // keyNeedSync() will be false .fi .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 \fIKeyInvalidName\fP if key could not be constructed (typically name wrong or at runtime on allocation problems) .RE .PP \fBParameters:\fP .RS 4 \fIkeyName\fP the name of the new key .RE .PP .SS "kdb::Key::Key (const std::stringkeyName, \&.\&.\&.)\fC [inline]\fP, \fC [explicit]\fP" .PP A practical way to fully create a \fBKey\fP object in one step\&. .PP This function tries to mimic the C++ way for constructors\&. .PP To just get a key object, simple do: .PP .nf Key *k = keyNew(0); // work with it keyDel (k); .fi .PP .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 and cheaper to \fBkeyDup()\fP the key\&. .RE .PP 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\&. See http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN135 .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 The simplest and minimum way to use it is with no tags, only a key name: .PP .nf Key *nullKey,*emptyNamedKey; // Create a key that has no name, is completely empty, but is initialized nullKey=keyNew(0); keyDel (nullKey); // Is the same as above nullKey=keyNew("", KEY_END); keyDel (nullKey); // Create and initialize a key with a name and nothing else emptyNamedKey=keyNew("user/some/example",KEY_END); keyDel (emptyNamedKey); .fi .PP .PP \fBkeyNew()\fP allocates memory for a key object and cleans everything up\&. After that, it processes the given argument list\&. .PP The \fBKey\fP attribute tags are the following: .IP "\(bu" 2 keyswitch_t::KEY_TYPE .br Next parameter is a type of the value\&. Default assumed is KEY_TYPE_UNDEFINED\&. Set this attribute so that a subsequent KEY_VALUE can toggle to \fBkeySetString()\fP or \fBkeySetBinary()\fP regarding to \fBkeyIsString()\fP or \fBkeyIsBinary()\fP\&. If you don't use KEY_TYPE but a KEY_VALUE follows afterwards, KEY_TYPE_STRING will be used\&. .IP "\(bu" 2 keyswitch_t::KEY_SIZE .br Define a maximum length of the value\&. This is especially useful for setting a binary key\&. So make sure you use that before you KEY_VALUE for binary keys\&. .IP "\(bu" 2 keyswitch_t::KEY_VALUE .br Next parameter is a pointer to the value that will be set to the key If no keyswitch_t::KEY_TYPE was used before, keyswitch_t::KEY_TYPE_STRING is assumed\&. If KEY_TYPE was previously passed with a KEY_TYPE_BINARY, you should have passed KEY_SIZE before! Otherwise it will be cut of with first \\0 in string! .IP "\(bu" 2 keyswitch_t::KEY_UID, \fCkeyswitch_t::KEY_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 keyswitch_t::KEY_MODE .br Next parameter is taken as mode permissions (int) to the key\&. See \fBkeySetMode()\fP\&. .IP "\(bu" 2 keyswitch_t::KEY_DIR .br Define that the key is a directory rather than a ordinary key\&. This means its executable bits in its mode are set\&. This option allows the key to have subkeys\&. See \fBkeySetDir()\fP\&. .IP "\(bu" 2 keyswitch_t::KEY_OWNER .br Next parameter is the owner\&. See \fBkeySetOwner()\fP\&. .IP "\(bu" 2 keyswitch_t::KEY_COMMENT .br Next parameter is a comment\&. See \fBkeySetComment()\fP\&. .IP "\(bu" 2 keyswitch_t::KEY_END .br Must be the last parameter passed to \fBkeyNew()\fP\&. It is always required, unless the \fCkeyName\fP is 0\&. .PP .PP \fBExample:\fP .RS 4 .PP .nf KeySet *ks=ksNew(0); ksAppendKey(ks,keyNew(0)); // an empty key ksAppendKey(ks,keyNew("user/sw", // the name of the key KEY_END)); // no more args ksAppendKey(ks,keyNew("user/tmp/ex1", KEY_VALUE,"some data", // set a string value KEY_END)); // end of args ksAppendKey(ks,keyNew("user/tmp/ex2", KEY_VALUE,"some data", // with a simple value KEY_MODE,0777, // permissions KEY_END)); // end of args ksAppendKey(ks,keyNew("user/tmp/ex4", KEY_TYPE,KEY_TYPE_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 ksAppendKey(ks,keyNew("user/tmp/ex5", KEY_TYPE, KEY_TYPE_DIR | KEY_TYPE_BINARY,// dir key with a binary value KEY_SIZE,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 ksDel(ks); .fi .PP .RE .PP The reference counter (see \fBkeyGetRef()\fP) 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 keyInc()) and the key can't be be deleted by a \fBkeyDel()\fP\&. .PP .PP .nf Key *k = keyNew(0); // ref counter 0 ksAppendKey(ks, k); // ref counter of key 1 ksDel(ks); // key will be deleted with keyset .fi .PP .PP If you increment only by one with keyInc() the same as said above is valid: .PP .PP .nf Key *k = keyNew(0); // ref counter 0 keyIncRef(k); // ref counter of key 1 keyDel(k); // has no effect keyDecRef(k); // ref counter back to 0 keyDel(k); // key is now deleted .fi .PP .PP If you add the key to more keySets: .PP .PP .nf Key *k = keyNew(0); // ref counter 0 ksAppendKey(ks1, k); // ref counter of key 1 ksAppendKey(ks2, k); // ref counter of key 2 ksDel(ks1); // ref counter of key 1 ksDel(ks2); // k is now deleted .fi .PP .PP or use keyInc() 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 .PP they key won't be deleted by a \fBkeyDel()\fP as long refcounter is not 0\&. .PP The key's sync bit will always be set for any call, except: .PP .nf Key *k = keyNew(0); // keyNeedSync() will be false .fi .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 \fIKeyInvalidName\fP if key could not be constructed (typically name wrong or at runtime on 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_listap)\fC [inline]\fP, \fC [explicit]\fP" .PP A practical way to fully create a \fBKey\fP object in one step\&. .PP This function tries to mimic the C++ way for constructors\&. .PP To just get a key object, simple do: .PP .nf Key *k = keyNew(0); // work with it keyDel (k); .fi .PP .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 and cheaper to \fBkeyDup()\fP the key\&. .RE .PP 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\&. See http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN135 .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 The simplest and minimum way to use it is with no tags, only a key name: .PP .nf Key *nullKey,*emptyNamedKey; // Create a key that has no name, is completely empty, but is initialized nullKey=keyNew(0); keyDel (nullKey); // Is the same as above nullKey=keyNew("", KEY_END); keyDel (nullKey); // Create and initialize a key with a name and nothing else emptyNamedKey=keyNew("user/some/example",KEY_END); keyDel (emptyNamedKey); .fi .PP .PP \fBkeyNew()\fP allocates memory for a key object and cleans everything up\&. After that, it processes the given argument list\&. .PP The \fBKey\fP attribute tags are the following: .IP "\(bu" 2 keyswitch_t::KEY_TYPE .br Next parameter is a type of the value\&. Default assumed is KEY_TYPE_UNDEFINED\&. Set this attribute so that a subsequent KEY_VALUE can toggle to \fBkeySetString()\fP or \fBkeySetBinary()\fP regarding to \fBkeyIsString()\fP or \fBkeyIsBinary()\fP\&. If you don't use KEY_TYPE but a KEY_VALUE follows afterwards, KEY_TYPE_STRING will be used\&. .IP "\(bu" 2 keyswitch_t::KEY_SIZE .br Define a maximum length of the value\&. This is especially useful for setting a binary key\&. So make sure you use that before you KEY_VALUE for binary keys\&. .IP "\(bu" 2 keyswitch_t::KEY_VALUE .br Next parameter is a pointer to the value that will be set to the key If no keyswitch_t::KEY_TYPE was used before, keyswitch_t::KEY_TYPE_STRING is assumed\&. If KEY_TYPE was previously passed with a KEY_TYPE_BINARY, you should have passed KEY_SIZE before! Otherwise it will be cut of with first \\0 in string! .IP "\(bu" 2 keyswitch_t::KEY_UID, \fCkeyswitch_t::KEY_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 keyswitch_t::KEY_MODE .br Next parameter is taken as mode permissions (int) to the key\&. See \fBkeySetMode()\fP\&. .IP "\(bu" 2 keyswitch_t::KEY_DIR .br Define that the key is a directory rather than a ordinary key\&. This means its executable bits in its mode are set\&. This option allows the key to have subkeys\&. See \fBkeySetDir()\fP\&. .IP "\(bu" 2 keyswitch_t::KEY_OWNER .br Next parameter is the owner\&. See \fBkeySetOwner()\fP\&. .IP "\(bu" 2 keyswitch_t::KEY_COMMENT .br Next parameter is a comment\&. See \fBkeySetComment()\fP\&. .IP "\(bu" 2 keyswitch_t::KEY_END .br Must be the last parameter passed to \fBkeyNew()\fP\&. It is always required, unless the \fCkeyName\fP is 0\&. .PP .PP \fBExample:\fP .RS 4 .PP .nf KeySet *ks=ksNew(0); ksAppendKey(ks,keyNew(0)); // an empty key ksAppendKey(ks,keyNew("user/sw", // the name of the key KEY_END)); // no more args ksAppendKey(ks,keyNew("user/tmp/ex1", KEY_VALUE,"some data", // set a string value KEY_END)); // end of args ksAppendKey(ks,keyNew("user/tmp/ex2", KEY_VALUE,"some data", // with a simple value KEY_MODE,0777, // permissions KEY_END)); // end of args ksAppendKey(ks,keyNew("user/tmp/ex4", KEY_TYPE,KEY_TYPE_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 ksAppendKey(ks,keyNew("user/tmp/ex5", KEY_TYPE, KEY_TYPE_DIR | KEY_TYPE_BINARY,// dir key with a binary value KEY_SIZE,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 ksDel(ks); .fi .PP .RE .PP The reference counter (see \fBkeyGetRef()\fP) 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 keyInc()) and the key can't be be deleted by a \fBkeyDel()\fP\&. .PP .PP .nf Key *k = keyNew(0); // ref counter 0 ksAppendKey(ks, k); // ref counter of key 1 ksDel(ks); // key will be deleted with keyset .fi .PP .PP If you increment only by one with keyInc() the same as said above is valid: .PP .PP .nf Key *k = keyNew(0); // ref counter 0 keyIncRef(k); // ref counter of key 1 keyDel(k); // has no effect keyDecRef(k); // ref counter back to 0 keyDel(k); // key is now deleted .fi .PP .PP If you add the key to more keySets: .PP .PP .nf Key *k = keyNew(0); // ref counter 0 ksAppendKey(ks1, k); // ref counter of key 1 ksAppendKey(ks2, k); // ref counter of key 2 ksDel(ks1); // ref counter of key 1 ksDel(ks2); // k is now deleted .fi .PP .PP or use keyInc() 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 .PP they key won't be deleted by a \fBkeyDel()\fP as long refcounter is not 0\&. .PP The key's sync bit will always be set for any call, except: .PP .nf Key *k = keyNew(0); // keyNeedSync() will be false .fi .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 \fIKeyInvalidName\fP if key could not be constructed (typically name wrong or at runtime on 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 .PP Adds \fCbaseName\fP to the current key name\&. .PP Assumes that \fCkey\fP is a directory\&. \fCbaseName\fP is appended to it\&. The function adds \fC'/'\fP if needed while 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 name \fC'system/dir1/dir2/mykey'\fP\&. .PP When baseName is 0 or '' nothing will happen and the size of the name is returned\&. .PP \fBWarning:\fP .RS 4 You should not change a keys name once it belongs to a keyset because it would destroy the order\&. .RE .PP TODO: does not recognice \&.\&. and \&. in the string! .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 .PP -1 if the key had no name .PP -1 on NULL pointers .RE .PP \fBSee also:\fP .RS 4 \fBkeySetBaseName()\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 "void kdb::Key::clear ()\fC [inline]\fP" .PP Clears/Invalidates a key\&. .PP 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, operator bool() .RE .PP \fBKey\fP Object Cleaner\&. .PP 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 \fBReturns:\fP .RS 4 returns 0 on success .PP -1 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\&. .PP 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 .PP The reference counter will not be changed for both keys\&. Affiliation to keysets are also not affected\&. .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 .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 If you want to copy all metadata, but keep the old 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 metadata from c } .fi .PP .PP \fBNote:\fP .RS 4 Next to the value itself we also need to remember if the value was string or binary\&. So in fact the meta data of the resulting key k in that example is not a complete duplicate, because the meta data 'binary' may differ\&. Similar considerations might be necessary for the type of the key and so on, depending on the concrete situation\&. .RE .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 \fBReturns:\fP .RS 4 -1 on failure when a NULL pointer was passed for dest or a dynamic property could not be written\&. Both name and value are empty then\&. .PP 0 when dest was cleaned .PP 1 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\&. .PP The key dest will additionally have all meta data 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 keyCopyMeta(k, c); // the caller will see the changed key k // with all the metadata 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, "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 (needs_shared_data(current)) keyCopyAllMeta(current, shared); } } .fi .PP .PP \fBPostcondition:\fP .RS 4 for every metaName present in source: keyGetMeta(source, metaName) == keyGetMeta(dest, metaName) .RE .PP \fBReturns:\fP .RS 4 1 if was successfully copied .PP 0 if source did not have any meta data .PP -1 on null pointers (source or dest) .PP -1 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\&. .PP 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 \fBReturns:\fP .RS 4 1 if was successfully copied .PP 0 if the meta data in dest was removed too .PP -1 on null pointers (source or dest) .PP -1 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\&. .PP 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 .PP 0 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" 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\&. .PP 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 initializised source \fBKey\fP .RE .PP \fBReturns:\fP .RS 4 0 failure or on NULL pointer .PP 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\&. .PP You can write your own template specialication, e\&.g\&.: .PP .nf .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 real internal key name where the \fCbasename\fP starts\&. .PP 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\&. If you need a copy of the basename consider to use \fBkeyGetBaseName()\fP\&. .PP \fBkeyBaseName()\fP returns '' when there is no keyBaseName\&. The reason is .PP .nf key=keyNew(0); keySetName(key,""); keyBaseName(key); // you would expect "" here keySetName(key,"user"); keyBaseName(key); // you would expect "" 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 \fBkeyBaseName()\fP method to set a new value\&. Use \fBkeySetBaseName()\fP instead\&. .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 .PP '' when the key has no (base)name .PP 0 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\&. .PP \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 .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 Get the value of a key as a binary\&. .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\&. .PP 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 .PP 1 when there is no data and type is not binary .PP 0 when there is no data and type is binary .PP -1 on null pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetString()\fP, \fBkeyGetBinary()\fP, \fBkeyValue()\fP .RE .PP .SS "std::string kdb::Key::getDirName () const\fC [inline]\fP" .PP \fBReturns:\fP .RS 4 the dir name of the key .RE .PP e\&.g\&. system/sw/dir/key will return system/sw/dir .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 .PP 1 on empty name .PP -1 on NULL pointers .PP -1 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 .PP 1 on empty name .PP -1 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" 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" Passes out the raw key pointer\&. .PP 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\&. .PP 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 \fBReturns:\fP .RS 4 0 if the key or metaName is 0 .PP 0 if no such metaName is found .PP 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\&. .PP 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 \fBkeyName()\fP returns '' 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 .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\&. .PP '' when there is no (a empty) keyname .PP 0 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 .RE .PP \fBNote:\fP .RS 4 unlike in the C version, it is safe to change the returned string\&. .RE .PP .SS "ssize_t kdb::Key::getNameSize () const\fC [inline]\fP" .PP Bytes needed to store the key name without owner\&. .PP 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 .PP 1 if there is is no key Name .PP -1 on NULL pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetName()\fP, \fBkeyGetFullNameSize()\fP .RE .PP .SS "ssize_t kdb::Key::getReferenceCounter () const\fC [inline]\fP" .PP Return how many references the key has\&. .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\&. Keys with zero references will be deleted when using \fBkeyDel()\fP\&. .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturns:\fP .RS 4 the number of references .PP -1 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\&. .PP 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 .PP 1 when there is no data and type is not binary .PP 0 when there is no data and type is binary .PP -1 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\&. .PP 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); 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 .PP '' when there is no data and key is not binary .PP 0 where there is no data and key is binary .PP 0 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 .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 Check if the key check is below the key key or not\&. .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 \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 \fBReturns:\fP .RS 4 1 if check is below key .PP 0 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\&. .PP 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 \fBReturns:\fP .RS 4 1 if it is binary .PP 0 if it is not .PP -1 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 .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 Check if the key check is direct below the key key or not\&. .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 \fBReturns:\fP .RS 4 1 if check is below key .PP 0 if it is not below or if it is the same key .PP -1 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 or not\&. .PP In elektra terminology any key is inactive if the it's basename starts with '\&.'\&. Inactive keys must not have any meaning to applications, they are reserved for users and administrators\&. .PP To remove a whole hierarchy in elektra, don't forget to pass option_t::KDB_O_INACTIVE to \fBkdbGet()\fP to receive the inactive keys in order to remove them\&. .PP Otherwise you should not fetch these keys\&. .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturns:\fP .RS 4 1 if the key is inactive, 0 otherwise .PP -1 on NULL pointer or when key has no name .RE .PP .SS "bool kdb::Key::isString () const\fC [inline]\fP" .PP Check if a key is string type\&. .PP 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 \fBReturns:\fP .RS 4 1 if it is string .PP 0 if it is not .PP -1 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" 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" 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 .RE .PP .SS "const \fBKey\fP kdb::Key::nextMeta ()\fC [inline]\fP" .PP Iterate to the next meta information\&. .PP 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 .PP 0 when the end is reached .PP 0 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" This is for loops and lookups only\&. .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 \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\&. They only take account when none of the preceding rules matched\&. .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\&. .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 // keyCmp(0,0) == 0 // keyCmp(k1,0) == 1 // keyCmp(0,k2) == -1 .fi .PP .PP You can write similar equation for the other rules\&. .PP Here are some more examples with equation: .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 .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 \fBWarning:\fP .RS 4 Do not try to strcmp the \fBkeyName()\fP yourself because the used strcmp implementation is allowed to differ from simple ascii comparison\&. .RE .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\&. .PP Passes out the raw key pointer\&. .PP 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\&. .PP 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 .PP .nf Key *k; keyInc (k); function_that_keyDec(k); // work with k keyDel (k); // now really free it .fi .PP .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 .PP -1 on null pointer .PP SSIZE_MAX 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, \fBkeyDecRef()\fP, \fBkeyDel()\fP .RE .PP .SS "void kdb::Key::operator++ () const\fC [inline]\fP" .PP Increment the viability of a key object\&. .PP 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 .PP .nf Key *k; keyInc (k); function_that_keyDec(k); // work with k keyDel (k); // now really free it .fi .PP .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 .PP -1 on null pointer .PP SSIZE_MAX 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, \fBkeyDecRef()\fP, \fBkeyDel()\fP .RE .PP .SS "\fBKey\fP & kdb::Key::operator+= (const std::string &newAddBaseName)\fC [inline]\fP" Add a new basename\&. .PP \fBSee also:\fP .RS 4 \fBkeyAddBaseName()\fP .RE .PP .SS "\fBKey\fP & kdb::Key::operator+= (const char *newAddBaseName)\fC [inline]\fP" .PP (const std::string &) Add a new basename\&. .PP \fBSee also:\fP .RS 4 \fBkeyAddBaseName()\fP (const std::string &) .RE .PP .SS "void kdb::Key::operator-- (int) const\fC [inline]\fP" .PP Decrement the viability of a key object\&. .PP 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 .PP -1 on null pointer .PP 0 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, \fBkeyDel()\fP, \fBkeyIncRef()\fP .RE .PP .SS "void kdb::Key::operator-- () const\fC [inline]\fP" .PP Decrement the viability of a key object\&. .PP 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 .PP -1 on null pointer .PP 0 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, \fBkeyDel()\fP, \fBkeyIncRef()\fP .RE .PP .SS "\fBKey\fP & kdb::Key::operator-= (const std::string &newSetBaseName)\fC [inline]\fP" Set a new basename\&. .PP \fBSee also:\fP .RS 4 \fBkeySetBaseName()\fP .RE .PP .SS "\fBKey\fP & kdb::Key::operator-= (const char *newSetBaseName)\fC [inline]\fP" .PP (const std::string &) Set a new basename\&. .PP \fBSee also:\fP .RS 4 \fBkeySetBaseName()\fP (const std::string &) .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\&. They only take account when none of the preceding rules matched\&. .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\&. .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 // keyCmp(0,0) == 0 // keyCmp(k1,0) == 1 // keyCmp(0,k2) == -1 .fi .PP .PP You can write similar equation for the other rules\&. .PP Here are some more examples with equation: .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 .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 \fBWarning:\fP .RS 4 Do not try to strcmp the \fBkeyName()\fP yourself because the used strcmp implementation is allowed to differ from simple ascii comparison\&. .RE .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\&. They only take account when none of the preceding rules matched\&. .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\&. .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 // keyCmp(0,0) == 0 // keyCmp(k1,0) == 1 // keyCmp(0,k2) == -1 .fi .PP .PP You can write similar equation for the other rules\&. .PP Here are some more examples with equation: .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 .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 \fBWarning:\fP .RS 4 Do not try to strcmp the \fBkeyName()\fP yourself because the used strcmp implementation is allowed to differ from simple ascii comparison\&. .RE .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" Assign a C key\&. .PP Will call del() on the old key\&. .SS "\fBKey\fP & kdb::Key::operator= (const \fBKey\fP &k)\fC [inline]\fP" Assign a key\&. .PP Will call del() on the old key\&. .SS "\fBKey\fP & kdb::Key::operator= (const std::string &newName)\fC [inline]\fP" Assign the name of a key\&. .PP \fBSee also:\fP .RS 4 \fBkeySetName\fP .RE .PP .SS "\fBKey\fP & kdb::Key::operator= (const char *newName)\fC [inline]\fP" .PP (const std::string &newName) Assign a C key\&. .PP Will call del() on the old key\&. (const std::string &newName) .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\&. They only take account when none of the preceding rules matched\&. .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\&. .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 // keyCmp(0,0) == 0 // keyCmp(k1,0) == 1 // keyCmp(0,k2) == -1 .fi .PP .PP You can write similar equation for the other rules\&. .PP Here are some more examples with equation: .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 .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 \fBWarning:\fP .RS 4 Do not try to strcmp the \fBkeyName()\fP yourself because the used strcmp implementation is allowed to differ from simple ascii comparison\&. .RE .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\&. They only take account when none of the preceding rules matched\&. .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\&. .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 // keyCmp(0,0) == 0 // keyCmp(k1,0) == 1 // keyCmp(0,k2) == -1 .fi .PP .PP You can write similar equation for the other rules\&. .PP Here are some more examples with equation: .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 .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 \fBWarning:\fP .RS 4 Do not try to strcmp the \fBkeyName()\fP yourself because the used strcmp implementation is allowed to differ from simple ascii comparison\&. .RE .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\&. They only take account when none of the preceding rules matched\&. .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\&. .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 // keyCmp(0,0) == 0 // keyCmp(k1,0) == 1 // keyCmp(0,k2) == -1 .fi .PP .PP You can write similar equation for the other rules\&. .PP Here are some more examples with equation: .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 .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 \fBWarning:\fP .RS 4 Do not try to strcmp the \fBkeyName()\fP yourself because the used strcmp implementation is allowed to differ from simple ascii comparison\&. .RE .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" Passes out the raw key pointer\&. .PP \fBNote:\fP .RS 4 that the ownership is moved outside\&. .RE .PP The key will stay empty\&. .SS "void kdb::Key::rewindMeta () const\fC [inline]\fP" .PP Rewind the internal iterator to first meta data\&. .PP 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 \fBReturns:\fP .RS 4 0 on success .PP 0 if there is no meta information for that key (\fBkeyNextMeta()\fP will always return 0 in that case) .PP -1 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 (Tx)\fC [inline]\fP" .PP Set a key value\&. .PP Set the value for \fCkey\fP as \fCnewStringValue\fP\&. .PP 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\&. .PP Sets \fCbaseName\fP as the new basename for \fCkey\fP\&. .PP All text after the last \fC'/'\fP in the \fCkey\fP keyname is erased and \fCbaseName\fP is appended\&. .PP So lets 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 \fBWarning:\fP .RS 4 You should not change a keys name once it belongs to a keyset because it would destroy the order\&. .RE .PP TODO: does not work with \&.\&. and \&. .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 .PP -1 on NULL pointers .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_tdataSize)\fC [inline]\fP" .PP Set the value of a key as a binary\&. .PP 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 .PP 0 when the internal binary was freed and is now a null pointer .PP -1 if key is a NULL pointer .PP -1 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, Tx)\fC [inline]\fP" .PP Set metadata for key\&. .PP Set a new Meta-Information\&. .PP 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 \fBReturns:\fP .RS 4 -1 on error if key or metaName is 0, out of memory or names are not valid .PP 0 if the Meta-Information for metaName was removed .PP 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\&. .PP A valid name is of the forms: .IP "\(bu" 2 \fCsystem/something\fP .IP "\(bu" 2 \fCuser/something\fP .IP "\(bu" 2 \fCuser:username/something\fP .PP .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 correctly\&. 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 \fBWarning:\fP .RS 4 You shall not change a key name once it belongs to a keyset\&. .RE .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) .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::stringnewString)\fC [inline]\fP" .PP Set the value for \fCkey\fP as \fCnewStringValue\fP\&. .PP 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\&.