Wednesday, May 25, 2016

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

"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 24 07:46PM -0700

On Tuesday, May 24, 2016 at 5:22:50 PM UTC-4, Mr Flibble wrote:
> > Rick C. Hodgin
 
> Mate, .... Oh and BTW if Jesus really did exist back in the day...
> /Flibble
 
Mr. Flibble, Jesus did come to the Earth. He is God. He stepped out of
Heaven, taking off His "royalty" to be born as one of us so that we
might be saved from the enemy who is today leading you in your life to
your destruction.
 
Jesus taught us how to be. And He continues to teach us today by sending
us His Holy Spirit, which guides us from within. You can see Him alive
in the believers, because He is alive in eternity having put an end to
death for all those who will believe in Him.
 
You too can be saved, Mr. Flibble. All you have to do is ask. And in asking, of course, you must acknowledge your sin, and your need for
forgiveness. He will forgive you. Of everything. No questions asked.
No penalty or punishment. And He will begin to change your life forever.
 
Jesus Christ is the cure for all ills. If we are not cured of the sin-
related issue here in this world, then our faith in Him has already
restored us in Heaven, and when we pass from this world we will enter
into His rest, into the paradise of God forever.
 
Jesus Christ cures all ills for all who will receive Him. And for all
who come to Him, He will never turn anyone away. He will forgive you,
and give you eternal life ... because He loves you, and because there
is an enemy who is deceiving us that He came to rescue us from.
 
Best regards,
Rick C. Hodgin
Ian Collins <ian-news@hotmail.com>: May 25 05:05PM +1200

On 05/25/16 09:22, Mr Flibble wrote:
 
> Mate, ...
 
Leigh, please trim here.
 
--
Ian
red floyd <no.spam@its.invalid>: May 25 10:24AM -0700

> On Tuesday, May 24, 2016 at 4:22:50 PM UTC-5,
 
> Leigh, please don't swear here.
 
Brian, please stop being a dickhead here.
James Moe <jimoeDESPAM@sohnen-moe.com>: May 25 12:07PM -0700

On 05/24/2016 01:35 PM, Rick C. Hodgin wrote:
> I saw this video today [...]
 
This asshole has been trolling a number of newsgroups. He is
impervious to requests to fuck off, however politely requested.
Your only relief from him is the killfile.
 
--
James Moe
jmm-list at sohnen-moe dot com
James Moe <jimoeDESPAM@sohnen-moe.com>: May 25 12:09PM -0700

On 05/24/2016 02:22 PM, Mr Flibble wrote:
>> > Best regards,
>> > Rick C. Hodgin
> Mate, fuck off you tedious, annoying cunt. [...]
 
Why did you re-post his incoherent rant?
 
--
James Moe
jmm-list at sohnen-moe dot com
bleachbot <bleachbot@httrack.com>: May 25 03:57PM +0200

ram@zedat.fu-berlin.de (Stefan Ram): May 25 03:43PM

>Wouter "Objects? No thanks!" van Ooijen
 
I have not watched the video, but I guess that
what actually is being intended to convey is:
 
Wouter "Run-time polymorphism? No thanks!" van Ooijen
 
. When a user of a vector-graphics editor can add several
shapes to an image, this is often implemented using a
collection of all the shapes of the image, and we only know
at runtime what the actual subclass (circle, triangle, ...)
of shape is when we loop over all shapes of the collection
and want to process each shape in turn.
 
How would someone implement such a loop without run-time
polymorphis (RTP)?
 
Why is this better than RTP?
 
When a new kind (subclass) of shape is being added to the
program by the programmer, where are changes necessary when
RTP is used and where when the alternative is used?
ram@zedat.fu-berlin.de (Stefan Ram): May 25 05:25PM

>speed and size of hardcoded C is your benchmark, it is worth considering
>CTP, because you can have a *some* of the advantages of RTP without the
>costs.
 
On the famous site
 
benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html
 
, C++ still is clearly slower than C.
 
Like many other people I do not understand why. As every C
program (with some minor adjustments) can be used as a C++
program, C++ should not be slower than C, because, when
there is a C program that is faster, one simple could use
/this/ C program as the C++ program.
 
C++ also has some cool hacks (like rvalue moves and
templates) that should provide abstraction for low-cost, and
it should be hard to imitate all of this abstraction and
type-safety in C for a program of the same complexity. So
one would expect C++ to be actually faster than C. But no,
on the »benchmarksgame« C++ is slower.
 
(In 2012, C was still number 1 on TIOBE, so when I gave a
C course, I would show them TIOBE and benchmarksgame and then
say: So you are here learning the programming that is the
most popular /and/ the fastest programming language.)
bleachbot <bleachbot@httrack.com>: May 25 08:12PM +0200

ram@zedat.fu-berlin.de (Stefan Ram): May 25 06:32PM

>How can I get in c_IDAMap an info about the template if it is a pointer
>or not?
 
