Sunday, September 18, 2022

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

Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Sep 18 01:35PM -0700

Recently I wanted to have a class with a method called "Drop" that would return 'this', and so I wrote the following:
 
class MyClass {
 
#define DROP(modifiers) \
MyClass modifiers *Drop(void) modifiers \
{ \
return this; \
}
 
DROP()
DROP(const)
DROP(volatile)
DROP(const volatile)
 
};
 
Is there a better way of writing a member function just once and then having it work for all combinations of 'const' and 'volatile'?
"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Sep 18 10:59PM +0200

On 18 Sept 2022 22:35, Frederick Virchanza Gotham wrote:
> DROP(const volatile)
 
> };
 
> Is there a better way of writing a member function just once and then having it work for all combinations of 'const' and 'volatile'?
 
Off the cuff:
 
// C++ support machinery.
 
template< class Derived, Base >
constexpr bool is_same_or_derived_and_base_ =
std::is_base_of_v<Base, Derived>; // (sic!)
 
template< bool condition >
using Enable_if_ = std::enable_if_v<condition, int>;
 
template< class T > using const_ = const T;
 
// Problem solution: use a freestanding function.
// Possibly with trivial non-static member function wrappers.
 
struct My_class {};
 
template<
class T,
Enable_if_<is_same_or_derived_and_base_<T, My_class>> = 0
 
auto drop( const_<T*> p ) -> T* { return p; }
 
Disclaimer: not checked by a compiler.
 
See also: upcoming C++23 support for exactly this problem; <url:
https://www.google.com/search?q=c%2B%2B23+deduced+this>.
 
- Alf
"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Sep 18 11:00PM +0200

On 18 Sept 2022 22:59, Alf P. Steinbach wrote:
 
> See also: upcoming C++23 support for exactly this problem; <url:
> https://www.google.com/search?q=c%2B%2B23+deduced+this>.
 
> - Alf
 
oh should be enable_if_t, not v. gah.
 
- Alf
Lynn McGuire <lynnmcguire5@gmail.com>: Sep 18 11:05AM -0500

On 9/17/2022 4:52 AM, Bonita Montero wrote:
>     };
>     cout << pow( 2.0, integral_constant<unsigned, 10'000>() ) << endl;
> }
 
Thanks, but no. What a mess !
 
And I do not allow namespaces to be generalized in our code. No using !
 
Lynn
Bonita Montero <Bonita.Montero@gmail.com>: Sep 18 06:56PM +0200

Am 18.09.2022 um 18:05 schrieb Lynn McGuire:
>> }
 
> Thanks, but no.  What a mess !
 
> And I do not allow namespaces to be generalized in our code.  No using !
 
You're a very bad programmer for sure as I already have noticed.
Not because of this, but people having such narrow-minded attitudes
are unflexible.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 18 04:21PM +0200

Am 17.09.2022 um 21:03 schrieb Chris M. Thomasson:
 
> right? Anyway, check out this loop unrolling in C for a HMAC lib:
> https://github.com/ogay/hmac/blob/master/sha2.c
> Macros indeed. Search the code for UNROLL_LOOPS :^)
 
template<size_t N, typename Fn>
requires (N >= 1) && requires( Fn fn ) { { fn.template operator
()<(size_t)N - 1>() } -> std::same_as<void>; }
inline
void unroll( Fn fn )
{
auto unroll_n = [&]<size_t ... Indices>( std::index_sequence<Indices ...> )
{
(fn.template operator ()<Indices>(), ...);
};
unroll_n( std::make_index_sequence<N>() );
}
 
template<size_t N, bool Unroll, typename Fn>
requires (N >= 1) && requires( Fn fn ) { { fn() } -> std::same_as<void>; }
inline
void unroll( Fn fn )
{
if constexpr( Unroll )
{
auto unroll_n = [&]<size_t ... Indices>( std::index_sequence<Indices
..> )
{
return ((Indices, fn()), ...);
};
unroll_n( std::make_index_sequence<N>() );
}
else
for( size_t i = 0; i != N; fn(), ++i );
}
 
template<size_t N, bool Unroll, typename Fn>
requires (N >= 1) && requires( Fn fn, size_t i ) { { fn( i ) } ->
std::convertible_to<bool>; }
inline
bool unroll( Fn fn )
{
if constexpr( Unroll )
{
auto unroll_n = [&]<size_t ... Indices>( std::index_sequence<Indices
..> ) -> bool
{
return (fn( Indices ) && ...);
};
return unroll_n( std::make_index_sequence<N>() );
}
else
{
for( size_t i = 0; i != N; )
if( !fn( i++ ) )
return false;
return true;
}
}
 
template<size_t N, typename Fn>
requires (N >= 1) && requires( Fn fn ) { { fn.template operator
()<(size_t)N - 1>() } -> std::convertible_to<bool>; }
inline
bool unroll( Fn fn )
{
auto unroll_n = [&]<size_t ... Indices>( std::index_sequence<Indices
..> ) -> bool
{
return (fn.template operator ()<Indices>() && ...);
};
return unroll_n( std::make_index_sequence<N>() );
}
 
