Thursday, December 17, 2020

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

spuddy@isnotyourbuddy.co.uk: Dec 10 11:11AM

On Thu, 10 Dec 2020 10:20:53 +0000
>On 10/12/2020 08:44, spuddy@isnotyourbuddy.co.uk wrote:
>> If I can I usually do :s/std:://g and be done with it.
 
>Totally irrational, take your meds.
 
I doubt you even know what thats refering to Windows Guy.
spuddy@isnotyourbuddy.co.uk: Dec 09 02:35PM

On Wed, 9 Dec 2020 07:31:10 -0500
>I grew up as a C programmer, and used to think that same way. Finally I
>realized that the typical C program and the typical C++ program were
>very different. C++ programs get MUCH bigger and more complicated, and
 
Do you want to take take a guess at which language the 28 million line
linux kernel is written in? Ditto Windows and MacOS.
 
>code ends up looking into more scopes for name resolution, so habitually
>adding the std:: can be a useful cognitive load reducing agent.
 
I'm not saying it can't be useful if there's a potential name clash, but
generally I just find it irritating.
spuddy@isnotyourbuddy.co.uk: Dec 10 08:44AM

On 10 Dec 2020 07:06:00 GMT
>how it felt to me when I stopped using 'using namespace std'.
 
>Try it on a piece of code you already have, and see. Or read someone
>else's code.
 
Thats the problem , I spend huge amounts of time working on other peoples
code that is littered with std:: all over the damn place that adds zero
to readability for me. If I can I usually do :s/std:://g and be done with it.
Juha Nieminen <nospam@thanks.invalid>: Dec 11 06:58AM

> No, it just gets lost in a sea of ::
 
That's the most ridiculous thing I have heard in a while.
 
You could use the exact same argument to advocate for the removal of all
parentheses, curly braces, brackets, semicolons, commas, hash symbols and
so on and so forth.
 
From all non-ascii characters that are used abundanty in C++ code, why
are you singling out "::" in particular? From all the ones that exist,
why those in particular? What's so special about those?
spuddy@isnotyourbuddy.co.uk: Dec 10 12:37PM

On Thu, 10 Dec 2020 12:05:54 +0000
>use a variety of POSIX-compliant operating systems as well Windows (not sure
>if Windows 10 is currently POSIX-compliant), Fucktarded Guy.
 
>So, again, irrational, take your meds.
 
I see youre up to your usual level of debate.
Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Dec 10 10:20AM

> If I can I usually do :s/std:://g and be done with it.
 
Totally irrational, take your meds.
 
/Flibble
 
--
😎
spuddy@isnotyourbuddy.co.uk: Dec 09 10:41AM

On Wed, 9 Dec 2020 10:01:09 +0000 (UTC)
>quick visual scan you can immediately see where standard library utilities
>are being used. Without the prefix it requires a deeper look, and a deeper
>experience and knowledge of what's from the standard library and what isn't.
 
Everyone is different I suppose. I disagree completely - I find a screen full
of std:: everywhere is just useless visual noise and clutter that detracts from
being able to read the code but perhaps because I started with C decades ago
I'm used to just knowing unqualified names. If I see vector its more readable
than std::vector but each to their own.
Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Dec 10 12:05PM

>>> If I can I usually do :s/std:://g and be done with it.
 
>> Totally irrational, take your meds.
 
> I doubt you even know what thats refering to Windows Guy.
 
It means you are doing a search/replace of "std::" with "" and unlike you I use a variety of POSIX-compliant operating systems as well Windows (not sure if Windows 10 is currently POSIX-compliant), Fucktarded Guy.
 
So, again, irrational, take your meds.
 
/Flibble
 
--
😎
spuddy@isnotyourbuddy.co.uk: Dec 11 04:43PM

On Fri, 11 Dec 2020 14:35:52 +0000
 
>> Thank you for proving my point so emphatically.
 
>You lost the argument, mate, I suggest you move on (and consider your
>irrationality whilst you are at it).
 
There is no argument "mate" because there's no right answer since its
subjective not objective. Perhaps you lot should stop your circle jerking for 5
minutes and go look up the difference.
spuddy@isnotyourbuddy.co.uk: Dec 11 02:34PM

On Fri, 11 Dec 2020 11:33:35 +0000 (UTC)
>> everyone is the same or processes visual information in the same way.
 
>Ah, finally the insults.
 
>I'll take that as a concession of defeat.
 
Thank you for proving my point so emphatically.
spuddy@isnotyourbuddy.co.uk: Dec 10 08:45AM

On Wed, 9 Dec 2020 13:19:32 -0500
>decide if this is referring to a local concept or some global standard one.
 
>If I see just string, does my local namespace provide an enhanced
>version, or is this the standard one.
 
Not a problem I've ever encountered.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 10 07:06AM


> Everyone is different I suppose. I disagree completely - I find a screen full
> of std:: everywhere is just useless visual noise and clutter that detracts from
> being able to read the code
 
You won't see std:: everywhere though. Juha might have mentioned it
upthread, but there won't be as many as you'd think. At least that's
how it felt to me when I stopped using 'using namespace std'.
 
Try it on a piece of code you already have, and see. Or read someone
else's code.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Richard Damon <Richard@Damon-Family.org>: Dec 10 08:02AM -0500

> Who cares? If they're obscure parts of the STL you won't know what they do
> anyway so knowing they're from the STL makes no difference since sticking
> them in google will tell you all you need to know.
 
