Sunday, September 11, 2022

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

Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 10 04:26PM -0700


>> Lynn
 
> How is this different from this file?
 
> <https://gcc.gnu.org/onlinedocs/gcc-12.2.0/cpp.pdf>
 
That's a manual for the GNU C preprocessor.
 
This new document is about the C language (with a strong emphasis on the
gcc variant). It's intended to incorporate the preprocessor manual.
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Sep 11 07:07AM +0200

On 10 Sep 2022 21:56, Michael S wrote:
> gcc, python, make and binutils installed. Which is true in case of myself, but but wrong
> for 99% of Windows users. So, for those 99% there is a need to install another 2 or 5 GB.
 
> I wonder, if RMS is doing it intentionally or out of ignorance.
 
I typed `bash` in Windows Cmd, to enter Ubuntu in Windows Subsystem for
Linux, and followed the given recipe:
 
sudo apt update
sudo apt install texlive-latex-extra
sudo apt install ghostscript
sudo apt install texinfo
git clone https://git.savannah.gnu.org/git/c-intro-and-ref.git
cd c-intro-and-ref
makeinfo --html -v c.texi -o c.html --no-split
 
 
I just changed "html" to "pdf".
 
For some reason it wouldn't accept these commands in one single paste. I
had to paste one command at a time. And in typical *nix land fashion
each produced an avalanche of installation progress messages, gah.
 
But it worked. :) The generated PDF has a standard bookmarks contents
listing, that's nice.
 
---
 
Just by skimming through the pages I learned that the g++ restriction to
Unicode escapes in identifiers, not the Unicode characters themselves,
is actually a C restriction, one that I was not aware of.
 
So, g++ implements the C rules, but not the C++ rules.
 
Interesting.
 
 
- Alf
Muttley@dastardlyhq.com: Sep 11 08:29AM

On Sat, 10 Sep 2022 18:16:45 +0200
 
>> Lynn
 
>C is a good language to learn programming
>but actually not to solve real tasks.
 
Real tasks such as most OS kernels and all the GNU command line utilities?
Muttley@dastardlyhq.com: Sep 11 08:29AM

On Sat, 10 Sep 2022 17:04:06 GMT
 
>>C is a good language to learn programming
>>but actually not to solve real tasks.
 
>I think you have that backwards. Really.
 
Story of his/her/its life.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 11 11:16AM +0200


>> C is a good language to learn programming
>> but actually not to solve real tasks.
 
> Real tasks such as most OS kernels and all the GNU command line utilities?
 
That's a matter of the writer's mindset and tradition and
not of necessities.
Muttley@dastardlyhq.com: Sep 11 09:44AM

On Sun, 11 Sep 2022 11:16:14 +0200
 
>> Real tasks such as most OS kernels and all the GNU command line utilities?
 
>That's a matter of the writer's mindset and tradition and
>not of necessities.
 
The necessity is for a language that can have embedded assembler, is very
efficient to compile and once compiled and is explicit. Because of this C++'s
hidden conversions, exceptions and most of the STL can be ruled out which
doesn't leave much left thats an advantage over C.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 11 01:42PM +0200

> efficient to compile and once compiled and is explicit. Because of this
> C++'s hidden conversions, exceptions and most of the STL can be ruled
> out which doesn't leave much left thats an advantage over C.
 
That all isn't a problem in the kernel if you know what you do.
Kernel-Programmers are very skilled and the should be able to
handle that, but it's not up to their mindset.
I wouldn't say that everything of the STL could be used inside
the kernel, but it would be possible to write adaptions, f.e.
to use special allocators for different types of allocations.
Exceptions wouldn't be a problem inside the kernel, although
they wouldn't make sense in any place.
David Brown <david.brown@hesbynett.no>: Sep 11 01:50PM +0200

On 10/09/2022 21:56, Michael S wrote:
> wrote:
>> "Richard Stallman Announces C Reference"
 
>> https://www.i-programmer.info/news/184-cc/15705-richard-stallman-announces-c-reference.html
 
"Richard Stallman (RMS) is a controversial figure - you either like or
> wrong for 99% of Windows users. So, for those 99% there is a need to
> install another 2 or 5 GB.
 
> I wonder, if RMS is doing it intentionally or out of ignorance.
 
Lots of people who write technical books do so using TeX (or something
based on TeX - LaTeX, texinfo, etc.). There is nothing that compares to
TeX (and its friends), in the right hands, for the quality of the
output. And for people who are used to it, it is vastly more efficient
in use than word processors or other gui tools.
 
So, do you think he should be using significantly inferior tools just
because people using an inferior OS (in his eyes, at least) probably
don't have these tools already installed? Of course not.
 
