static struct Args {
char* arg1;
unsigned arg2;
unsigned arg3;
char* arg4;
} arg;
My program saves command line args to a structure. Sometime all of the members are set... sometimes only a couple of them.
In the case where only arg1 is set, what would the best practice be to do with the rest of the members?
Thanks.
I'd use a flagged optional type, e.g. Boost.Optional. While you can use NULL for pointers, you may as well use an optional<char *> as well as an optional<int>.
If you insist on using NULL, you may decide that some int values aren't legal inputs (e.g. (unsigned)-1); you could reject them if the user supplies them, and use them to represent "no option supplied".
The essence of an optional wrapper is: boolean flag for whether option is present, and wrapped data type, e.g.:
template <class T>
struct optional<T> {
T val;
bool none;
bool have() { return !none; }
optional() : none(true)
optional(T const& val) : val(val),none(false) {}
void operator=(T const& t) { none=false; val=t; }
// etc; make none and val private if you wish
};
Usually when an argument is omitted, some default value is used by the program instead. If it makes sense, just put such defaults into the structure as if they were supplied as arguments.
Alternatively, it's common to set (char *)s to NULL in cases like this. (Note, it's possible to distinguish an empty string "" from NULL, and this may be useful as well.)
Integers are often set to some "invalid" value like 0 or -1 (this depends on which values are valid). For an unsigned you could use 0xFFFFFFFF.
I would just memset the whole thing. Any 0 value or null pointer are assumed not set.
For example,
memset(&arg, 0, sizeof(arg));
...
if (arg.arg2 == 0) // Not set
If you are working in plain c consider using GNU gengetopt, or emulating the approach used therein (which is to have flag variable that tell if optional arguments have been set). The c standards provide you with no support (soon to be released c++ standard).
As Artelius pointed out, you could set them to the default values. It is common to set pointers to NULL in such cases. With integers, you would want them to have a value other which will not confuse the rest of the code, like -1.
Related
I'm reading the documentation of std::experimental::optional and I have a good idea about what it does, but I don't understand when I should use it or how I should use it. The site doesn't contain any examples as of yet which leaves it harder for me to grasp the true concept of this object. When is std::optional a good choice to use, and how does it compensate for what was not found in the previous Standard (C++11).
The simplest example I can think of:
std::optional<int> try_parse_int(std::string s)
{
//try to parse an int from the given string,
//and return "nothing" if you fail
}
The same thing might be accomplished with a reference argument instead (as in the following signature), but using std::optional makes the signature and usage nicer.
bool try_parse_int(std::string s, int& i);
Another way that this could be done is especially bad:
int* try_parse_int(std::string s); //return nullptr if fail
This requires dynamic memory allocation, worrying about ownership, etc. - always prefer one of the other two signatures above.
Another example:
class Contact
{
std::optional<std::string> home_phone;
std::optional<std::string> work_phone;
std::optional<std::string> mobile_phone;
};
This is extremely preferable to instead having something like a std::unique_ptr<std::string> for each phone number! std::optional gives you data locality, which is great for performance.
Another example:
template<typename Key, typename Value>
class Lookup
{
std::optional<Value> get(Key key);
};
If the lookup doesn't have a certain key in it, then we can simply return "no value."
I can use it like this:
Lookup<std::string, std::string> location_lookup;
std::string location = location_lookup.get("waldo").value_or("unknown");
Another example:
std::vector<std::pair<std::string, double>> search(
std::string query,
std::optional<int> max_count,
std::optional<double> min_match_score);
This makes a lot more sense than, say, having four function overloads that take every possible combination of max_count (or not) and min_match_score (or not)!
It also eliminates the accursed "Pass -1 for max_count if you don't want a limit" or "Pass std::numeric_limits<double>::min() for min_match_score if you don't want a minimum score"!
Another example:
std::optional<int> find_in_string(std::string s, std::string query);
If the query string isn't in s, I want "no int" -- not whatever special value someone decided to use for this purpose (-1?).
For additional examples, you could look at the boost::optional documentation. boost::optional and std::optional will basically be identical in terms of behavior and usage.
An example is quoted from New adopted paper: N3672, std::optional:
optional<int> str2int(string); // converts int to string if possible
int get_int_from_user()
{
string s;
for (;;) {
cin >> s;
optional<int> o = str2int(s); // 'o' may or may not contain an int
if (o) { // does optional contain a value?
return *o; // use the value
}
}
}
but I don't understand when I should use it or how I should use it.
Consider when you are writing an API and you want to express that "not having a return" value is not an error. For example, you need to read data from a socket, and when a data block is complete, you parse it and return it:
class YourBlock { /* block header, format, whatever else */ };
std::optional<YourBlock> cache_and_get_block(
some_socket_object& socket);
If the appended data completed a parsable block, you can process it; otherwise, keep reading and appending data:
void your_client_code(some_socket_object& socket)
{
char raw_data[1024]; // max 1024 bytes of raw data (for example)
while(socket.read(raw_data, 1024))
{
if(auto block = cache_and_get_block(raw_data))
{
// process *block here
// then return or break
}
// else [ no error; just keep reading and appending ]
}
}
Edit: regarding the rest of your questions:
When is std::optional a good choice to use
When you compute a value and need to return it, it makes for better semantics to return by value than to take a reference to an output value (that may not be generated).
When you want to ensure that client code has to check the output value (whoever writes the client code may not check for error - if you attempt to use an un-initialized pointer you get a core dump; if you attempt to use an un-initialized std::optional, you get a catch-able exception).
[...] and how does it compensate for what was not found in the previous Standard (C++11).
Previous to C++11, you had to use a different interface for "functions that may not return a value" - either return by pointer and check for NULL, or accept an output parameter and return an error/result code for "not available".
Both impose extra effort and attention from the client implementer to get it right and both are a source of confusion (the first pushing the client implementer to think of an operation as an allocation and requiring client code to implement pointer-handling logic and the second allowing client code to get away with using invalid/uninitialized values).
std::optional nicely takes care of the problems arising with previous solutions.
I often use optionals to represent optional data pulled from configuration files, that is to say where that data (such as with an expected, yet not necessary, element within an XML document) is optionally provided, so that I can explicitly and clearly show if the data was actually present in the XML document. Especially when the data can have a "not set" state, versus an "empty" and a "set" state (fuzzy logic). With an optional, set and not set is clear, also empty would be clear with the value of 0 or null.
This can show how the value of "not set" is not equivalent to "empty". In concept, a pointer to an int (int * p) can show this, where a null (p == 0) is not set, a value of 0 (*p == 0) is set and empty, and any other value (*p <> 0) is set to a value.
For a practical example, I have a piece of geometry pulled from an XML document that had a value called render flags, where the geometry can either override the render flags (set), disable the render flags (set to 0), or simply not affect the render flags (not set), an optional would be a clear way to represent this.
Clearly a pointer to an int, in this example, can accomplish the goal, or better, a share pointer as it can offer cleaner implementation, however, I would argue it's about code clarity in this case. Is a null always a "not set"? With a pointer, it is not clear, as null literally means not allocated or created, though it could, yet might not necessarily mean "not set". It is worth pointing out that a pointer must be released, and in good practice set to 0, however, like with a shared pointer, an optional doesn't require explicit cleanup, so there isn't a concern of mixing up the cleanup with the optional having not been set.
I believe it's about code clarity. Clarity reduces the cost of code maintenance, and development. A clear understanding of code intention is incredibly valuable.
Use of a pointer to represent this would require overloading the concept of the pointer. To represent "null" as "not set", typically you might see one or more comments through code to explain this intention. That's not a bad solution instead of an optional, however, I always opt for implicit implementation rather than explicit comments, as comments are not enforceable (such as by compilation). Examples of these implicit items for development (those articles in development that are provided purely to enforce intention) include the various C++ style casts, "const" (especially on member functions), and the "bool" type, to name a few. Arguably you don't really need these code features, so long as everyone obeys intentions or comments.
I am looking for space efficient implementation of optional (sizeof small_optional<T> == sizeof (T)).
So the emptiness is encoded using some special value of T, for example
small_optional<int, -1>
requires that I never store -1 in the small_optional so -1 can be used as magic value to determine if optional is empty or not.
The markable lib was created for this sole purpose:
Markable 1.0.0
An alternative to boost::optional<T> which does not store an additional bool flag, but encodes the 'empty' state inside T using a special indicated value.
Usage
Do you want to store a possibly missing int? Can you spare value -1?
You can use it like this:
using namespace ak_toolkit;
typedef markable<mark_int<int, -1>> opt_int;
opt_int oi;
opt_int o2 (2);
assert (!oi.has_value());
assert (o2.has_value());
assert (o2.value() == 2);
static_assert (sizeof(opt_int) == sizeof(int), "");
Do you want to store a possibly missing std::string, where 'missing'
!= 'empty'? Can you spare some string values that contain a null
character inside, like std::string("\0\0", 2)? This is how you do
it:
struct string_marked_value // a policy which defines the representaioion of the
: ak_toolkit::markable_type<std::string> // 'marked' (special) std::string value
{
static std::string marked_value() { // create the marked value
return std::string("\0\0", 2);
}
static bool is_marked_value(const std::string& v) { // test if a given value is considered marked
return v.compare(0, v.npos, "\0\0", 2) == 0;
}
};
typedef ak_toolkit::markable<string_marked_value> opt_str;
opt_str os, oE(std::string(""));
assert (!os.has_value());
assert (oE.has_value());
assert (oE.value() == "");
static_assert (sizeof(opt_str) == sizeof(std::string), "");
Albeit not a Boost library, markable is licensed under Boost Software License, Version 1.0., and is even referred to from the Performance Considerations section of Boosts own optional type:
Performance considerations
[...]
Controlling the size
[...] Therefore, if the size of the objects is critical for your
application (e.g., because you want to utilize your CPU cache in
order to gain performance) and you have determined you are willing to
trade the code clarity, it is recommended that you simply go with
type int and use some 'magic value' to represent not-an-int, or
use something like markable
library.
The background and thought process of the lib is explained in the following blog post from the lib's author:
Andrzej's C++ blog - Efficient optional values
I have written the following macro to mimic C#'s nameof operator but in C++/CLI:
#define nameof(x) (#x)
if (info == nullptr)
throw gcnew ArgumentNullException(nameof(info));
I have tried to convert this macro to a constexpr:
Either of these are wrong, they return the content of ToString:
template <typename T>
constexpr auto NAMEOF1(T value)
{
return """" + value + """";
}
template <typename T>
constexpr auto NAMEOF2(T value)
{
return System::String::Format("{0}", value);
}
Third attempt, using the typeid keyword:
template <typename T>
constexpr auto NAMEOF3(T value)
{
return gcnew System::String(typeid(value).name());
}
But it fails with the following error:
error C3185: 'typeid': used on managed type 'T', use 'T::typeid' instead
In short, not as easy as it sounds.
Question:
Is it possible to convert this nameof macro to a constexpr ?
(or should I just stick to good old #define ?)
No, it is not possible to obtain the name of an object in C++ in a constexpr function. constexpr functions are still able to be called at runtime, and at runtime, there is no possibility for this kind of reflection. Indeed, reflection in C++ in general is extremely limited. Without macros, your reflection abilities are limited to testing for the existence of and type of members using dirty and unintuitive template trickery, but nothing that returns a name as a string. Also be aware that as soon as an argument is passed to a function like NAMEOF1, the name of that argument will always be "value". There is no way to query the scope of the caller for the name or expression that was passed.
You should stick with your solution:
#define nameof(x) (#x)
This is of course, also a very limiting solution. This will simply turn the expression x into a string perfectly verbatim, and has no concept of different entities and scoping like nameof in C#.
I say this coming from a non-managed C++ background. From the error message you receive, it's clear that managed C++ has interesting effects on typeid. Perhaps somebody who knows more about C++/CLI can enlighten me or give a better answer.
Alternatively, if this sort of null-check is a frequent pattern, you could wrap that into a more concise macro. For example:
define THROW_IF_NULL(x) \
if ((x) == nullptr){ \
throw gcnew ArgumentNullException(#x); \
}
Example usage:
void process_info(Info* info){
THROW_IF_NULL(info)
// --snip--
}
On a side not, I'm not sure what you expect this to do:
return """" + value + """";
but if my understanding is correct, the expression """" will be parsed as two empty string literals ("", ""), which, because they appear side-by-side, are appended by the preprocessor into a single empty string literal. You can thus replace """" with "" to achieve the same effect. But perhaps you wanted something else?
I am trying to come up with a generic solution for parsing strings (with a given format). For instance, I would like to be able to parse a string containing a list of numeric values (integers or floats) and return a std::vector. This is what I have so far:
template<typename T, typename U>
T parse_value(const U& u) {
throw std::runtime_error("no parser available");
}
template<typename T>
std::vector<T> parse_value(const std::string& s) {
std::vector<std::string> parts;
boost::split(parts, s, boost::is_any_of(","));
std::vector<T> res;
std::transform(parts.begin(), parts.end(), std::back_inserter(res),
[](const std::string& s) { return boost::lexical_cast<T>(s); });
return res;
}
Additionally, I would like to be able to parse strings containing other type of values. For instance:
struct Foo { /* ... */ };
template<>
Foo parse_value(const std::string& s) {
/* parse string and return a Foo object */
}
The reason to maintain a single "hierarchy" of parse_value functions is because, sometimes, I want to parse an optional value (which may exist or not), using boost::optional. Ideally, I would like to have just a single parse_optional_value function that would delegate on the corresponding parse_value function:
template<typename T>
boost::optional<T> parse_optional_value(const boost::optional<std::string>& s) {
if (!s) return boost::optional<T>();
return boost::optional<T>(parse_value<T>(*s));
}
So far, my current solution does not work (the compiler cannot deduce the exact function to use). I guess the problem is that my solution relies on deducing the template value based on the return type of parse_value functions. I am not really sure how to fix this (or even whether it is possible to fix it, since the design approach could just be totally flawed). Does anyone know a way to solve what I am trying to do? I would really appreciate if you could just point me to a possible way to address the issues that I am having with my current implementation. BTW, I am definitely open to completely different ideas for solving this problem too.
You cannot overload functions based on return value [1]. This is precisely why the standard IO library uses the construct:
std::cin >> a >> b;
which may not be your piece of cake -- many people don't like it, and it is truly not without its problems -- but it does a nice job of providing a target type to the parser. It also has the advantage over a static parse<X>(const std::string&) prototype that it allows for chaining and streaming, as above. Sometimes that's not needed, but in many parsing contexts it is essential, and the use of operator>> is actually a pretty cool syntax. [2]
The standard library doesn't do what would be far and away the coolest thing, which is to skip string constants scanf style and allow interleaved reading.
vector<int> integers;
std::cin >> "[" >> interleave(integers, ",") >> "]";
However, that could be defined. (Possibly it would be better to use an explicit wrapper around the string literals, but actually I prefer it like that; but if you were passing a variable you'd want to use a wrapper).
[1] With the new auto declaration, the reason for this becomes even clearer.
[2] IO manipulators, on the other hand, are a cruel joke. And error handling is pathetic. But you can't have everything.
Here is an example of libsass parser:
const char* interpolant(const char* src) {
return recursive_scopes< exactly<hash_lbrace>, exactly<rbrace> >(src);
}
// Match a single character literal.
// Regex equivalent: /(?:x)/
template <char chr>
const char* exactly(const char* src) {
return *src == chr ? src + 1 : 0;
}
where rules could be passed into the lex method.
a C++ noob here. I am trying to tweak some code, with the following key lines (meaning they are not the only ones, but they are the only ones that should matter for this question). By the way, I am using Visual Studio 2010 C++ compiler on Windows.
CMap<ATL::CAtlString,LPCTSTR,UINT,UINT> mapForDuplicates; // "dict" definition
ATL::CAtlString strDescription = ... // let's just say it gets set to a value.
UINT nFound = 0; // What is this for???
BOOL bFound = mapForDuplicates.Lookup(strDescription, nFound);
mapForDuplicates[strDescription] = 1;
Now ... I really do not want to use the UINT here, as bool is all I really need. However, I could not figure out what all of the arguments for the CMap constructor really are. When using C#, all I have to specify is the type of the key and the type of the value. The fact that ATL::CAtlString does not match LPCSTR really confuses me. What exactly are KEY, ARG_KEY, VALUE, and ARG_VALUE? Why do I need all four and can all four be different? Thanks.
...
template<class KEY, class ARG_KEY, class VALUE, class ARG_VALUE>
class CMap : public CObject
...
Note: I could use std::map here instead(although I have not used it either); the only non-negotiable is ATL::CAtlString - I have to use this type. Let me know if you have questions.
IIRC the four args to the template are there so you can throw one type in and get another (const) type back. Here it throws in CAtlStrings, but it'll get back LPCTSTR. Often you just specify the same to types twice (e.g. int, int, float, float for a map of ints -> floats).
Grr, that extra L really irks me nowadays, it was great for 16-bit Windows but nowadays... PCSTR is all that's needed. 'L' is the useless appendix of Windows programming.
nFound is something coming out of the map, the map maps to UINT so nFound is a UINT.
Start with the docs for the class =- there is a ref to a sample here too
http://msdn.microsoft.com/en-us/library/s897094z(VS.71).aspx
By the way, the following pseudo-sample did the trick for me.
std::set<CAtlString> setOfDescriptions;
for each(...)
{
CAtlString strDescription = GetDescription();
if (setOfDescriptions.find(strDescription) != setOfDescriptions.end())
{
// Remove a duplicate.
}
setOfDescriptions.insert(strDescription); // Mark as seen.
}