But you at least know where to look for the description. The std::
prefix bdcomes useful when the program grows bigger than you can hold
most of its parts description in your head at once.
 
Before you hit that point, the std:: may seem to be 'noise', but once
the program passes that point, it become essential 'signal' to help with
understanding.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 16 05:01PM -0800

On 12/16/2020 5:02 AM, Bonita Montero wrote:
>> threads were ended or are in the process of ending.
 
> Sorry, that's stupid. I need a proper cleanup since the threads will
> usually terminate before the process ends.
 
Using detached threads can be a bit sketchy. I never really found a need
to actually use them.
Bonita Montero <Bonita.Montero@gmail.com>: Dec 17 07:22AM +0100

>> usually terminate before the process ends.
 
> Using detached threads can be a bit sketchy. I never really found a need
> to actually use them.
 
I don't need the thread-objects after creation.
Bonita Montero <Bonita.Montero@gmail.com>: Dec 13 03:13PM +0100

> The problem was that the destructor of the base class was calling a pure
> virtual method (something that a good compiler should warn about, but
> it's not an enforceable error).
 
Not the destructor but another function from another thread to the same
object.
Bonita Montero <Bonita.Montero@gmail.com>: Dec 14 09:58AM +0100

> One of the most common kinds of bug in Java/C# is calling a derived
> class method or during initialization, before the derived class' class
> invariant (the basic assumptions about the state) has been established.
 
Is that really a bug but not just a specified different behaviour
than in C++ ?
Bonita Montero <Bonita.Montero@gmail.com>: Dec 13 02:39PM +0100

> The vtable change is because once you enter the base class destructor,
> there isn't any derived class to enter anymore (it has been destructed),
> so the object is now just of the base class.
 
As you can read from my posting I already know that.
 
> classes (maybe calling a method in the base), but even that is
> technically late as you shouldn't be doing even that if there are
> still things referring to it.
 
I'm using a simple function-pointer now.
Juha Nieminen <nospam@thanks.invalid>: Dec 13 02:07PM

> derived class object (because a shared_ptr cannot be constructed before
> the most derived class object is ready, and the destructor of the most
> derived class is not evoked while there is a shared_ptr alive).
 
I don't understand what std::shared_ptr has anything to do with this.
 
The problem was that the destructor of the base class was calling a pure
virtual method (something that a good compiler should warn about, but
it's not an enforceable error).
 
I don't think std::shared_ptr would have remedied that in any way.
When the last std::shared_ptr object is destroyed, it will destroy the
managed object, and the problem will happen. std::shared_ptr doesn't
somehow magically guard against that problem.
Marcel Mueller <news.5.maazl@spamgourmet.org>: Dec 13 02:35PM +0100

Am 13.12.20 um 14:05 schrieb Richard Damon:
 
> The vtable change is because once you enter the base class destructor,
> there isn't any derived class to enter anymore (it has been destructed),
> so the object is now just of the base class.
 
Yes that is the way C++ initializes and destroys the objects.
 
While formally correct I never found a practical use case for this behavior.
In contrast it creates the need for initialization or deinitialization
functions that need to be called manually for every class instance. So
it is correct but useless. From my point of view a language must be
first of all useful.
 
 
Marcel
Brian Wood <woodbrian77@gmail.com>: Dec 16 08:01PM -0800

On Wednesday, December 16, 2020 at 2:09:04 AM UTC-6, David Brown wrote:
 
> Stick to technical posts about /specific/ points in software and C++,
> without getting side-tracked, and perhaps you'll get a little of the
> help you want.
 
I'll post as I see fit. Without fear of jackasses.
 
template<class E>void apps (E&){}
template<class E,class T,class...Ts>void apps (E& e,T t,Ts...ts){
e<<t; apps(e,ts...);
}
 
template<class E=Failure,class...T>[[noreturn]]void raise (char const *s,T...t){
E e{s}; apps(e,t...); throw e;
}
 
These are some functions in my repo. I'd like to know
if they could be rewritten as lambdas. I've tried a bit,
but haven't found a way to do it. Tia.
 
 
Brian
scott@slp53.sl.home (Scott Lurndal): Dec 09 02:57PM


>"Software as a service" is well-known and well established, and has been
>for a long time. And code generators have existed for decades (how old
>is yacc?).
 
Slightly older than LINC (https://en.wikipedia.org/wiki/LINC_4GL).
Bonita Montero <Bonita.Montero@gmail.com>: Dec 09 04:50PM +0100

>> counters were invented? Why do you think RCU was invented? Well,
>> to get rid of atomic RMW's and memory barriers. ;^)
 
> Try not to feed the troll.
 
I'm not trolling. Handing over a queue-item to another thread is so
expensive, that 20 cycles don't hurt.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 09 11:52AM -0800

On 12/9/2020 6:55 AM, Scott Lurndal wrote:
>> counters were invented? Why do you think RCU was invented? Well, to get
>> rid of atomic RMW's and memory barriers. ;^)
 
> Try not to feed the troll.
 
Its difficult because it can mislead others. Her statements on this seem
to be naive at best. Sometimes I think she knows better.
Bonita Montero <Bonita.Montero@gmail.com>: Dec 11 09:40AM +0100

>> the object as the left operand. So you can' define a member operator
>> with two parameters inside the class.
 
> And your answer to "Why the restriction?" is...
 
Because there's another place where to define such operators: globally.
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)