Thursday, April 22, 2021

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

wij <wyniijj@gmail.com>: Apr 21 10:06PM -0700

On Thursday, 22 April 2021 at 06:27:16 UTC+8, Chris M. Thomasson wrote:
> language to the new stuff.
 
> Here is a result of some of my C code generating a single file for
> another program, PovRay, to raytrace for me:
 
When thread was introduced in C++11, I needed to consider using it or not, too.
But after weighing the gains and losses, I decided that RAII feature outweigh
the efficiency. Thus, not using it.
C++ has several places violated its original OO principle, this is just one example.
For instance, the added keyword override/final/delete (good, but it reflects the
half-true "object model" crap) violated the C++ author's ideal (or guideline) about a
a good language "...not add a new feature and then add another to disable it..."
 
wij <wyniijj@gmail.com>: Apr 21 10:38PM -0700

On Thursday, 22 April 2021 at 04:14:27 UTC+8, Chris Vine wrote:
 
> The fact is that C is now a vastly smaller language than, say, C++20.
 
> Of course, similar issues arise for including Rust in the kernel. It
> will be interesting to see how it works out.
 
Yes, C++ fans often ignore the program size issue.
I used often to see C++ complied object file contain almost 1/2 entries
of name symbols, most of them are throw types, rare people care about.
When it comes to the kernel, the entire OS, even 1Gb would make me
worry the life-time of my disk.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 22 12:26AM -0700

On 4/19/2021 9:42 PM, Chris M. Thomasson wrote:
> foo_destroy is guaranteed to be called when foo goes out of scope. So,
> C++ can be more convenient, and safer. No need to use all of C++, but it
> does have its moments.
 
First learning about RAII, even when I learned about ScopeGuard, back in
my C++ days, for some reason, makes me think of the following song:
 
https://youtu.be/UZ2-FfXZlAU
 
Even though I was working with C/C++ well before this song was created,
it makes think way back when I was a little kid using basic on my Atari.
Juha Nieminen <nospam@thanks.invalid>: Apr 22 08:45AM

>> when it was written, much less now.
 
> I would say it has about the same validity as your own arguments about C
> and how much easier C++ is for beginners
 
You are telling me in all seriousness that dynamic string manipulation in C
is as easy as it is in C++, and thus it makes no difference to a beginner
programmer which one he uses?
 
Seriously?
 
As for Linus's famous rant, I could write an entire book giving strong
arguments about why he was wrong even back when he wrote it, and how the
vast majority of the claims he presented in that rant were either completely
idiotic, irrelevant, or just outright false.
 
The only arguments I have seen from C programmers against my original post
have been "use this non-standard extension to make the language better
(not that C is bad and needs any extensions to make it better)".
Not a single actual refutation to my original point: Which one is simpler
from a beginner programmer's perspective, std::string in C++, or raw char
arrays in C (for which standard C offers pretty much no tools to make
their memory management easier or more automatic).
 
The irony here is that the C programmers making that argument are tacitly
admitting C to be limited and defective, and in bad need for extensions that
would make it better and easier to use. While still strongly maintaining
that it doesn't.
 
Oh, and of course the other type of argument: "Yeah? Well, how about
rvalue references!" As if that had anything at all to do about teaching
a beginner programmer about using dynamic strings. I find this "well,
C++ has its complexities too!" to be rather infantile because it doesn't
address the actual original argument.
 
> (you came up with a similar set of arguments about a year or so ago).
 
You are probably confusing me with someone else. I have not written about
this subject a year ago, or even two years ago.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 22 01:48AM -0700

On 4/22/2021 1:45 AM, Juha Nieminen wrote:
 
> You are telling me in all seriousness that dynamic string manipulation in C
> is as easy as it is in C++, and thus it makes no difference to a beginner
> programmer which one he uses?
 
C++ is definitely easier... Perhaps, a nice lesson in C would be, how
could we get fairly close to std::string? So, lets get some simple
functions up and running. Concatenation, indexing into a string, ect...
 
 
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 22 01:51AM -0700

On 4/22/2021 1:45 AM, Juha Nieminen wrote:
 
> You are telling me in all seriousness that dynamic string manipulation in C
> is as easy as it is in C++, and thus it makes no difference to a beginner
> programmer which one he uses?
[...]
 
Perhaps start out with creating a dynamic array in C, then move on to
creating a deque using the dynamic array. Linking arrays together... All
of that fun stuff. ;^)
Juha Nieminen <nospam@thanks.invalid>: Apr 22 08:52AM

> When thread was introduced in C++11, I needed to consider using it or not, too.
> But after weighing the gains and losses, I decided that RAII feature outweigh
> the efficiency. Thus, not using it.
 
That paragraph doesn't make much sense. Care to rephrase it?
 
