Monday, July 23, 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?
Vir Campestris <vir.campestris@invalid.invalid>: Jul 16 09:46PM +0100

On 16/07/2018 06:45, bitrex wrote:
> few good use cases in modern C++, modern C++ which uses it all over the
> place is simply not well-designed code. I think I've used it in
> something like three or four times. ever.
 
I came into a project that was using raw pointers for objects with a
complex lifecycle. I halved the crash rate by swapping them for
shared_ptr and weak_ptr as appropriate. There were a mixture of leaks
and use-after-free problems.
 
They are overused; there are places where a unique_ptr will do the job.
But IMHO if you see thing* in modern C++ that's what the XP guys call a
code smell. It's dangerous.
 
Andy
legalize+jeeves@mail.xmission.com (Richard): Jul 18 08:21PM

[Please do not mail me a copy of your followup]
 
>On 18/07/18 06:16, Scott Lurndal wrote:
 
>> We have many linux programmers internally, and aside from a couple
>> of interns who used eclipse, everyone else uses vim or emacs.
 
I'm always amazed at the number of C/C++ developers that haven't
upgraded their development environment in 30+ years. By this point, I
would have expected that all the emacs afficionados would have
automated refactoring implemented in elisp, but nope. They have
essentially the same environment I had in 1988.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Rosario19 <Ros@invalid.invalid>: Jul 19 12:07PM +0200

On Thu, 19 Jul 2018 08:44:24 +0000 (UTC), boltar wrote:
>><quote>
>>So we limited our code to "Embedded C++�€? constructs
>>Exceptions: none
 
this seems to me ok... each function return error if can, and each
that call see if some error (if this is important)
 
>>Templates: none
 
where templates are the problem? the code that has <int> is traslated
as it is one int type in what i understand
 
>>Iostream: none
 
than one has to write his own routines... seems ok, if one not
introduce bugs (one can rewrite iostream eliminate their i presume bug
(can not possible to check for sucessfull/wrong input or remember it
wrong? because i rewrote getint getdouble with cin input etc))
 
possible now make error more than usual because some grappa
 
>>Multiple inheritance: none
 
i don't know the meaning...
 
legalize+jeeves@mail.xmission.com (Richard): Jul 17 05:47PM

[Please do not mail me a copy of your followup]
 
Vir Campestris <vir.campestris@invalid.invalid> spake the secret code
 
>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.
 
CLion comes close. Visual Studio Code is well respected as an editor
on linux.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
legalize+jeeves@mail.xmission.com (Richard): Jul 17 05:47PM

[Please do not mail me a copy of your followup]
 
Bart <bc@freeuk.com> spake the secret code
 
>[...] To hear people on these groups tell
>it, Windows is hopeless for software development.
 
Because those of us who find ourselves productive in Windows have long
since given up on the /. type bigots and their endless whinging.
 
...but back to the topic of the article. This is like the 40th time
that someone has complained about C++ and introduced a new language to
"solve" the problems that C++ has.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Lewis <g.kreme@gmail.com.dontsendmecopies>: Jul 16 04:05PM

> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 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?
 
Microsoft has been reliant on hard-coded paths since before Windows,
and Windows 10 is no different.
 
--
'Winners never talk about glorious victories. That's because they're the
ones who see what the battlefield looks like afterwards. It's only the
losers who have glorious victories.' --Small Gods
Paavo Helde <myfirstname@osa.pri.ee>: Jul 16 07:31PM +0300

On 16.07.2018 19:05, Lewis wrote:
 
> Are you even able to install microsoft crap in a custom location?
 
> Microsoft has been reliant on hard-coded paths since before Windows,
> and Windows 10 is no different.
 
There are lots of computers where there is no C:\Program Files, but for
example C:\Programme or C:\Archivos de programa.
 
Not to speak about missing C: in the original example, the code would
fail every time the current drive happens to be not C:.
 
There are Windows SDK functions for figuring out the locations of such
folders, but apparently if the program happened to work once somewhere
it's not broken.
SilverSlimer <silver@slim.er>: Jul 17 11:50AM

On Tue, 17 Jul 2018 09:03:42 +0000, boltar wrote:
 
> unix install in france or spain and expect to see /maison or /casa
> instead of /home. Major OS paths should be standardised no matter what
> the locale.
 
Completely agreed. It should be possible for a user who installed a
system in English to switch it over to something like Spanish and have
all of the software translate as well without any negative consequences.
I'm not sure whether Linux allows it to consistently change on demand (I
doubt it) but Windows should have made it possible considering they
charge for the operating system.
gof@somewhere.invalid (Adam Wysocki): Jul 19 08:09AM


> - Enforce at compile time that an object can only be instanciate on the stack. This is to implement a "safe" dynarray type like object.
 
No idea here.
 
