Wednesday, December 14, 2022

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

David Brown <david.brown@hesbynett.no>: Dec 14 02:16PM +0100


> IOW the auto type can differ from expectations.
 
> TBH I've always avoided vector<bool> because of its specialisation. This is
> another reason not to use it.
 
Yes, the problem here is that a std::vector<bool> behaves significantly
differently from all other std::vector types. The intention of the STL
(as it was called in those days) developers was to make something that
is efficient, compact, and as simple to use as other vector types. They
did a reasonable job, but the result is inconsistent and surprising in
some ways. I would much preferred inefficiency and consistency, and a
separate type ("bit_vector") for compactness.
David Brown <david.brown@hesbynett.no>: Dec 14 02:23PM +0100

On 14/12/2022 09:38, Juha Nieminen wrote:
> write names that are as short as possible, as contracted and abbreviated
> as possible, as compressed as possible, just to save typing a few
> characters.
 
I also happen to be working with code written by others today. The code
is a pile of dodo doo-doo. Most of the identifiers have long and
expressive names, but it is still crap code, and still incomprehensible.
I don't think shorter names would have helped much, but they might
have made the code a little more readable in some places - code that is
logically one line would not have been spread over two physical lines.
 
Still, naming choices are not in the top ten problems with the code.
 
I really think if acronyms and short names are the biggest issue you
have with other people's code, either it is very unusual code or you are
missing the most important problems, such as poor structure or overly
long functions.
Muttley@dastardlyhq.com: Dec 14 04:24PM

On Wed, 14 Dec 2022 12:19:37 -0000 (UTC)
>> *inside* itself. How is mynamespace::func() any different from writing
>> mynamespace_func()?
 
>In the latter the prefix is mandatory, in the former it's not.
 
No shit. Well done on completely missing my point.
 
>With the prefix it becomes a lot clearer where that func() is, and thus
>the code is much easier to understand.
 
So why not just use prefixes instead of namespaces?
 
 
>Namespaces can have other uses, such as bringing the names of one namespace
>into another (which, in a way, is a bit like "inheriting" the other
>namespace).
 
But you'd write the fully expressed name anyway, right?
Muttley@dastardlyhq.com: Dec 14 04:30PM

On Wed, 14 Dec 2022 12:28:24 -0000 (UTC)
>> index counter.
 
>What's so hard to understand in the fact that the name 'i' does not tell
>me _anything_ about what it's going to be used for? And that if it's
 
Its convention. 'i' has been the top level index counter since 1980s BASIC.
You'll probably find it used as an index var in for() in just about every large
C and C++ program ever written.
 
>believe how significantly clearer it is when each loop variable is
>named clearly after what it's going to index, compared to if they
>are just named 'i', 'j' and 'k'.
 
Clearer for you maybe. For me i, j and k would be perfectly clear.
 
>I honestly cannot understand what's so controversial about this.
 
Nothing. But I can't understand why you seem to think your personal preferences
are the True Way. Though then you're not alone in that.
 
>It should be quite self-evident: When you express what it's being
>used for, it's much easier to understand than if it's just a
>short generic name that says nothing.
 
Speak for yourself.
 
>> Long winded names are as bad as names that are meaningless.
 
>That's just a completely asinine assertion.
 
Go read some Java.
 
>If long-winded names are bad, then why do you use long words when
>you write English? Why don't you contract every word you use?
 
I guess you've never used SMS.
 
>You use full English words because if you were to contract every
>word your text would become illegible. Why is code any different?
 
A lot of common words in English are short, eg 'a', 'an', 'the'. Same in most
european languages (and probably others). And russian dispensed with the
definate and indefinate articles altogether.
 
>*Tell what you are doing* in your code. Don't make it cryptic and
>obscure for no reason. This should be good programming 101.
>We are not writing code for the obfuscated C code contest.
 
*sigh*
Michael S <already5chosen@yahoo.com>: Dec 14 08:36AM -0800

On Wednesday, December 14, 2022 at 3:23:19 PM UTC+2, David Brown wrote:
> > characters.
 
> I also happen to be working with code written by others today. The code
> is a pile of dodo doo-doo.
 
"Hell is other people's code"
 
Udo Steinbach <trashcan@udoline.de>: Dec 14 05:50PM +0100

Am 2022-12-12 um 18:17 schrieb Scott Lurndal:
> I'll take 'rval' over "returnValue" every time.
 
