Friday, December 23, 2022

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

Juha Nieminen <nospam@thanks.invalid>: Dec 23 10:31AM


> for (const auto &pair : string_frequencies) ...
 
> I don't think the reader is helped by having the full type:
 
> for (const std::pair<const std::string, std::vector<double>> &pair : string_frequencies) ...
 
I have never said that there are zero situations where using 'auto' is
warranted and thus it should be avoided at all costs. Some situations
where using it might be warranted (assuming that the resulting code
still is easy to read and understand) include:
 
- lambas (helped by the fact that 'auto' is officially the only way)
- iterators (especially in loop statemets)
- the return value of std::make_shared() etc (although this depends
on the context).
- structured bindings (because 'auto' is mandatory due to the syntax)
 
The example you gave above may also qualify, although I would actually say
that if the type feels way too long to type every time, that might be a
sign that perhaps it could benefit from some abstraction.
 
My main problem is not those situations. It's when some programmers use
'auto' as much as possible, shoving it everywhere where they can. This
can become especially frustrating when knowing the actual type would
be useful in order to better undrestand the code, and it has been
completely hidden via 'auto'.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Dec 23 07:42PM

> - the return value of std::make_shared() etc (although this depends
> on the context).
> - structured bindings (because 'auto' is mandatory due to the syntax)
 
This sort of reasonable exchange was missing from most of the thread.
 
> The example you gave above may also qualify, although I would actually say
> that if the type feels way too long to type every time, that might be a
> sign that perhaps it could benefit from some abstraction.
 
I agree with this last point, but if the details of type are abstracted
you would loose what I thought was your primary intent: to see the exact
details of the type.
 
> My main problem is not those situations. It's when some programmers use
> 'auto' as much as possible, shoving it everywhere where they can.
 
I doubt anyone would approve of shoving auto everywhere it could be
used. I would probably accept more uses of auto that you would but the
exact boundary between reasonable use and overuse is bound to be fuzzy
and personal.
 
> can become especially frustrating when knowing the actual type would
> be useful in order to better undrestand the code, and it has been
> completely hidden via 'auto'.
 
The only thing I'd say about this is that I suspect that in a few of
these cases the fact that actual the type must be known in order to
easily understand the code suggests problems with it that are not really
to do with the use of auto. It would be good to see some actual
examples, but you probably can't post any for legal reasons.
 
--
Ben.
wij <wyniijj5@gmail.com>: Dec 23 01:26AM -0800

template <typename T> struct AA {
T m_val;
 
void f(const T& arg) {
m_val.~T();
new (&m_val) T(arg); // if T(T&) available
// new (&m_val) T(); // if T() available
}
};
 
How should AA::f be written depending on T(T&) or T() is available?
"Öö Tiib" <ootiib@hot.ee>: Dec 23 02:24AM -0800

On Friday, 23 December 2022 at 11:26:24 UTC+2, wij wrote:
> }
> };
 
> How should AA::f be written depending on T(T&) or T() is available?
 
To detect such things one can use std::is_copy_constructible and
std::is_default_constructible from <type_traits>.
 
<https://en.cppreference.com/w/cpp/meta>
wij <wyniijj5@gmail.com>: Dec 23 05:53AM -0800

On Friday, December 23, 2022 at 6:24:56 PM UTC+8, Öö Tiib wrote:
> To detect such things one can use std::is_copy_constructible and
> std::is_default_constructible from <type_traits>.
 
> <https://en.cppreference.com/w/cpp/meta>
 
What if the constructor is different, e.g. T(T*, size_t)? Besides, I cannot
see such a type "is_xxx_constructible<T>::value" is helpful.
Paavo Helde <eesnimi@osa.pri.ee>: Dec 23 04:11PM +0200

23.12.2022 15:53 wij kirjutas:
 
>> <https://en.cppreference.com/w/cpp/meta>
 
> What if the constructor is different, e.g. T(T*, size_t)? Besides, I cannot
> see such a type "is_xxx_constructible<T>::value" is helpful.
 
Maybe you want perfect forwarding?
 
template <typename T> struct AA {
T m_val;

template<class... ARGTYPES>
void f(ARGTYPES&&... args) {
m_val.~T();
new (&m_val) T(std::forward<ARGTYPES>(args)...);
}
};
 