> - Enforce at compile tiem that an object can only be instanciate on the heap. This is to ensure That no "Big" object are instanciated on the stack.
 
The only solution I see is creating a "wrapper" class that would
instantiate the desired class on the heap even if the wrapper is
instantiated on the stack.
 
--
[ Adam Wysocki :: Warsaw, Poland ]
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 18 08:22AM -0400

On 7/17/2018 3:26 PM, Rick C. Hodgin wrote:
> Somebody posted on comp.lang.asm.x86 an algorithm for fizz buzz.
> It made me think of one here in C/C++.
 
An optimization occurred to me driving in to work this morning.
 
 
>     // Cycling bit patterns
>     uint32_t three_data = 0x924;
>     uint32_t five_data  = 0x84210;
 
Shift the five_data bit pattern left by one bit:
 
uint32_t five_data = 0x84210 << 1;
 
>         for (int lnI = 1; lnI <= 100; ++lnI)
>         {
>             funcs[(three_data & 1) + (2 * (five_data & 1))].func(lnI);
 
It removes the need for a multiply here:
 
funcs[(three_data & 1) + (five_data & 2)].func(lnI);
 
>             three_data = (three_data >> 1) | ((three_data & 1) << 11);
>             five_data  = (five_data  >> 1) | ((five_data  & 1) << 19);
 
Then shift over 20 instead of 19:
 
five_data = (five_data >> 1) | ((five_data & 1) << 20);
 
>     }
 
> The rules of the FizzBuzz game are here:
 
>     http://wiki.c2.com/?FizzBuzzTest
 
 
Just popped in my head while driving. If there are any others, please
post them. I like this solution. Seems simple and elegant.
 
--
Rick C. Hodgin
boltar@cylonHQ.com: Jul 23 10:03AM

On Sun, 22 Jul 2018 13:26:37 +0200
>On 22/07/18 10:43, boltar@cylonHQ.com wrote:
>> You've obviously never programmed an arduino then :)
 
>I work with real embedded systems, not toys. I usually only see
 
Depends how you define a toy. It can be used for some lightweight applications.
 
>development system. It combines the worst of C with the worst of C++,
>hides all the useful stuff in the toolchain, skimps over important
>details so that people who learned with Arduino can't program on other
 
You still have to understand digital vs analogue I/O and timing otherwise
you're not going to get anything done.
 
>systems, and gives a false impression that embedded development is
>something quick and easy. If you understand the limitations of the
>system, it can be a useful idea - if not, it is worse than useless.
 
Same with anything really.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 17 06:21PM +0200

On 17.07.2018 16:32, Thiago Adams wrote:
> }
> return 0;
> }
 
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++.
 
 
Cheers!,
 
- Alf
David Brown <david.brown@hesbynett.no>: Jul 20 12:27AM +0200

On 19/07/18 21:43, Paavo Helde wrote:
>> to matter a great deal.
 
> Well, then you compile with -Os or equivalent, and hope the compiler
> does the right thing and optimizes for the size.
 
Sure, you use the right flags (and the right compiler). And you also
learn how to write code for such systems.
 
My point is that the size of the binaries can matter here.
 
> AFAIK there are even
> special compilers for embedded devices which can create smaller binaries.
 
Of course there are, especially for the very small devices (which are
rarely programmed in C++ anyway).
 
 
> In case of exception handling this means you trade some speed for the
> size. TANSTAAFL.
 
That is always the case with exception handling. Table-based exception
implementations are designed to minimise the impact for normal runs, at
the cost of speed or size for dealing with exceptions. Usually that's a
good tradeoff. (In embedded systems, you often disable exceptions
entirely.)
 
 
> When you do compile without -Os then it means you do not care about the
> size.
 
No, it certainly does not. It merely means that you are making a choice
other than having the compiler use size as the dominant factor in the
compilation. -O2 compilation can sometimes be smaller, and is often a
much more appropriate balance between size and speed (I'm assuming gcc
here). In particular, regardless of the flags you use you may make
design decisions aimed at smaller code space or at greater speed (or
flexibility, or other criteria).
 
Paavo Helde <myfirstname@osa.pri.ee>: Jul 18 03:04PM +0300

On 18.07.2018 11:00, Juha Nieminen wrote:
> 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.)
 
In 18.5/8: "If status is zero or EXIT_SUCCESS, an implementation-defined
form of the status successful termination is returned."
 
So 0 and EXIT_SUCCESS appear to be at least interchangeable, even if not
exactly the same.
Juha Nieminen <nospam@thanks.invalid>: Jul 17 12:14PM

> pass over all of them anyway to test for collisions and update the
> position, and inside this loop you can manage and update the active
> flag. Compacting the buffer can also be combined with this loop.
 
So, essentially, you want to implement your own memory management to
handle the projectiles, instead of using the one provided by the system.
 