And why not „CurrentTime"? I name variables after their content, not their
function. One look on the return statement says the reader what it does
return.
What do you do if you have two return statements in which you return two
different variables, name them rval1 and rval2? Or do you assign the
second to rval before return?
--
Fahrradverkehr in Deutschland: http://radwege.udoline.de/
GPG: A245 F153 0636 6E34 E2F3 E1EB 817A B14D 3E7E 482E
scott@slp53.sl.home (Scott Lurndal): Dec 14 04:50PM


>>What's so hard to understand in the fact that the name 'i' does not tell
>>me _anything_ about what it's going to be used for? And that if it's
 
>Its convention. 'i' has been the top level index counter since 1980s BASIC.
 
How about 1960s Basic? Or Fortran 66, for that matter, where I,J, K, L, M and N are
implictly integer.
scott@slp53.sl.home (Scott Lurndal): Dec 14 05:13PM

>What do you do if you have two return statements in which you return two
>different variables, name them rval1 and rval2? Or do you assign the
>second to rval before return?
 
* @param iocb The IOCB describing the WRITE operation.
* @returns false if the operation succeeded, true for failure.
*/
bool
c_uniline_dlp::ocs_write(c_iocb *iocb)
{
uint8 cmd = iocb->get_op_var1();
bool rval = false;
 
switch (cmd) {
case IOD_OCSWRITE_WC:
lock();
rval = ocs_write_control(iocb);
unlock();
break;
case IOD_OCSWRITE_LOAD_FIRMWARE:
rval = load_firmware(iocb);
break;
case IOD_OCSWRITE_WC_RC:
case IOD_OCSWRITE_WC_RC_INH_TO:
lock();
u_write_failed = false;
u_write_complete = false;
rval = ocs_write_control(iocb);
if (rval) {
while (!u_write_complete) {
bool timeout = u_flip_read.timed_wait(&u_lock, u_write_timeout);
if (timeout && ((cmd & 1) == 0)) {
u_write_failed = true;
set_rd(iocb, IOT_WITH_EXCEPTIONS, RD1_OCS_TIMEOUT);
break;
}
}
if (!u_write_failed) {
stc_read_control(iocb, cmd&1);
}
}
unlock();
rval = false;
break;
default:
d_logger->log("%s OCS Unsupported write op '%1.1lx'\n",
u_dlp_name, iocb->get_op_var1());
set_rd(iocb, IOT_WITH_EXCEPTIONS, RD_DESCRIPTOR_ERROR);
break;
}
 
return rval;
}
 
Given multithreaded code and the required synchronization, it is wise
to limit the number of early 'return' statements in a function.
Muttley@dastardlyhq.com: Dec 14 05:16PM

On Wed, 14 Dec 2022 16:50:42 GMT
 
>How about 1960s Basic? Or Fortran 66, for that matter, where I,J, K, L, M and
>N are
>implictly integer.
 
My programming experience only goes back to the 80s but I'll take your word
for it :)
"daniel...@gmail.com" <danielaparker@gmail.com>: Dec 14 09:40AM -0800

On Wednesday, December 14, 2022 at 6:54:41 AM UTC-5, Ben Bacarisse wrote:
> > assert(v[1] == false); // fails
 
> That "fail" is so obvious that I think there must be a better example of
> something that will baffle the reader.
 
Is it so obvious? I would have thought a typical C++ programmer
would expect bare auto to never deduce a reference. But here
it seemingly does.
 
In any case, the example wasn't designed to baffle the reader,
but to illustrate the problem of using auto in conjunction with functions
returning proxy values invoking only the standard library.
 
 
> Is a wide-spread idiom in which some aggregate accessory (like
> operator[]) really returns something that behaves like a reference but
> which is defeated by the use of auto?
 
It certainly is in numerical libraries such as Eigen and Armadillo , which use
return proxies extensively, particularly for functions and operators returning matrices
(to avoid unnecessary copies). Elsewhere, in pre-auto days Scott Meyers popularized
the use of proxy return types in his series of Effective C++ books. They're not
that rare, including as noted one instance in the standard library.
 
> > to put some effort into convincing himself that it didn't have "auto value =
> > copy of proxy" landmines.
 
> Can you give a cut-down example?
 
See link below. Regarding the potential landmines of using proxy objects ,
ones I've seen include expecting a value type but getting reference semantics
(as illustrated above), acquiring a complex proxy object where member
functions perform expensive lookups for every call, and acquiring objects
that hold pointers to memory that is past the continuation point.
 