(If you are claiming that RAII is inefficient, on what exactly do you base
that assumption?)
 
> For instance, the added keyword override/final/delete (good, but it reflects the
> half-true "object model" crap) violated the C++ author's ideal (or guideline) about a
> a good language "...not add a new feature and then add another to disable it..."
 
What exactly is the problem with the 'override' keyword? It has zero effect on
object-oriented design in one direction or the other, and it helps avoiding
mistakes. So what's the problem?
 
As for 'delete', do you prefer the old method of declaring automatically
generated functions as private? That was a bit of a kludge in the first place,
which '=delete' fixes. Now you have a much clearer way to tell the compiler
to not autogenerate those functions, and to get better error messages.
MrSpook_lxrj1vfhmw@qdgb.org: Apr 22 09:37AM

On Thu, 22 Apr 2021 08:45:08 +0000 (UTC)
>from a beginner programmer's perspective, std::string in C++, or raw char
>arrays in C (for which standard C offers pretty much no tools to make
>their memory management easier or more automatic).
 
Dynamic string handling in C really isn't that hard. You've got strdup()
and asprintf() to allocate and calling free() really isn't hard though
obviously you have to remember to do it! The only thing C really needs is
an appendString() function out the box but frankly writing one yourself is a 2
minute job.
 
But given the choice I'd use C++ and std::string.
MrSpook_l0xjKyc@b3jtfv70fxckzmak.net: Apr 22 09:40AM

On Thu, 22 Apr 2021 01:51:05 -0700
 
>Perhaps start out with creating a dynamic array in C, then move on to
>creating a deque using the dynamic array. Linking arrays together... All
>of that fun stuff. ;^)
 
Back when I used to do C developer interviews one of my standard questions
would be "Write some code to create and use a linked list". The number of
people who didn't even know where to start never mind write working code
was quite worrying. I imagine they're the types now writing reams of
garbage javascript for websites.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 22 11:32AM +0100

>>their memory management easier or more automatic).
 
> Dynamic string handling in C really isn't that hard. You've got strdup()
> and asprintf() to allocate
 
Not if you are referring to standard C. These are often available, but
the language itself, as standardised, does not have them.
 
> and calling free() really isn't hard though
> obviously you have to remember to do it!
 
Ensuring that free is called correctly often dictates the shape of a
function, which can be a distraction from writing the algorithm as
clearly as possible. Old C hands may do this semi-automatically, but
it's anther obstacle for beginners.
 
> The only thing C really needs is
> an appendString() function out the box but frankly writing one yourself is a 2
> minute job.
 
Without writing YASS (Yet Another String Struct), every append will
result in an allocation, a copy and a free. C programmers get used to
keeping the size around and over-allocating to ensure these costs are
ameliorated. None of it is hard, but it's more obstacles for beginners.
 
> But given the choice I'd use C++ and std::string.
 
ACK.
 
--
Ben.
MrSpook_f0mj9r@d6g.gov.uk: Apr 22 10:38AM

On Thu, 22 Apr 2021 11:32:07 +0100
>> and asprintf() to allocate
 
>Not if you are referring to standard C. These are often available, but
>the language itself, as standardised, does not have them.
 
If you only use the core language whether C or C++ you'll be rolling your
own for most things.
 
>result in an allocation, a copy and a free. C programmers get used to
>keeping the size around and over-allocating to ensure these costs are
>ameliorated. None of it is hard, but it's more obstacles for beginners.
 
You can't get around the copy no matter how you manage the memory and
with an intelligent implementation of realloc() that attempts to extend the
current memory block hopefully the amount of free'ing will be limited too.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 22 12:35PM +0100

>>the language itself, as standardised, does not have them.
 
> If you only use the core language whether C or C++ you'll be rolling your
> own for most things.
 
Sure. That's the focus of this particular criticism, I think.
 
Mind you, it also raises the question of why stop at strdup and
asprintf? A fuller string library would make it even easier!
 
> with an intelligent implementation of realloc() that attempts to extend the
> current memory block hopefully the amount of free'ing will be limited
> too.
 
I don't think I was clear. If a string is represented as nothing more
that a pointer, appendString() will be expensive. You have to choose
between a simple interface or more efficient allocation. With
 
char *appendString(const char *s1, size_t len, const char *s2)
 
you can avoid a strlen call but if realloc is to be used the beginner
must know the rules: that the string being appended to must be allocated
and not be static, and that the contents of it will change.
 
And to guarantee efficient string growth, you need appendString to over
allocate and return the size_available as well.
 
--
Ben.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 22 01:35PM +0100

On Thu, 22 Apr 2021 08:45:08 +0000 (UTC)
 