Using memory compaction at the same time you are traversing the data
container (ie. removing gaps by moving elements to the first unused
slot in the container as you traverse it) may avoid having to traverse
a list with huge gaps, but are you really going to see a signficant
performance benefit from this scheme? You are only adding more
complication to your own code. (Also, if it so happens that there's
a significant amount of data stored for each projectile, assigning
them around in your data container may be a relatively heavy operation
and might offset any performance benefit you gain from not having
to call 'new' and 'delete' so often. Depending on the situation,
of course.)
 
In the end, this projectile management routine might not be any sort
of bottleneck anyway, so it comes a bit to premature optimization.
Ian Collins <ian-news@hotmail.com>: Jul 16 06:04PM +1200

On 16/07/18 11:51, Scott Lurndal wrote:
 
> For which there is an inevitable cost. In a recent project, we ripped
> out all the smart pointers because they had a huge performance impact. The
> code was almost twice as fast after elimination of the smart pointers.
 
The only real cost with standard smart pointers in an optimised build
comes from excessive copying of std::shared_ptr objects. On some
targets the resulting atomic increments and decrements are expensive.
That's why it's good practice to pass std::shared_ptr by const reverence
where possible.
 
Using something like std::unique_ptr to manage the lifetime of an object
is a freebie.
 
--
Ian.
Paavo Helde <myfirstname@osa.pri.ee>: Jul 16 05:59PM +0300

On 16.07.2018 17:27, Bart wrote:
 
>> set identbody = (identstarter | Range('0', '9')) & ~Elem('Z');
 
 
> You can simplify it further. Below is a version in C that uses byte-maps
> rather than bit-maps, which is OK for small sets.
[...]
> Set identstarter;
> Set identbody;
[...]
 
> memcpy(identbody,identstarter,sizeof(Set));
> addrange(identbody,'0','9');
> subelem(identbody,'Z');
 
I notice this is 10 lines/statements of *usage* in C as compared to the
2 lines in C++, not to speak about not being able to make the sets const
or constexpr when desired, and not to speak about error-prone use of
sizeof. I would not call it "further simplification".
 
Yes, the full implementation might be simpler in the C version. Who
cares? The implementation is supposed to be written once and used as
many times as possible.
Ian Collins <ian-news@hotmail.com>: Jul 17 08:13AM +1200

On 17/07/18 00:52, Scott Lurndal wrote:
 
>> Using something like std::unique_ptr to manage the lifetime of an object
>> is a freebie.
 
> So is using a regular pointer and understanding the code.
 
So removing something that has no cost is a sound engineering decision?
 
If code is designed to use smart pointers, especially std::shared_ptr,
removing them is a huge call affecting the core structure of the code.
Using them more efficiently (which is what we did when we had
performance issues) is a much more rational approach.
 
--
Ian.
Vir Campestris <vir.campestris@invalid.invalid>: Jul 16 09:45PM +0100

On 16/07/2018 13:52, Scott Lurndal wrote:
> Ian Collins<ian-news@hotmail.com> writes:
8X
>> Using something like std::unique_ptr to manage the lifetime of an object
>> is a freebie.
> So is using a regular pointer and understanding the code.
 
When the codebase was written by 100 people over 10 years - no,
understanding it isn't free.
 
Andy
Tim Rentsch <txr@alumni.caltech.edu>: Jul 18 11:46AM -0700

> manipulation of objects in C++ at all. All member functions get an
> implicit 'this' "pointer", and all member variables are accessed
> through it.
 
You think that's nitpicking? Is your understanding that shallow?
 
The difference is essential because passing an object by value
throws away dynamic type information. Any object passed by value
has a dynamic type that is the same as its static type. Virtual
function calls are dynamic only when the dynamic type is (at
least potentially) different than the static type. Passing an
object by pointer/reference is necessary for dynamic dispatch
of virtual functions actually to be dynamic rather than static.
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)?
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 {};
 
.
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 18 08:52PM

>the notion about 'leaking resources' in particular memory,
>i'd think would sound foreign to say a java or c# programmer
 
You open a connection to a database in Java. Ok, you can't
even spell "Java". So, say, a Java programmer opens a
connection to a database. At a certaint point, he does not
need it anymore, but he does not close it. What do you call
this if not a "resource leak"?
 
(You even can leak /memory/ by adding it to a stack and then
setting the stack pointer to the start without clearing
the references in the stack.)
 
>in java, you simply do a
>MyClass myobject = new MyClass();
 
How is that simpler than
 
My_class my_object;
 
?
 
>and you literally *forget* about it (yup that's leaked), when
>it goes out of scope say that it is allocated on the stack,
>garbage collection takes care of cleaning that up
 
GC does not clean up when »myobject« goes out of scope,
but it /might/ clean up the object created when it is not
reachable by the programs code anymore, which might be
way before or way after »myobject« goes out of scope.
 
(Not read on.)
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)