#include <iostream>
#include <ostream>
 
template< class C >struct T
{ void report( ::std::ostream & out )
{ out << ::std::is_pointer< C >() << '\n'; }};
 
int main()
{ T< int >{}.report( ::std::cout );
T< int* >{}.report( ::std::cout ); }
 
g++ -std=c++17
 
0
1
ram@zedat.fu-berlin.de (Stefan Ram): May 25 06:35PM

Supersedes: <is_pointer-20160525193045@ram.dialup.fu-berlin.de>
[added "#include <type_traits>"]
 
>How can I get in c_IDAMap an info about the template if it is a pointer
>or not?
 
#include <iostream>
#include <ostream>
#include <type_traits>
 
template< class C >struct T
{ void report( ::std::ostream & out )
{ out << ::std::is_pointer< C >() << '\n'; }};
 
int main()
{ T< int >{}.report( ::std::cout );
T< int* >{}.report( ::std::cout ); }
 
g++ -std=c++17
 
0
1
ram@zedat.fu-berlin.de (Stefan Ram): May 25 07:01PM

> to achieve some abstractional benefits (call it compile
>time parametrization) without paying a price in performance or size of
>over (less parametrizable) C.
 
That is one, possibly, /the/, strength of C++.
Juha Nieminen <nospam@thanks.invalid>: May 25 08:09AM


>> --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
 
> You haven't worked on very big projects, then. I've seen compiles take
> overnight on a mainframe.
 
But that's my point: Every single time, every single freaking time,
someone complains about C++, the "long compile times" argument is
brought up, like it were some kind of crucial core flaw that affects
every single C++ programmer.
 
Well, it doesn't. In my entire professional career it has never been
an issue for me. It is most certainly not a reason to choose some other
language. It would be one of the silliest possible reasons to change
the entire programming language to something completely different and
incompatible.
 
If you work on multi-million-line codebases that take three weeks
to compile, then fine, change your language if you wish. But don't
be telling others to change their language because *you* have to
work with such codebases. It's not a problem that affects
everybody.
 
The complaint is idiotic.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Jerry Stuckle <jstucklex@attglobal.net>: May 25 12:00PM -0400

On 5/25/2016 4:09 AM, Juha Nieminen wrote:
> everybody.
 
> The complaint is idiotic.
 
> --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
 
No, it's not the complaint that is idiotic. The complaint is valid.
Just because it doesn't affect YOU doesn't mean it's not a valid
complaint. It's just not valid for YOU.
 
But it is very valid for a lot of other programmers.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Wouter van Ooijen <wouter@voti.nl>: May 25 07:08PM +0200

Op 25-May-16 om 5:43 PM schreef Stefan Ram:
> and want to process each shape in turn.
 
> How would someone implement such a loop without run-time
> polymorphis (RTP)?
 
I never meant to say that RTP is never usefull, to the contrary. I just
spent the last few weeks hammering that concept into the heads of a
fresh batch of students.
 
But when you don't realy need RTP, there are alternatives. And when the
speed and size of hardcoded C is your benchmark, it is worth considering
CTP, because you can have a *some* of the advantages of RTP without the
costs. And in my field (low-level micro-controller stuff) you often
don't need (and sometimes don't want!) run-time flexibility (for
instance because it makes it a lot harder to calculate the stack size
you need).
 
Wouter (still) "Objects? No Thanks!" van Ooijen
 
 
Wouter van Ooijen <wouter@voti.nl>: May 25 08:49PM +0200

Op 25-May-16 om 7:25 PM schreef Stefan Ram:
 
> benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html
 
> , C++ still is clearly slower than C.
 
> Like many other people I do not understand why.
 
Neither do I. What they problably are saying is that a certain set of
features (hopefully the same in both cases, but you can never be sure..)
was implemented by some specific groups of programmers using some
specific way of programmaing that they regarded as 'proper' for their
language, and the C++ version was slower than the C version. How very
interesting. (And how did the two versions compare on coding cost, bugs,
readability, flexibility, maintainbility?)
 
What I try to achieve with my "Objects? No thanks!" approach (I can sure
think of technically better names, but this one sure captures the
attention) is to achieve some abstractional benefits (call it compile
time parametrization) without paying a price in performance or size of
over (less parametrizable) C.
 
Wouter "Objects? No Thanks!" van Ooijen
Ramine <ramine@1.1>: May 25 06:57AM -0700

Hello...
 
My Scalable Parallel C++ Conjugate Gradient Linear System Solver Library
was updated..
 
Allocating memory on different NUMA nodes is now working correctly.
 
 
You can download My Scalable Parallel C++ Conjugate Gradient Linear
System Solver Library from:
 
https://sites.google.com/site/aminer68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 25 11:12AM -0700

Hello,
 
Sorry, i have just uploaded the new updated version.
 
My updated scalable PCG_DENSE is at version 1.4
 
You can download my new updated Scalable Parallel C++ Conjugate Gradient
Linear System Solver Library from:
 
https://sites.google.com/site/aminer68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library
 
 
Thank you,
Amine Moulay Ramdane.
"Heinz-Mario Frühbeis" <Div@Earlybite.individcore.de>: May 25 08:09PM +0200

Hi,
 
here I have a template class with a vector:
 
template < class t_MapMember >
class c_IDAMap{
private:
typedef std::pair < std::string, t_MapMember > tPair;
typedef std::vector < tPair > tVec;
// ...
}
 
I'm using it e.g.:
class c_Member{
// ...
}
c_IDAMap <c_Member*> mMap; // with pointer
 
I also could use it like this:
c_IDAMap <c_Member> mMap; // w/o pointer
 
How can I get in c_IDAMap an info about the template if it is a pointer
or not?
 
Regards
Heinz-Mario Frühbeis
Paavo Helde <myfirstname@osa.pri.ee>: May 25 11:32AM +0300

On 24.05.2016 0:26, jacobnavia wrote:
 
> This is completely impossible. To add two float128_t I need at least
> 50-60% of the library to extract the components, adjust the decimal
> point, do a 256 bit mantissa addition, build the result and a long etc!
 
In principle there is no reason why a constexpr function could not
contain all this. One can call also library functions as long as those
functions are constexpr as well.
 
 
> I thought the compiler would just call a function in a dll/so or similar.
 
If I understand correctly, your proposal would be that when (shared)
library A contains a non-constexpr function foo() (e.g. for adding
128-bit floats) and library B depends on library A, then library B could
use constexpr functions containing calls to foo(), and the compiler
would actually call this function at compile time and substitute the
result, instead of just linking to the library and calling foo() at run
time.
 
Interesting idea, but I have not not heard of any such things. For
starters, compiling library B in general does not require the presence
of library A, only headers are needed (and in case of Windows, the stub
.lib file). Dealing with libraries is the concern of the linker which
would be too late. It is true that nowadays linkers are also capable of
generating compiled code (whole program optimization etc), but this is
not mandated. For calling foo(), the linker must first be able to load
the library A into a process (together with all its dependencies which
is not a trivial task), which may become very tricky in case of
cross-compilation etc.
 
The current constexpr support is much more modest. It does not involve
the linker. It is only the compiler which sees the full source code
(recursively, so no need to mess with any library loading), recompiles
it (probably for the current platform as then it would be easy to call
it) and calls it, probably directly from the memory buffer where it
wrote the binary code, no library or dependencies loading needed.
 
Note that cross-compilation is very widespread. For example, MSVC
compiler cl.exe is for example a 32-bit program, so compiling 64-bit
applications with MSVC means cross-compilation.
 
Cheers
Paavo
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 25 02:05PM +0100

On Wed, 25 May 2016 11:32:59 +0300
> calling foo() at run time.
 
> Interesting idea, but I have not not heard of any such things. For
> starters, ...
[snip]
 
I agree with your snipped conclusions, but it has been done in other
languages. Realistically, it requires the same parser to be used for
compile time evaluation of syntactic transformations that is used to
generate code for run time evaluation. Looking at the languages
with (like C++) eager evaluation, OCaml has a relatively modest system
for syntactic macros, although only recently has it been possible to use
the OCaml parser for this. Lisps have had it from the outset: the lisp
parser can parse macros (s-expressions intended to be evaluated at
compile time) using the same parser as it uses to evaluate
s-expressions at runtime. The overriding restriction is that compile
time evaluation can only operate on literals (in this case, code
literals).
 
It doesn't look particularly worthwhile with C++ because of its strict
syntax; specialist code generators seem a better way of doing it, and
(as I think you mentioned, or if not someone else did) by providing
C++ constexpr versions of non-constexpr C library functions where they
can sensibly be made constexpr. This particularly applies to C
mathematical functions.
 
Chris
forumsmp@gmail.com: May 24 05:23PM -0700

Consider:
 
# include <iostream>
# include <cmath>
 
class FooClass
{
unsigned int mVariable ;
public :
FooClass ()
: mVariable ( 10. )
{}
friend std::ostream& operator << ( std::ostream& os, const FooClass& obj )
{
os << " Variable: " << obj.mVariable << "\n";
return ( os );
}
};
 
Three questions surrounding std::ostream use as shown above:
 
a) Any concerns/pitfalls surrounding use of ostream in an embedded environment?
b) Is storage generated for the ostream method?
 
The issue of ostream in an embedded environment is taboo in my line of work yet unclear to me why. I think the beliefs are often rooted in antiquated views of issues 10 or 20 years ago. For now my alternative is to use a macro to restrict use in embedded land
 
#ifdef USE_OSTREAM
friend std::ostream& operator << ( std::ostream& os, const FooClass& obj )
{
os << " Variable: " << obj.mVariable << "\n";
return ( os );
}
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)