Wednesday, July 18, 2018

Digest for comp.lang.c++@googlegroups.com - 25 updates in 10 topics

jacobnavia <jacob@jacob.remcomp.fr>: Jul 18 11:08AM +0200

Consider the following C++ code (taken from
http://www.cplusplus.com/reference/system_error/error_code/error_code/)
 
// error_code constructors
#include <iostream> // std::cout
#include <cmath> // std::sqrt
#include <cerrno> // errno
#include <system_error> // std::error_code, std::generic_category
// std::error_condition
int main()
{
errno=0;
std::sqrt(-1.0); // errno set to EDOM
std::error_code ec (errno,std::generic_category());
 
std::error_condition ok;
if (ec != ok) std::cout << "Error: " << ec.message() << '\n';
 
return 0;
}
 
Compiled with gcc this code produced an error display.
Compiled with clang (in my Macintosh) this code display absolutely NOTHING.
 
I tried compiling using -std=c++11, -std=c++14 with the same results.
 
Is this a bug in clang?
 
As far as I understand this this code
1) Sets errno to zero
2) Calls sqrt with a double constant of -1.0 This should set errno.
3) Calls the constructor with an error code (errno) and a generic
category. This should produce an object of type error_code
4) Calls the constructor with default arguments. This should produce an
error code object with no errors
5) Compares the two error codes. If they are different displays a
message. They must be different since errno should have been set by sqrt.
 
But for clang they aren't.
 
Is this a bug in clang?
Juha Nieminen <nospam@thanks.invalid>: Jul 18 07:57AM

> AFAIK, nowadays the compilers attempt to have zero overhead in the
> non-exceptional path.
 
Indeed. It is my understanding that the C++ standardization committee only
standardized exception handling into C++98 once they were convinced that
it's possible to have a zero-overhead implementation of them (in the case
that exceptions are not thrown). In other words, if no exceptions are
thrown, there is no speed difference between supporting and not supporting
throwing exceptions. They upheld the "you don't pay for what you don't use"
principle quite strictly here. (In this case it means that code that isn't
using exceptions shouldn't suffer a speed penalty just because it has to
be prepared for an exception to happen somewhere along the line.)
Juha Nieminen <nospam@thanks.invalid>: Jul 18 08:00AM

> Yes, that `catch` does make a difference. Note that the `return 0;` is
> superfluous. It's the default for `main`, in both C and C++.
 
It's unclear to me if "return 0;" or "return EXIT_SUCCESS;" is the default
in C++ when no explicit return is specified in main().
 
(In the vast majority of systems EXIT_SUCCESS is 0, but I think theoretically
it could be something else.)
morealfwierdness@cylonHQ.com: Jul 18 09:03AM

On Tue, 17 Jul 2018 18:21:12 +0200
>> }
 
>Yes, that `catch` does make a difference. Note that the `return 0;` is
>superfluous. It's the default for `main`, in both C and C++.
 
Int is also the default return type for main() so lets bin that too, oh and
untyped function parameters default to int so lets save a few bytes and don't
bother putting it in. Now try compiling your dream code and see what the
compiler has to say about it.
 
You do love to put brevity above clarity, were you a Perl coder in a past
life?
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jul 17 10:06PM -0700

On 7/17/2018 3:19 PM, Vir Campestris wrote:
>     }
> }
 
> I seem to be in a minority.
 
I have indented them all before. It does seem to have potential scaling
issues wrt deeply nested namespaces.
Ian Collins <ian-news@hotmail.com>: Jul 18 06:34PM +1200

On 18/07/18 17:06, Chris M. Thomasson wrote:
 
>> I seem to be in a minority.
 
> I have indented them all before. It does seem to have potential scaling
> issues wrt deeply nested namespaces.
Mitigate by sticking to two space indentation, or use nested namespace
as Flibble showed.
 
--
Ian
Juha Nieminen <nospam@thanks.invalid>: Jul 18 08:04AM

> indentation and in simple cases I don't feel it affects readability, but
> in more complicated ones, where there are many nested namespaces, it
> easily becomes a mess...
 
C++17 added support for the syntax
 
namespace A::B::C
{
...
}
 
which was quite welcome, for me at least.
 
I also often use another syntactical trick (already supported by C++98) to
minimize the amount of indentation:
 