> You are telling me in all seriousness that dynamic string manipulation in C
> is as easy as it is in C++, and thus it makes no difference to a beginner
> programmer which one he uses?
[snip]
 
I wasn't commenting specifically on string manipulation, which is
something C++ does better. I was commenting on your more general point
that C++ is considerably easier for beginners to learn.
 
On the specific point of string manipulation, a beginning wanting to
become a competent C++ programmer is going to have to learn the
principles of how C strings work fairly early on, because similar issues
are applicable to other resource management cases for which C++ does
not provide a standard library wrapper, and for which programmers are
going to have to write their own wrapper classes. And of course
std::string does expose C strings in its interface. You are simply not
going to get very far in C++ if you don't understand C strings.
 
> > (you came up with a similar set of arguments about a year or so ago).
 
> You are probably confusing me with someone else. I have not written
> about this subject a year ago, or even two years ago.
 
I think I was thinking of your contributions to the thread "Why should
a c programmer learn c++", in which as I recall you made similar
points. But I am willing to be corrected.
Manfred <noname@add.invalid>: Apr 22 04:30PM +0200

On 4/22/2021 10:45 AM, Juha Nieminen wrote:
> from a beginner programmer's perspective, std::string in C++, or raw char
> arrays in C (for which standard C offers pretty much no tools to make
> their memory management easier or more automatic).
 
For what is worth, my argument is somewhat different:
 
If you try to use a design that would be well suited for C++, it is no
surprise that the same design will lead to frustration if attempted with
in C. Again, despite their name, the languages are very different.
 
In addition, there are well known ways to do OO programming in C, but
from the examples you described your attempt was to replicate in C some
C++ code style instead, with all the clumsiness that may be expected
from such approach.
 
C and C++ have both their strong suits (I am not talking about
performance only) - the fact that string manipulation has a much more
comprehensive support in C++ does not make C++ a better language in
absolute terms, the same applies to containers, the standard library and
all the bells and whistles of C++ - all of these are useful features,
but they are only relevant if actually essential to the problem domain,
otherwise they constitute extra baggage that is best not paid for.
 
One field where C++ really stands up, IMO, is templates and generic
programming - here the life of a C programmer would get really
miserable, but again, it is only as useful as what you are building
actually needs it.
 
(for the record, I have have been using C++ much more than C in my
career, and almost exclusively C++ in more recent years - this is to say
that I am probably not the most keen of C fans)
 
> admitting C to be limited and defective, and in bad need for extensions that
> would make it better and easier to use. While still strongly maintaining
> that it doesn't.
 
It is true that the feature portfolio of C++ is considerably larger than
that of C. As far as I am concerned, this is only a benefit if your
problem domain needs such extra features, otherwise it is actually a
drawback.
 
https://www.stroustrup.com/P0977-remember-the-vasa.pdf
wij <wyniijj@gmail.com>: Apr 22 09:26AM -0700

On Thursday, 22 April 2021 at 13:06:43 UTC+8, wij wrote:
 
> When thread was introduced in C++11, I needed to consider using it or not, too.
> But after weighing the gains and losses, I decided that RAII feature outweigh
> the efficiency. Thus, not using it.
 
Checked again from https://en.cppreference.com/w/cpp/thread/thread, along with
my document and email. Woo, I could have read a premature version of
std::thread (I do not use C++ standard library). I have been so wrong for these years.
Sorry about this part.
 
wij <wyniijj@gmail.com>: Apr 22 09:41AM -0700

On Thursday, 22 April 2021 at 16:52:26 UTC+8, Juha Nieminen wrote:
> That paragraph doesn't make much sense. Care to rephrase it?
 
> (If you are claiming that RAII is inefficient, on what exactly do you base
> that assumption?)
 
Checked again from https://en.cppreference.com/w/cpp/thread/thread, along with
my document and email. Woo, I could have read a premature version of
std::thread (I do not use C++ standard library). I have been so wrong for these years.
Sorry about this part.
 
> generated functions as private? That was a bit of a kludge in the first place,
> which '=delete' fixes. Now you have a much clearer way to tell the compiler
> to not autogenerate those functions, and to get better error messages.
 
As you can only focus on partial sight, like the cases of string manipulations in C.
I cannot make it more clear for you.
"Öö Tiib" <ootiib@hot.ee>: Apr 21 11:59PM -0700

On Monday, 19 April 2021 at 14:05:13 UTC+3, Bonita Montero wrote:
> -pointer, a member-function within this object and the
> parameters for this function. Later you can call this
> generated object like bound().
 
The boost::bind (that std::bind technically is) was specified before
lambdas for ease of constructing callable objects. It was very
useful more than decade ago.
After lambdas the bind is rarely of any use. Both products of
bind and lambda are callable objects of unspecified type but
lambdas are more flexible and easy to follow way to make
callable objects.
Can you explain why on your case that bind is worth using?
Bonita Montero <Bonita.Montero@gmail.com>: Apr 22 10:06AM +0200

