| Age | Commit message (Collapse) | Author |
|---|
|
|
|
In warn_nil, the return value was undefined on exception -- I think.
While informative, the names throw_nil and warn_nil don't work very
well in conditionals:
if (warn_nil<f>(...)) g();
sounds like g should be called if f returns nil and a warning is
issued. But it is actually the other way around; g is called if f is
successful.
if (prefer<f>(...)) g();
sounds less like that.
|
|
|
|
This is equivalent, but it may be useful to highlight that `args' does
not HAVE to be declared in order to get the return type of the
function call.
|
|
|
|
Some of the checks are likely redundant, but the Windows API
documentation rarely makes it clear WHICH errors may be returned (and
under which circumstances) rather than simply WHETHER errors may be
returned (under any circumstances, including those that do not apply
in the given case).
|
|
|
|
|
|
It isn't really more safe, but it removes the need for a confusing
function pointer cast, which is easy to get wrong. As far as the
compiler is concerned, the result is literally the same, but it does
force the caller to (indirectly, via the template parameter) cast the
return value, which may be a good thing.
|
|
|
|
|
|
f(void) is a C-ism that is valid but unnecessary in C++.
|
|
This is obviously a lot less obtuse.
|
|
It seems that "right-spaced" pointers are more widely used among C++
programmers.
|
|
Note that I did NOT add const to non-pointer/non-reference arguments
in function declarations (without a following definition), as they do
not mean anything there.
|
|
If needed in the future, it is possible to simply copy it from the Git
history.
|
|
|
|
I.e. using std::basic_string<TCHAR> instead of TCHAR *. This removes
all unmanaged frees.
|
|
This is feasible now that the makedeps script exists to automatically
manage build dependencies (see 6034fe2, d00f8b3).
|
|
Some older UNIX programs are organized like this,
and I think it gives a very good overview over the code.
See troff for an example.
|
|
|