This book is a work in progress, as I understand it. When it is ready,
I'm sure you'll be able to view it as a pdf or html on whatever system
you like. In the meantime, if you want to see its current state, you
have to have the appropriate software.
Michael S <already5chosen@yahoo.com>: Sep 11 05:53AM -0700

On Sunday, September 11, 2022 at 2:50:20 PM UTC+3, David Brown wrote:
 
> So, do you think he should be using significantly inferior tools just
> because people using an inferior OS (in his eyes, at least) probably
> don't have these tools already installed? Of course not.
 
No, I think that he should periodically check in generated .html or .pdf
or both into source control. Once per month sounds like good enough.
And at the same time to push it to one of the popular repositories with
no0b-friendly front end. Preferably, github, but if his ideological pureness
does not allow that then one of several alternatives.
Of course, if somebody wants to be totally user-friendly then he would
supply one of e-book formats as well, e.g. ideologically acceptable epub.
But I realize that in this particular case it is too much to ask.
 
As to word processors, I am in a full agreement with everybody who thinks
that word processor format is not any better for distribution of the book
than internal format of RMS's tools.
I would be equally unhappy with the need to install MS Office or Libre
Office as I am with the need to install texlive-latex-extra.
 
 
> This book is a work in progress, as I understand it. When it is ready,
> I'm sure you'll be able to view it as a pdf or html on whatever system
> you like.
 
See, *I* already can see it as pdf or html on whatever system I like.
But I care (or pretend to care :-) about less tech-savvy souls.
And about wasting Internet bandwidth and disk space.
 
> In the meantime, if you want to see its current state, you
> have to have the appropriate software.
 
BTW, I didn't read it and there is approximately zero chance that I's ever
read it entirely, but I took a look at some topics and found it (surprise!)
rather reasonable in views and competently written.
Muttley@dastardlyhq.com: Sep 11 03:44PM

On Sun, 11 Sep 2022 13:42:20 +0200
 
>That all isn't a problem in the kernel if you know what you do.
>Kernel-Programmers are very skilled and the should be able to
>handle that, but it's not up to their mindset.
 
Its nothing to do with their mindset, its to do with knowing EXACTLY what the
code is going to do and/or where the program counter is going to go. There
is nothing to fall back on to tidy up any fuckups and no C++ runtime to hold
your hand.
 
>I wouldn't say that everything of the STL could be used inside
>the kernel, but it would be possible to write adaptions, f.e.
>to use special allocators for different types of allocations.
 
You could in theory do a lot of things. Whether the time and effort and extra
bloat would be worth it is another matter. Also the STL throws exceptions and
does hidden conversions.
 
>Exceptions wouldn't be a problem inside the kernel, although
>they wouldn't make sense in any place.
 
Oh yes they would. The kernel already has its own type of exceptions and has
to deal with low level interrupts. The last thing the code needs is C++
exceptions where something gets thrown and the program counter ends up god
knows where because someone forgot to do a catch 5 levels up.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 11 05:55PM +0200

> code is going to do and/or where the program counter is going to go. There
> is nothing to fall back on to tidy up any fuckups and no C++ runtime to hold
> your hand.
 
If you know C++ it's easy to understand what's happening behind the
scenes. Your problem is that you don't understand the language.
 
> You could in theory do a lot of things. Whether the time and effort and extra
> bloat would be worth it is another matter. Also the STL throws exceptions and
> does hidden conversions.
 
There's nothing boatish with STL.
STL does things you'd otherwise do manually.
 
> Oh yes they would. The kernel already has its own type of exceptions and
> has to deal with low level interrupts. ...
 
I don't have interrupts in mind when I talk about exceptions.
And in interrupts you won't allocate resources so it's not
necessary to throw excpetions within them.
 
> The last thing the code needs is C++ exceptions where something gets
> thrown and the program counter ends up god knows where because someone
> forgot to do a catch 5 levels up.
 
Exceptions need some documentation, but thats easier than manual
return code handling.
Muttley@dastardlyhq.com: Sep 11 04:17PM

On Sun, 11 Sep 2022 17:55:22 +0200
>> your hand.
 
>If you know C++ it's easy to understand what's happening behind the
>scenes. Your problem is that you don't understand the language.
 
And you don't understand low level programming. But we knew that already.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 11 06:22PM +0200


> And you don't understand low level programming. But we knew that already.
 
I understand low level programming very good and with every
abstraction step I do I understand what's going on at the
lowest level behind what I do.
scott@slp53.sl.home (Scott Lurndal): Sep 11 04:26PM


>> Real tasks such as most OS kernels and all the GNU command line utilities?
 
>That's a matter of the writer's mindset and tradition and
>not of necessities.
 
But they "solve real tasks", which you claimed wasn't the case. Admit
you were wrong, just this once.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 11 06:35PM +0200

