Re: Onwards and upwards
On Saturday, 4 April 2015 04:20:39 UTC+3, woodb...@gmail.com wrote:
On Friday, April 3, 2015 at 8:12:03 AM UTC-5, =D6=F6 Tiib wrote:
On Thursday, 2 April 2015 07:51:11 UTC+3, woodb...@gmail.com wrote:
What do you think of this class?
Average class.
Here's an updated version
class failure : public ::std::exception {
::std::string whatStr;
public:
explicit failure (char const* w) : whatStr(w) {}
explicit failure (::std::string w) : whatStr(::std::move(w)) {}
char const* what () const throw()
{ return whatStr.c_str(); }
failure& operator<< (char const* s)
{
whatStr.append(s);
return *this;
}
failure& operator<< (char* s)
{
whatStr.append(s);
return *this;
}
failure& operator<< (::std::string const& s)
{
whatStr.append(s);
return *this;
}
template <class T>
failure& operator<< (T val)
{
using ::std::to_string;
return *this << to_string(val);
}
};
I took your advice and removed the destructor and added
the using statement. I'm not sure what the advantage
would be to changing that signature from char const* to
char const [] so I didn't change that.
I wrote what I have seen some coding standards suggesting.
I am also not always sure about advantage, it is often just
syntax that some people consider easier to read, others not.
Sometimes there is practical value too. For example to
indicating 'override' consistently helps when someone changes
a base class virtual and forgets to update one of overrides.
It is then compile error since it does not override anything
anymore.
....
I don't think of programs as selves. I'd compare a compiler
to a rock or a shovel.
Software is more active than rock or shovel. It does sometimes rather
complex things on its own among other things. C++ code is text with
complex rules of interpretation so sometimes one may have to rearrange
it a bit to make it easier to parse for certain tools and people.
....
Technically it is 'catch (std::string const&)' for user?
Performance considerations are always less important than usability
considerations so I usually derive exception types that may be
thrown out of my code from 'std::runtime_error'. Better usability
for caller, microscopic difference in performance.
If you really need such microscopic performance benefits then better
throw enwrapped into 'std::exception' string literals or integers.
IOW do not build long texts at throw site. For example: If catch
site can't do anything with long text that explains in detail what
strange byte sequence did not let a parser to parse the input,
then do not build such thing at throw site and executable size is
immediately smaller too.
That seems to be easier said than done. I'm not sure who
does that.
What is 'that'? I would call your second version of 'failure' as
'string_builder'. It extended 'std::string' to make building
texts more convenient. That is why I suspected that may be you
build complex texts with it and maybe those texts are not really
useful.
We sometimes build complex texts for logging or tracing but it
is orthogonal to exceptions. Lot of logs and traces are only
temporary for debugging/testing and so removed or turned off
from end products but exceptions are functional part of behavior
and remain same.
Exceptions need to have sufficient variety of types so
catch site can catch 'my::FileNotFound', 'my::AccessDenied' and
'my::BadDataInFile' separately when there is difference in
handling or just 'std::exception' base class when there are
no difference in handling.