template<size_t N, bool Unroll, typename Fn>
requires (N >= 1) && requires( Fn fn ) { { fn() } ->
std::convertible_to<bool>; }
inline
bool unroll( Fn fn )
{
if constexpr( Unroll )
{
auto unroll_n = [&]<size_t ... Indices>( std::index_sequence<Indices
..> ) -> bool
{
return ((Indices, fn()) && ...);
};
return unroll_n( std::make_index_sequence<N>() );
}
else
{
for( size_t i = 0; i != N; ++i )
if( !fn() )
return false;
return true;
}
}
 
template<std::size_t N, typename RandomIt, typename UnaryFunction>
requires std::random_access_iterator<RandomIt>
&& requires( UnaryFunction fn, std::iter_value_t<RandomIt> elem ) { {
fn( elem ) }; }
inline
RandomIt unroll_for_each( RandomIt begin, RandomIt end, UnaryFunction fn )
{
RandomIt &it = begin;
if constexpr( N > 1 )
for( ; it + N <= end; it += N )
unroll<N>( [&]<std::size_t I>() { fn( it[I] ); } );
for( ; it < end; ++it )
fn( *begin );
return it;
}
David Brown <david.brown@hesbynett.no>: Sep 18 12:13PM +0200

>> or other employers (such as universities).
 
> Thats not the same as 90% in total over the decades. I suspect its rather
> smaller.
 
Since you claim to be familiar with Google, I'll let you do your own
research here into how long Linux development contributions have been
dominated by people paid to do the work - including how long Linus
Torvalds has been paid for his efforts. You might also look at how the
lines of code in the kernel have grown, and then you can get an idea of
how much of the kernel is written by people paid by their employers to
do the work.
 
It is probably smaller than 90%, since that is the figure for the
changes to Linux 5.10. (Actually, the figure is 90% to 95% - unknown is
unknown.) It would be very difficult to establish a true figure for the
total of the kernel source as it is now, as parts have been re-written
or replaced many times. But I think there is little doubt that it is
made primarily by people who are paid to do the work. (The same applies
to many other major open source projects, such as gcc and clang.)
 
 
> Both you and Juha are humourless bores and in your case one who takes himself
> far too seriously. People who cling on to professionalism as some kind of
> badge are usually making up for a lack of actual skills.
 
People who can't distinguish between serious, professional work (or
indeed serious amateur work) and overgrown teenager attitudes are a bane
to society. Documents like that guide are not light-hearted or
entertaining in a workplace - they are an embarrassment. It's fine to
post that kind of humour as a joke, but not as a requirement for real work.
David Brown <david.brown@hesbynett.no>: Sep 18 12:22PM +0200

On 16/09/2022 22:16, Andreas Kempe wrote:
>> program.)
 
> I guess the term embedded is a bit diluted these days with how
> powerful SoCs have become.
 
Yes, indeed. There have always been powerful embedded systems, with big
processors running big OS's, but they used to be very much in the
minority. Now you can put a Pi Zero running Linux in anything. The key
distinction, I think, whether the system is running a single statically
linked program as its main task (either bare bones, or with an RTOS of
some kind).
 
> assembly and my main experience is using PICs. I have toyed with the
> idea of using C++, but there isn't really any free C++ compilers PICs
> as far as I've found.
 
The PICs (and by that I assume you mean the 8-bit devices, not the PIC32
chips which have MIPS cores) have always had quite limited tools - they
are not well suited to C coding, never mind C++. The only 8-bit
microcontroller for which C++ is a reasonable option is the AVR, for
which the most common compiler is gcc. The core language is well
supported, but much of the library is very limited - including
language-support code for things like exceptions.
 
David Brown <david.brown@hesbynett.no>: Sep 18 12:34PM +0200

On 16/09/2022 23:55, Lynn McGuire wrote:
 
 
> What is a PIC ?
 
Ignorance is bliss - you'd have been happier if you never knew :-)
 
Since Scott has already posted a link, I think the key thing to know is
that it is one of the most brain-dead of all the brain-dead 8-bit CISC
microcontroller architectures around. It makes the 8051 look smart. We
are talking single register, banked ram and flash/rom access, separate
memory spaces for code and data, an assembly language that reminds me of
microcoding rather than assembly code, hardware return stack of limited
size, very limited and highly inefficient indirect memory access instead
of pointers. There have been a number of C compilers for the chips,
each of which has its own range of non-standard features, extensions and
limitations necessary to get usable results out of the device. The
official compiler supplied (at a high cost) by the manufacturer at one
time supported structs, and arrays, but not arrays of structs or structs
containing arrays.
 
On the other hand, the manufacturer never stops making devices - even
when they are decades out of date, you can still buy them. That kind of
long-term availability is very rare in the business.
 
And the microcontrollers are incredibly robust. I've seen PIC
microcontrollers rated for 85 °C run happily at 160 °C. Short-circuits,
over-voltages, and all kinds of hardship that would kill a lesser
microcontroller rarely bother PICs. And they are popular with hobby
users as they are available in packages with big legs that are easy to
solder at home.
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)