namespace A { class B; }
 
class A::B
{
...
};
Tim Rentsch <txr@alumni.caltech.edu>: Jul 18 12:48AM -0700


>> "a mild superset". That's a good one. :)
 
> It is better to say that C++ has compatibility with C, then speaking in
> terms of superset.
 
My comment was not about the superset part, only about the
mild part.
Tim Rentsch <txr@alumni.caltech.edu>: Jul 18 12:50AM -0700


> Without metaprogramming (and all the stuff that utilizes template
> metaprogramming like the STL) C++ really isn't much to write home
> about in the year of our Lord 2018.
 
I wasn't offering any opinion about how much C++ is to write home
about. My comment is only about the laughable proposition that
C++-minus-templates is only mildly larger than C.
Juha Nieminen <nospam@thanks.invalid>: Jul 18 07:53AM

> A good suggestion IMO. A problem with lists (as I think Bjarne has
> pointed out) is they suffer from lack of cache locality, so in
> practice arrays/vectors nearly always do better.
 
That's completely true, but in this case it may be a micro-optimization,
even premature optimization, with little to no benefit.
 
I this were a number-crunching example, where the list of elements is
being traversed and modified millions of times per second, as fast as
the computer can possibly do it, I would never use a linked list
(unless it's absolutely necessary, which is the case with a few
algorithms; rarely, but they exist).
 
However, this example is a list of a couple dozen elements, give or take,
which is traversed and modified once per frame (ie. typically 60 times
per second). It's hardly a bottleneck.
 
Moreover, depending on the particular implementation, the projectiles
themselves may be dynamically allocated objects (which is very common
with many game engines, where sprites are typically dynamically
allocated), so you are not really saving a lot of dynamic allocations
by not using a linked list.
 
The advantage of using std::list is that the code becomes simpler,
and thus the likelihood of bugs is smaller.
 
Know your tools, and use them efficiently.
Tim Rentsch <txr@alumni.caltech.edu>: Jul 18 12:47AM -0700

> I guess the case of having side effects qualifies as not a "core
> constant expression" which in n4659 10.1.5 p5 results in an ill-formed
> program, without warning (I hate those)
 
My reading of this passage is that the program is ill-formed only
if the function cannot possibly be called to deliver a constexpr
result. As long as there is some way of calling it to deliver a
constexpr result, it's okay to call it other ways that result in
runtime evaluation. Yes?
Ian Collins <ian-news@hotmail.com>: Jul 11 08:21AM +1200

On 11/07/18 05:33, Rick C. Hodgin wrote:
 
> Constructor
> Mated destructor
> Generic destructor
 
No.
 
There is only ever one destructor. If the work of the destructor
depends on how the object was construct, include a flag. This pattern
is uncommon.
 
--
Ian.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 10 01:33PM -0400

Is there something like this:
 
class CWhatever
{
public:
// Mated constructor / destructor pair
CWhatever(... params ...)
{
// Constructor code here
std::cout << "Constructor" << std::endl;
 
} ~ {
// Mated destructor code here
std::cout << "Mated destructor" << std::endl;
}
 
// Generic destructor
~CWhatever()
{
// Generic destructor code here
std::cout << "Generic destructor" << std::endl;
}
 
// Other things here
};
 
Such that it would generate this output on use:
 
Constructor
Mated destructor
Generic destructor
 
--
Rick C. Hodgin
ram@zedat.fu-berlin.de (Stefan Ram): Jul 18 03:58AM

>What is your preference towards indenting contents of namespaces?
 
Boost does it like this:
 