Am 11.09.2022 um 18:26 schrieb Scott Lurndal:
>> not of necessities.
 
> But they "solve real tasks", which you claimed wasn't the case.
> Admit you were wrong, just this once.
 
Yes they do, but with much more work than a proper language
would make.
Michael S <already5chosen@yahoo.com>: Sep 11 09:51AM -0700

> efficient to compile and once compiled and is explicit. Because of this C++'s
> hidden conversions, exceptions and most of the STL can be ruled out which
> doesn't leave much left thats an advantage over C.
 
 
Back in 2008 I found boost::intrusive project very promising.
It promised many of advantages as STL containers without any exceptions
and memory allocation outside of user's control.
Didn't follow it since then.
Would guess, it somehow didn't deliver otherwise by now it would be
part of STL.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 11 06:55PM +0200

Am 11.09.2022 um 18:51 schrieb Michael S:
 
> Didn't follow it since then.
> Would guess, it somehow didn't deliver otherwise by now it would be
> part of STL.
 
I don't know why someone should drop exceptions. Error handling
is sinewy anyway, but exceptions are the most comfortable way to
have error-handling.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 11 12:41PM -0700

On 9/11/2022 8:55 AM, Bonita Montero wrote:
>> your hand.
 
> If you know C++ it's easy to understand what's happening behind the
> scenes. Your problem is that you don't understand the language.
[...]
 
Perhaps I am misunderstanding you here, but, there are differences
behind different STL implementations, no?
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 11 04:17PM -0700

"Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
[...]
> cd c-intro-and-ref
> makeinfo --html -v c.texi -o c.html --no-split
 
> I just changed "html" to "pdf".
[...]
 
Thanks for that.
 
I've found that the provided Makefile doesn't work very well. One minor
point: `make` creates files c, c-1, c-2, and c-3 (no ".info" suffix);
they're usable with the info command: `info ./c`, but it would be more
consistent to name the files c.info, c.info-1, et al. And `make clean`
doesn't delete c-3.
 
Based on your example above, here's what I use to generate info, pdf,
and html documents, once I have a clone of the repo and all required
tools installed:
 
makeinfo --pdf -v c.texi -o c-intro-and-ref.pdf --no-split
makeinfo --html -v c.texi -o c-intro-and-ref.html --no-split
makeinfo --info -v c.texi -o c-intro-and-ref.info --no-split
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
Bonita Montero <Bonita.Montero@gmail.com>: Sep 11 05:18PM +0200

What do you think about this ?
 
#include <iostream>
#include <vector>
#include <string>
#include <functional>
#include <link.h>
 
using namespace std;
 
int main()
{
vector<string> images;
auto fnDlIterate = bind(
[&]( dl_phdr_info *image, size_t size ) -> int
{
try
{
images.emplace_back( image->dlpi_name );
}
catch( bad_alloc const & )
{
return 1;
}
return 0;
}, placeholders::_1, placeholders::_2 );
using fn_callback_t = decltype(fnDlIterate);
if( dl_iterate_phdr(
[]( dl_phdr_info *image, size_t size, void *pFn ) -> int
{
return (*(fn_callback_t *)pFn)( image, size );
}, &fnDlIterate ) )
return EXIT_FAILURE;
for( string const &image : images )
cout << "\"" << image << "\"" << endl;
}
Muttley@dastardlyhq.com: Sep 11 03:45PM

On Sun, 11 Sep 2022 17:18:13 +0200
>What do you think about this ?
 
Enter it into the Obfuscated C++ contest. I'm sure it would do well.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 11 05:51PM +0200

> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> What do you think about this ?
 
> Enter it into the Obfuscated C++ contest. I'm sure it would do well.
 
There's nothing obfuscated if you're used to program functional in C++.
Muttley@dastardlyhq.com: Sep 11 03:53PM

On Sun, 11 Sep 2022 17:51:30 +0200
>>> What do you think about this ?
 
>> Enter it into the Obfuscated C++ contest. I'm sure it would do well.
 
>There's nothing obfuscated if you're used to program functional in C++.
 
Any why would you do that? Use ML or Erlang if thats your thing.
 
Anyway, like all your code, its an overcomplicated mess.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 11 05:57PM +0200


>>> Enter it into the Obfuscated C++ contest. I'm sure it would do well.
 
>> There's nothing obfuscated if you're used to program functional in C++.
 
> Any why would you do that? Use ML or Erlang if thats your thing.
 
C++ has the best of all worlds, functional programming _with_ state.
 
> Anyway, like all your code, its an overcomplicated mess.
 
I program like that every day and for me that's absolutely not
complicated. For the purpose I've shown that's too much effort,
but if you have more complex callbacks that's a real relief.
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.

No comments: