Monday, October 3, 2016

Digest for comp.lang.c++@googlegroups.com - 16 updates in 6 topics

Mr Flibble <flibble@i42.co.uk>: Oct 03 06:50PM +0100

On 02/10/2016 22:21, Öö Tiib wrote:
> inlined functor. It just means developer can't use 'qsort()' and has to
> waste time to implement introsort (or what that 'std::sort()' typically
> is) for his container but it won't be slower than 'std::sort()'.
 
It is not possible to write functors in C. Pointers to functions can't
be inlined.
 
/Flibble
David Brown <david.brown@hesbynett.no>: Oct 03 08:13PM +0200

On 03/10/16 19:50, Mr Flibble wrote:
>> is) for his container but it won't be slower than 'std::sort()'.
 
> It is not possible to write functors in C. Pointers to functions can't
> be inlined.
 
It is perfectly possible for a compiler to inline functions called by
pointers, as long as it knows the relevant details at compile time (or
link-time, for link-time optimisation). It is even perfectly possible
for the compiler to generate several copies of "qsort", each with an
inlined version of a particular comparison function - that is known as
"function cloning" optimisation.
 
Whether it /will/ inline like this or not is a different matter - that
depends on the compiler, the flags, and the code. But it is
fundamentally the same type of optimisation as inlining virtual method
calls, which C++ compilers often do.
 
(None of this changes the fundamental argument here - C++ can always be
at least as fast as C, assuming you have an optimising compiler, and
sometimes C++ gives you ways to write code that is faster than C code if
you want code to be clear, flexible and maintainable.)
"Öö Tiib" <ootiib@hot.ee>: Oct 03 12:06PM -0700

On Monday, 3 October 2016 20:50:21 UTC+3, Mr Flibble wrote:
> > is) for his container but it won't be slower than 'std::sort()'.
 
> It is not possible to write functors in C. Pointers to functions can't
> be inlined.
 
I did not write that it is possible to write functors or lambdas in C.
I wrote that it is possible to write code in C that is about equal with
instantiated 'std::sort()' template.
Daniel <danielaparker@gmail.com>: Oct 03 01:11PM -0700

On Monday, September 26, 2016 at 10:43:26 PM UTC-4, Lynn McGuire wrote:
 
> when I ask a question beginning with "Why" concerning the rationale for a
> particular C++ language or library feature, they have a 90% chance of
> getting the answer right by replying with a single word: "Performance.""
 
A student with some doubts about the performance beast might also reply with one word: streams.
 
Best regards,
Daniel
Wouter van Ooijen <wouter@voti.nl>: Oct 03 10:53PM +0200

Op 03-Oct-16 om 10:11 PM schreef Daniel:
>> particular C++ language or library feature, they have a 90% chance of
>> getting the answer right by replying with a single word: "Performance.""
 
> A student with some doubts about the performance beast might also reply with one word: streams.
 
To which I would reply: you like the C version better (for performance,
or any other reason)? Use it from C++, and still get the benefits from a
better language.
 
Wouter "Objects? No Thanks!" van Ooijen
Daniel <danielaparker@gmail.com>: Oct 03 02:24PM -0700

On Monday, October 3, 2016 at 4:53:59 PM UTC-4, Wouter van Ooijen wrote:
 
> To which I would reply: you like the C version better (for performance,
> or any other reason)? Use it from C++, and still get the benefits from a
> better language.
 
People do that, or implement their own conversions, especially for
integer/string conversions, sometimes they even hack the floating point bits.
Anything to avoid streams. Especially if they're writing software that has to
look respectable on benchmarks to be used.
 
Unfortunately, the C versions aren't complete, for example, the _l versions
aren't standard and aren't available in all environments, sometimes people write code to reverse the effects of localization.
 
It's just something to lament, that C++ doesn't have a respectable abstraction
for IO, or a full set of C IO functions.
 
Best regards,
Daniel
mark <mark@invalid.invalid>: Oct 04 12:46AM +0200

On 2016-10-03 19:50, Mr Flibble wrote:
 
> It is not possible to write functors in C. Pointers to functions can't
> be inlined.
 
Really?
 
-------------------------------------------------------
#include <stdbool.h>
 
typedef struct S {
int a;
int b;
} S;
 
inline bool cmp(const void* s1, const void* s2) {
return ((S*)s1)->a < ((S*)s2)->a;
}
 
typedef bool (*fn_ptr_t)(const void*, const void*);
fn_ptr_t fn_ptr = cmp;
 
bool test(const void* s1, const void* s2, fn_ptr_t c) {
return (*c)(s1, s2);
}
 
bool test_caller(const S* s1, const S* s2) {
return test(s1, s2, cmp);
}
-------------------------------------------------------
_test_caller:
LFB2:
.cfi_startproc
mov eax, DWORD PTR [esp+8]
mov edx, DWORD PTR [esp+4]
mov eax, DWORD PTR [eax]
cmp DWORD PTR [edx], eax
setl al
ret
.cfi_endproc
-------------------------------------------------------
 
With LTO, this kind of thing works across translation units. It
obviously won't work with dynamic function pointers, but if things are
known at compile time, it's not much different from templates getting
inlined.
ram@zedat.fu-berlin.de (Stefan Ram): Oct 03 04:12PM

>> 'auto main() -> int'
>why is this better than
>int main()
 
Maybe the old-timers are being reminded of Pascal:
 
Function IsLetter( Ch : Char ): Boolean;
 
Function Average( num, num1 : Real): Real;
 
? However, in modern C++, we can often omit the
return type alltogeter.
 
main.cpp
 
#include <iostream> // ::std::cout
#include <ostream> // <<
 
auto sum( auto x, auto y ){ return x + y; }
 
int main() { ::std::cout << sum( 10, 20 ) << '\n'; }
 
transcript
 
main.cpp:6:15: error: ISO C++ forbids use of 'auto' in parameter declaration [-Wpedantic]
auto sum( auto x, auto y ){ return x + y; }
^
main.cpp:6:23: error: ISO C++ forbids use of 'auto' in parameter declaration [-Wpedantic]
auto sum( auto x, auto y ){ return x + y; }
^
 
Oops. So my first attempt was not (yet) understood
by my C++ compiler (at least as long as I am being
pedantic). If we already would have concepts,
we could possibly write:
 
auto sum( Numeric x, Numeric y ){ return x + y; }
 
using the concept »Numeric« (which i just made up).
 
Ok, next try:
 
main.cpp
 
#include <iostream> // ::std::cout
#include <ostream> // <<
 
auto sum( int x, int y ){ return x + y; }
 
int main() { ::std::cout << sum( 10, 20 ) << '\n'; }
 
transcript
 
30
 
Of course, what /would/ be possible is also:
 
main.cpp
 
#include <iostream> // ::std::cout
#include <ostream> // <<
 
int main()
{ auto sum = []( auto x, auto y ){ return x + y; };
::std::cout << sum( 10, 20 ) << '\n'; }
 
transcript
 
30
 
, or
 
main.cpp
 
#include <cstdlib> // ::std::srand
#include <iostream> // ::std::cout
#include <ostream> // <<
 
template< class Numeric, class Numeric1 >
auto sum( Numeric x, Numeric1 y )
{ return x + y; }
 
int main() { ::std::cout << sum( 10, 20 ) << '\n'; }

transcript
 
30
 
. But we also can try to build our own "concepts light light":
 
main.cpp
 
#include <iostream> // ::std::cout
#include <ostream> // <<
#include <type_traits> // ::std::is_..., ::std::common_...
 
template< class Numeric, class Numeric1 >
void applyNumericalBinOpAssertions( Numeric, Numeric1 )
{ static_assert( ::std::is_arithmetic< Numeric >(), "" );
static_assert( ::std::is_arithmetic< Numeric1 >(), "" );
static_assert( ::std::is_convertible< Numeric, Numeric1 >(), "" );
static_assert( ::std::is_convertible< Numeric1, Numeric >(), "" );
using Common = typename ::std::common_type< Numeric, Numeric1 >::type;
static_assert( ::std::is_arithmetic< Common >(), "" ); }
 
template< class Numeric, class Numeric1 >
auto sum( Numeric x, Numeric1 y )
{ applyNumericalBinOpAssertions( x, y );
return x + y; }
 
int main() { ::std::cout << sum( 100, 200 ) << '\n'; }
 
transcript
 
300
JiiPee <no@notvalid.com>: Oct 03 07:43AM +0100

On 02/10/2016 16:27, Öö Tiib wrote:
> 'auto main() -> int'
 
 
why is this better than
 
int main()
 
 
?
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 03 08:50AM +0200

On 03.10.2016 08:43, JiiPee wrote:
 
> why is this better than
 
> int main()
 
> ?
 
Öö Tiib hasn't claimed that one of the declarations of `main` is better.
 
 
Cheers & hth.,
 
- Alf
scott@slp53.sl.home (Scott Lurndal): Oct 03 03:50PM


>In my opinion one should simplify by using only the general notations,
>because they are not more complex or uglier or more verbose than the old
>notations that they replace, so there's no reason to use the old.
 
Ugly is relative. auto main(int, const char **, const char **) -> int is just plain ugly
and is useless when one cannot use the latest version of C++
Trrvct@msn.com: Oct 03 04:35AM -0700

Trrvct@msn.com: Oct 03 04:31AM -0700

seeplus <gizmomaker@bigpond.com>: Oct 02 05:28PM -0700


> , but I can't read his slides. The font is too small.
 
> Brian
> Ebenezer Enterprises
 
Why is that?
I have a 27 inch monitor and the slides appear as about
300mm x 160mm == it looks just like my IDE does
and I feel like editing it .....
 
At this CPP Con is there an automatic tracker device which keeps
the presenter (nearly) in frame? Have not seen this before.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 02 07:17PM -0700

I was hoping for another talk from Kostya Serebryany on the
sanitizer additions to GCC. Always like Kostya's presentations:
 
http://www.google.com/search?&q=kostya+serebryany+sanitizer
 
CppCon 2015: Kostya Serebryany "Beyond Sanitizers..."
 
CppCon 2014: Kostya Serebryany "Sanitize your C++ code"
 
GTAC 2013: AddressSanitizer, ThreadSanitizer and MemorySanitizer -- Dynamic Testing Tools for C++
 
Best regards,
Rick C. Hodgin
"Chris M. Thomasson" <invalid@invalid.invalid>: Oct 02 07:44PM -0700

On 10/2/2016 7:17 PM, Rick C. Hodgin wrote:
 
> CppCon 2015: Kostya Serebryany "Beyond Sanitizers..."
 
> CppCon 2014: Kostya Serebryany "Sanitize your C++ code"
 
> GTAC 2013: AddressSanitizer, ThreadSanitizer and MemorySanitizer -- Dynamic Testing Tools for C++
 
 
Have you ever taken a look at Relacy?
 
http://www.1024cores.net/home/relacy-race-detector
 
 
It is created by a very smart friend of mine on the team for
ThreadSanitizer, and probably more.
 
http://www.1024cores.net
 
Very smart, and nice information here.
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)