namespace boost {
namespace detail {
namespace function {
// Choose the appropriate underlying implementation
template<int Args> struct real_get_function_impl {};
 
.
ram@zedat.fu-berlin.de (Stefan Ram): Jul 18 04:03AM

>Boost does it like this:
>namespace boost {
> namespace detail {
 
And n4750 like
 
namespace std {
using ptrdiff_t = see below ;
 
. So what does my preference matter when both n4750 and
Boost agree in this regard (two spaces)?
Storage Unit <storage.unit@mailinator.com>: Jul 17 05:32AM -0500

>> Things like that are the reason why Windows programs suddenly break when
>> something is not installed to default location.
 
> Are you even able to install microsoft crap in a custom location?
 
It's been many years, but if I remember correctly many system folders
are called differently in different versions of Windows (French,
Japanese, Chinese, etc.) because their names are translated to native
language of the user. For example, I'm 100% sure that Desktop and
Documents folders' names are always translated. I guess Desktop is not
that important, but Documents folder is the default place where many
programs keep their files, which mean that they try to access it at the
startup.
 
Even programs that allow custom paths to folders are often break when
those paths contain non-ASCII characters.
 
 
--
Emacs OS
ram@zedat.fu-berlin.de (Stefan Ram): Jul 10 05:30PM

>explains, and the nature of programming means that significant amounts
>of time get dedicated to "what is essentially busywork."
>without him fully realizing that.
 
»Much of the relative simplicity of Java is — like for
most new languages — partly an illusion and partly a
function of its incompleteness. As time passes, Java
will grow significantly in size and complexity. It will
double or triple in size and grow implementation-
dependent extensions or libraries.«
 
Bjarne Stroustrup, 1995
 
Today (2018), the renowned Java expert Joshua Bloch
acknowledged that Bjarne Stroustrup was right.
ram@zedat.fu-berlin.de (Stefan Ram): Jul 10 05:23PM

>takes 1 value and a number of elements.
>These are two logically different constructs, which justify the
>different syntax.
 
main.cpp
 
#include <iostream>
#include <ostream>
#include <string>
using namespace ::std::literals;
 
struct two_argument_constructor_no_list
{ two_argument_constructor_no_list
( int const one_value, int const a_number_of_elements )
{ ::std::cout << "two_argument_constructor_no_list\n"s; }};
 
#define INITIALIZER_LIST { 1, 2 }
 
int main(){ two_argument_constructor_no_list INITIALIZER_LIST; }
 
transcript
 
two_argument_constructor_no_list
Vir Campestris <vir.campestris@invalid.invalid>: Jul 10 09:57PM +0100

On 10/07/2018 11:41, Bart wrote:
> To hear people on these groups tell it, Windows is hopeless for software
> development.
 
IMHO Visual Studio is the best IDE out there.
 
These days I'm writing semi-embedded Linux stuff, and I miss Visual
Studio. I haven't found a Linux one as good.
 
Andy
Lynn McGuire <lynnmcguire5@gmail.com>: Jul 10 06:48PM -0500

On 7/10/2018 1:32 AM, Juha Nieminen wrote:
 
>> https://www.gamesindustry.biz/articles/2018-07-02-jonathan-blow-c-is-a-weird-mess
 
> "There are only two kinds of languages: the ones people complain about and
> the ones nobody uses." - Bjarne Stroustrup
 
+1,000,000
 
Lynn
Bart <bc@freeuk.com>: Jul 10 01:54PM +0100

On 10/07/2018 13:39, Thiago Adams wrote:
>> bad idea and in another video he introduces a special pointer syntax
>> for an "owning" pointer which frees memory automatically.
 
> I didn't find the videos.Do you have the links?
 
 
Try: https://inductive.no/jai/
Ian Collins <ian-news@hotmail.com>: Jul 11 09:57AM +1200

On 11/07/18 08:57, Vir Campestris wrote:
 
> IMHO Visual Studio is the best IDE out there.
 
> These days I'm writing semi-embedded Linux stuff, and I miss Visual
> Studio. I haven't found a Linux one as good.
 
Visual Studio Code?
 
https://code.visualstudio.com/
 
--
Ian.
Jeff-Relf.Me @.: Jul 17 08:40PM -0700

Jeff-Relf.Me @.: Jul 10 01:52PM -0700

Will Watts <ais@no.spam.please.cix.co.uk>: Jul 11 10:18AM +0100

I buy a lot of programming books. Packt books are somewhat variable in
quality: however 'Mastering the C++17 STL' is two or three cuts above
the average:
 
https://www.packtpub.com/application-development/mastering-c17-stl
 
It covers recent material that I have not seen documented previously,
is detailed, and editorialises in an amusing and chatty way. It also
has a historical perspective, which is most illuminating when covering
streams.
 
Recommended.
 
Will Watts
 
(I should say I have no relationship with the author or Packt, other
than as a satisfied punter.)
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)