> After lambdas the bind is rarely of any use. ...
 
I use bind very often to pack callables with their parameters
into a function-object, f.e. to execute it in another thread.
That's much more convenient than to define a structure which
is handed to a function in another thread.
And lambdas are extremely useful. I use them very often to
have functions in functions which wouldn't have any meaning
outside that function and to prevent repetitive code within
a function.
And I've got some helper-functions like this:
 
template<typename Function>
inline
typename std::invoke_result<Function>::type exc_default( Function &func,
std::exception_ptr *excPtr = nullptr )
{
using namespace std;
try
{
if( excPtr )
*excPtr = nullptr;
return func();
}
catch( ... )
{
if( excPtr )
*excPtr = current_exception();
return typename std::invoke_result<Function>::type();
}
}
 
This returns the default-value of a function if the function gives
an exception. Optionally the exception_ptr is saved (if not this is
optimized away. I use this like this:
 
wstring dstPath = copyNode->dstDir + L"\\" + extractFileName(
fleSrcDir.path.c_str() );
vfle_t dstFilesAndDirs = exc_default( [&]() { return fileList(
dstPath.c_str(), true, true ); }, &fileListExc );
 
So you see a lambda above inside exc_default.
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 22 08:14AM

> vfle_t dstFilesAndDirs = exc_default( [&]() { return fileList(
> dstPath.c_str(), true, true ); }, &fileListExc );
 
> So you see a lambda above inside exc_default.
I stopped using exceptions couple of years ago...
 
--
current job title: senior software engineer
skills: x86 aasembler,c++,c,rust,go,nim,haskell...
 
press any key to continue or any other to quit...
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 22 01:20AM -0700

On 4/22/2021 1:14 AM, Melzzzzz wrote:
>> dstPath.c_str(), true, true ); }, &fileListExc );
 
>> So you see a lambda above inside exc_default.
> I stopped using exceptions couple of years ago...
 
Have you ever used scopeguard?
 
Iirc, one time I used an exception to rollback an operation... It was
called valid, but weird and dangerous back in an old Intel thread forum.
Iirc, it was for a raii guard on my read/write mutex. It would be fun to
try to find the post. Iirc it was somewhere in the following thread:
 
https://community.intel.com/t5/Intel-oneAPI-Threading-Building/Starvation-free-bounded-time-rw-mutex-with-wait-free-fast-pathed/td-p/895233
Bonita Montero <Bonita.Montero@gmail.com>: Apr 22 11:32AM +0200

> I stopped using exceptions couple of years ago...
 
That's stupid. Exceptions are very useful and you can't circumvent
them in C++ if you don't drop using the standard libary.
Andrey Tarasevich <andreytarasevich@hotmail.com>: Apr 22 07:11AM -0700

On 4/19/2021 2:23 AM, Bonita Montero wrote:
> }
 
> Unfortunately the compiler crashes with this.
> C++20-support is still experimental with MSVC.
None of this has any relation to "C++20 support with MSVC" since the
code is obviously ill-formed. Reusing template parameter names inside a
template definition is prohibited in all versions of C++ language.
 
On top of that, the code is doing something nonsensical on top of
something even more nonsensical. I wanted to call it a "solution looking
for a problem", but I can't do even that since it makes no sense whatsoever.
 
> I just tested std::bind with a member-function trick
 
There's no such thing as "member-function trick" and there's no need for
any. `std::bind` works with member functions directly.
 
--
Best regards,
Andrey Tarasevich
Andrey Tarasevich <andreytarasevich@hotmail.com>: Apr 22 07:12AM -0700

On 4/19/2021 4:04 AM, Bonita Montero wrote:
 
> std::bind doesn't work with objects and member-functions.
 
Huh?
 
int main()
{
struct S
{
int a, b, c;
int sum( int d )
{
return a + b + c + d;
}
};
S s;
s.a = s.b = s.c = 1;
 
auto bound = std::bind(&S::sum, &s, 4);
return bound();
}
 
--
Best regards,
Andrey Tarasevich
Bonita Montero <Bonita.Montero@gmail.com>: Apr 22 05:50PM +0200


>      auto bound = std::bind(&S::sum, &s, 4);
>      return bound();
>  }
 
Coooooool, I didn't know that this works.
YOU'RE MY HERO !
MrSpook_tm0@i9d.com: Apr 22 04:25PM

On Thu, 22 Apr 2021 17:50:56 +0200
>>  }
 
>Coooooool, I didn't know that this works.
>YOU'RE MY HERO !
 
I must be missing the point. When would this ever be used?
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)