>I can't shake the feeling that the
> problem might not be with auto, but with the idiom that is defeated by
> using auto.
 
As noted, the idiom is firmly entrenched in numerical libraries, particularly
in implementations of expression templates.
 
Proxies and auto don't interact well, because auto exposes aspects of
the type that were meant to stay hidden. There have been suggestions
for a language change, where the auto in auto v = foo() or auto& v = foo()
can be deduced as the value type, even if foo() returns a proxy value, see
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0672r0.pdf.
 
In the meantime, it might be prudent to exercise some caution in the use of auto,
and not to blindly use it everywhere.
 
Daniel
Udo Steinbach <trashcan@udoline.de>: Dec 14 06:43PM +0100

Am 2022-12-13 um 09:42 schrieb David Brown:
> calculate_average_of_vector_of_ints() {
>     int the_size_of_the_vector_of_ints_to_average
 
I love practical examples used to support the opposite practical point of view.
 
> Are you seriously suggesting that the first version is "clearer"
 
Cheap straw man.
int CalcAverage(std::vector<int> Throughput) {
{ int Sum= 0;
for (int Current : Throughput)
Sum += Current;
return Sum / Throughput.size();
}
--
Fahrradverkehr in Deutschland: http://radwege.udoline.de/
GPG: A245 F153 0636 6E34 E2F3 E1EB 817A B14D 3E7E 482E
Paavo Helde <eesnimi@osa.pri.ee>: Dec 14 08:01PM +0200

14.12.2022 19:13 Scott Lurndal kirjutas:
> }
 
> Given multithreaded code and the required synchronization, it is wise
> to limit the number of early 'return' statements in a function.
 
Ant the reason to not use a C++-style RAII lock is ...? Nostalgy for C?
scott@slp53.sl.home (Scott Lurndal): Dec 14 06:12PM


>> Given multithreaded code and the required synchronization, it is wise
>> to limit the number of early 'return' statements in a function.
 
>Ant the reason to not use a C++-style RAII lock is ...? Nostalgy for C?
 
1) the code was written quite some time ago, C++ 2.1 era.
 
2) I prefer to keep critical sections as small as possible,
particularly in CPU-bound multithreaded applications like this one.
 
3) I've found that using RAII prevents the programmer from actually thinking
and reasoning about the critical section; instead they just blindly lock
an entire function and all the functions called from it (which may acquire
locks of their own, and may even recurse).
David Brown <david.brown@hesbynett.no>: Dec 14 08:01PM +0100

On 14/12/2022 17:50, Scott Lurndal wrote:
 
>> Its convention. 'i' has been the top level index counter since 1980s BASIC.
 
> How about 1960s Basic? Or Fortran 66, for that matter, where I,J, K, L, M and N are
> implictly integer.
 
Or 1970's Forth, where I and J are standard words built into the
language as the way to access loop counters.
Michael S <already5chosen@yahoo.com>: Dec 14 05:37AM -0800

> > their own internal things.
 
> Google most decidedly supports Kotlin. Microsoft is poking
> around with rust.
 
Cotlin and Rust are not direct competitors. One is for applications,
esp. UI applications, another is for systems, infrastructure, libraries.
I'd guess some people write big, complex applications in Rust, but that's
mostly because they are masochists.
 
> Google is also putting resources into Carbon,
> and pulling resources away from clang.
 
According to my understanding, Carbon is 100% reliant on LLVM
so if Google see a future in Carbon it can't abandon support
of LLVM. Which automatically helps clang as primary LLVM front end.
Michael S <already5chosen@yahoo.com>: Dec 14 05:56AM -0800


> >And D, among others. I wish D had caught on more.
> Don't forget Dart. Another emanation from Google which no doubt they'll get
> bored with in a few years and drop like most of their projects.
 
My impression from reading Wikipedia article is that Google as firm
got bored with Dart around 2014-2015. As a consequence, all senior
devs left a project and most of them left Google as well.
Despite that it seems that Google still willing to keep development
financed, if barely.
I could be wrong about it.
 
> And on MacOS there's Swift which is supposed to be a better Objective C.
> Frankly it couldn't be much worse. Why Apple don't just use modern C++ and
> get all the benefits not to mention experienced devs on board is anyones guess.
 
May be, because modern C++ is not particularly good language for 99% of
programming tasks?
Muttley@dastardlyhq.com: Dec 14 04:33PM

On Wed, 14 Dec 2022 12:34:59 -0000 (UTC)
>perhaps a bit surprisingly it worked quite well, IMO.
 