int main() {
 
AA<int> x;
x.f(12);
 
AA<std::string> y;
y.f(10, 'A');
 
}
Bo Persson <bo@bo-persson.se>: Dec 23 03:57PM +0100

On 2022-12-23 at 14:53, wij wrote:
>> std::is_default_constructible from <type_traits>.
 
>> <https://en.cppreference.com/w/cpp/meta>
 
> What if the constructor is different, e.g. T(T*, size_t)?
 
Then you have is_constructible_v<T, T*, size_t>
 
> Besides, I cannot
> see such a type "is_xxx_constructible<T>::value" is helpful.
 
You can check for the set of parameters you expect to use
 
if constexpr (is_constructible_v<T, T*, size_t>)
new (&m_val) T(param1, param2);
 
And perhaps you should use is_nothrow_constructible to not have the
unpleasant surprise of leaving the scope with a destroyed object.
wij <wyniijj5@gmail.com>: Dec 23 08:45AM -0800

On Friday, December 23, 2022 at 10:57:19 PM UTC+8, Bo Persson wrote:
> new (&m_val) T(param1, param2);
 
> And perhaps you should use is_nothrow_constructible to not have the
> unpleasant surprise of leaving the scope with a destroyed object.
 
#include <iostream>
#include <utility>
#include <type_traits>
 
using namespace std;
 
struct DD {
DD() { cout << "DD() ";};
// DD(const DD&) { cout << "DD(const DD&) "; };
// DD(int,char) { cout << "DD(int,char) "; };
// DD(size_t,char) { cout << "DD(size_t,char) "; };
~DD() { cout << "~DD() "; };
};
 
template <typename T> struct AA {
T m_val;
 
void f() {
m_val.~T();
if constexpr (is_constructible<T, int, char>::value) {
cout << "new1: ";
new (&m_val) T(int(1), char(2));
} else if constexpr (is_constructible<T, size_t, char>::value) {
cout << "new2: ";
new (&m_val) T(size_t(1), char(2));
} else if constexpr (is_copy_constructible<T>::value) {
cout << "new3: ";
new (&m_val) T(m_val);
} else if constexpr (is_constructible<T, const T&>::value) {
cout << "new4: ";
new (&m_val) T(m_val);
} else if constexpr (is_default_constructible<T>::value) {
cout << "new5: ";
new (&m_val) T();
} else {
cout << "Fail\n";
}
};
 
};
 
int main()
{
AA<DD> x;
x.f();
cout << "\n";
return 0;
}
 
-------------------
Thanks, Bo Persson and Paavo Helde. Tested fine.
I did not know the syntax " if constexpr (is_constructible<T,int,char>::value)".
Lynn McGuire <lynnmcguire5@gmail.com>: Dec 22 10:10PM -0600

On 12/21/2022 2:37 PM, Lynn McGuire wrote:
>     amethod (xyz, ...);
 
> Thanks,
> Lynn
 
Thanks to all ! I am slowly puzzling my way through this.
 
Thanks,
Lynn
Lynn McGuire <lynnmcguire5@gmail.com>: Dec 22 10:23PM -0600

On 12/21/2022 2:37 PM, Lynn McGuire wrote:
>     amethod (xyz, ...);
 
> Thanks,
> Lynn
 
BTW, I am also looking at this:

https://stackoverflow.com/questions/13326021/how-to-pass-a-3d-array-as-a-parameter-to-function-c-also-do-global-variables
 
Thanks,
Lynn
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 22 03:39PM -0800

On 12/22/2022 12:11 PM, Scott Lurndal wrote:
> keep a string private to each thread where each thread updates the
> string as required without locking; when you need the full status
> append the six strings into a single string.
 
Yes. This is analogous to split counters. Each thread keeps its own
count. If you want to know the sum, well, sum up all of the threads
counters. It scales fairly decently. A lot better than a single shared
counter! :^)
 
 
 
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 22 03:42PM -0800

On 12/22/2022 12:11 PM, Scott Lurndal wrote:
> status independently).
 
> The recursive mutex solution seems fragile and not scalable to large
> numbers of worker threads.
 
recursive mutex makes be get a bit sick from time to time. Brings back
some memories about having to debug some deeply nested locking issues.
God damn it was bad.
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)