>Objective-C adds to the language several things that C++ simply cannot
>add (such as runtime introspection), and C++ adds things that Objective-C
 
If you think having generic objects being thrown around similar to Javas
Object type is a good idea instead of knowing what they are at compile time then
I suppose introspection makes sense. Personally I think its a solution for a
problem that shouldn't exist in the first place.
Muttley@dastardlyhq.com: Dec 14 04:35PM

On Wed, 14 Dec 2022 05:56:36 -0800 (PST)
>guess.
 
>May be, because modern C++ is not particularly good language for 99% of
>programming tasks?
 
I think you're in the wrong newsgroup. Python groups are that way ---->
David Brown <david.brown@hesbynett.no>: Dec 14 07:21PM +0100


>> May be, because modern C++ is not particularly good language for 99% of
>> programming tasks?
 
> I think you're in the wrong newsgroup. Python groups are that way ---->
 
Maybe he thinks no one language is ideal for more than a few percent of
programming tasks? Maybe he thinks C++ is not good for 99% of
programming tasks, but the tasks /he/ does are in the 1%? Maybe he has
no choice but to use it despite it not being ideal? Maybe he likes C++
and uses it because he likes it, even if it is not good for the task in
hand? Maybe he thinks C++ is not particularly good, yet better than all
the rest?
 
There's lots of reasons to be in a C++ newsgroup and to use C++ even if
you think it is not a great language. I think most of the programming
done in C would be better done in other languages, and that most of the
people who program in C would be better off in other languages - but I
still enjoy C and write a lot of code in C and frequent comp.lang.c.
Lynn McGuire <lynnmcguire5@gmail.com>: Dec 14 12:54PM -0600


> And on MacOS there's Swift which is supposed to be a better Objective C.
> Frankly it couldn't be much worse. Why Apple don't just use modern C++ and
> get all the benefits not to mention experienced devs on board is anyones guess.
 
Apple is all about minimizing their competition. Changing languages is
one way to do that.
 
Lynn
Bonita Montero <Bonita.Montero@gmail.com>: Dec 14 06:02PM +0100


> error: expression contains unexpanded parameter pack 'T'
 
> in clang.
 
> Is there a way to get the type inside the function?
 
This makes the check for each variable:
 
#include <iostream>
#include <type_traits>
 
using namespace std;
 
int main()
{
auto variadic = []<typename ... Args>( Args &&... args )
{
auto onString = []<typename T>( T &&t )
{
if constexpr( is_same_v<remove_cvref_t<T>, string> )
cout << t << endl;
};
(onString( forward<Args>( args ) ), ...);
};
variadic( string( "hello world"), 123 );
}
Muttley@dastardlyhq.com: Dec 14 05:17PM

On Wed, 14 Dec 2022 18:02:26 +0100
> };
> variadic( string( "hello world"), 123 );
>}
 
Arrrgh!
 
[Runs screaming to the hills...]
Bonita Montero <Bonita.Montero@gmail.com>: Dec 14 06:23PM +0100

>> }
 
> Arrrgh!
 
> [Runs screaming to the hills...]
 
If you know the lanuguage this is easy to read.
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Dec 14 06:46AM -0800

On Wednesday, December 14, 2022 at 11:43:06 AM UTC, Bo Persson wrote:
 
> Because that's how template argument deduction works. When you
> explicitly supply <int> to a function returning T&&, you get an int&&.
> No surprise here.
 
 
It all makes sense after learning about the "reference collapsing" rules.
 
Although to be honest it does surprise me that those reference collapsing rules made it into the Standard.
Random Channel <rizwanshortsvideos17@gmail.com>: Dec 14 06:03AM -0800

My name is PrettyGirl and I am an OnlyFans account holder. I created this blog to share my love of all things pretty with the world. From fashion and beauty tips to lifestyle advice, I hope to provide some insights into what it means to be a PrettyGirl.
 
Link Here https://t.co/vesP4jLDcI
 
I have always been interested in fashion and beauty, and after years of trial and error, I have finally found my personal style. I love experimenting with different looks and am always on the lookout for new trends. I believe that every woman is beautiful in her own way, and that there is no one standard of beauty.In addition to fashion and beauty, I am also passionate about health and fitness. I try to lead a balanced lifestyle and enjoy working out regularly. I believe that taking care of your body is important for overall health and wellbeing.If you're looking for some pretty inspiration, then you've come to the right place! Thank you for reading and I hope you enjoy my blog.
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)