Friday, October 6, 2017

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

Lynn McGuire <lynnmcguire5@gmail.com>: Oct 05 07:24PM -0500

"The Curious Case of the Longevity of C"
https://www.ahl.com/ahl-tech-the-curious-case-of-the-longevity-of-c
 
"It is the early 1980s and you have been programming in BASIC, FORTRAN,
a bit of Pascal and you read in BYTE magazine of a hot new language: C.
Want to take a bet on it? There are only two bookshops in London that
stock computer books and just one book on C: K&R. The book is expensive,
about a week's rent for a couple of hundred pages but it is the only way
to learn in these pre-Google 1 pre-StackOverflow/GitHub 2 days."
 
Yup, that is when I started looking at C. I bought TurboC in 1987 ???
and I was in love.
 
Lynn
bartc <bc@freeuk.com>: Oct 06 01:59AM +0100

On 06/10/2017 01:24, Lynn McGuire wrote:
> to learn in these pre-Google 1 pre-StackOverflow/GitHub 2 days."
 
> Yup, that is when I started looking at C.  I bought TurboC in 1987 ???
> and I was in love.
 
I bought a copy of K&R in 1982 (I think it was £12; my rent would have
been something over £20).
 
I sold it for £2 to a colleague who was more keen on it than I was.
 
My next purchase was in 1992, nearly £200 for a copy of MS Visual C,
which in the end I never used (I think I gave that away for nothing).
 
I don't think it's cost me any money since then.
 
--
bartc
Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 06 06:42AM

["Followup-To:" header set to comp.lang.c.]
 
On Fri, 2017-10-06, bartc wrote:
 
> My next purchase was in 1992, nearly £200 for a copy of MS Visual C,
> which in the end I never used (I think I gave that away for nothing).
 
> I don't think it's cost me any money since then.
 
In 1988 or 1989. Me and some classmates spent a lot of time in the
school computer lab. I stuck to BASIC and experimented a bit with
TurboPascal on the two PCs they had. But Johan wrote code in a
language called C (or TurboC). I peeked over his shoulder once or
twice. It looked alien and weird.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Ian Collins <ian-news@hotmail.com>: Oct 06 08:05PM +1300

On 10/ 6/17 01:24 PM, Lynn McGuire wrote:
> to learn in these pre-Google 1 pre-StackOverflow/GitHub 2 days."
 
> Yup, that is when I started looking at C. I bought TurboC in 1987 ???
> and I was in love.
 
Um, bought my original K&R from the university bookshop in '79 for the
grand sum of £9.05 :)
 
--
Ian
scott@slp53.sl.home (Scott Lurndal): Oct 06 12:37PM

>> and I was in love.
 
>Um, bought my original K&R from the university bookshop in '79 for the
>grand sum of £9.05 :)
 
Yeah, I bought mine in 1979 for about 8.95USD. And
a mimeo copy of Lion's book for about the same.
 
https://en.wikipedia.org/wiki/Lions'_Commentary_on_UNIX_6th_Edition,_with_Source_Code
Jens Stuckelberger <Jens_Stuckelberger@nowhere.net>: Oct 06 02:12PM

On Thu, 05 Oct 2017 19:24:42 -0500, Lynn McGuire wrote:
 
> "The Curious Case of the Longevity of C"
> https://www.ahl.com/ahl-tech-the-curious-case-of-the-longevity-of-c
 
As curious as the longevity of the wheel. Which many try to
reinvent, over and over again.
legalize+jeeves@mail.xmission.com (Richard): Oct 06 05:38PM

[Please do not mail me a copy of your followup]
 
Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code
>to learn in these pre-Google 1 pre-StackOverflow/GitHub 2 days."
 
>Yup, that is when I started looking at C. I bought TurboC in 1987 ???
>and I was in love.
 
It wasn't the only way to learn C and in fact wasn't the way that I
learned it. The Bell Labs Unix editions had a command called "learn"
and you could type:
 
$ learn C
 
at the command prompt to get an interactive tutorial on the language
syntax and writing programs in it. Even though I already understood
the difference between the address and the data at that address, for
some reason the * syntax threw me off on that first attempt to learn
C. I didn't pick it up again for another 4 years or so and by then
I'd been doing enough programming that the * syntax didn't give me a
hard time anymore.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Ian Collins <ian-news@hotmail.com>: Oct 06 08:15PM +1300

On 10/ 6/17 08:02 AM, Jorgen Grahn wrote:
> work with); I don't want a third one, especially if it's more
> open-ended than the other two.
 
> I guess design bias like that is the reason I've never used variant/any/etc.
 
For the infrastructure support applications I'm frequently called upon
to write, JSON is a good internal and external format to use. These
applications tend to follow a pattern along the lines of get tree like
data from A, manipulate it and merge it with B or compare tree like data
from A and B and update one to match the other. It's easier just to use
JSON to transfer the data and manipulate it without needing to know the
types involved.
 
Once you have a set of algorithms (along the lines of the standard
container algorithms) to manipulate JSON objects, you can reuse them for
processing pretty much anything.
 
--
Ian
Juha Nieminen <nospam@thanks.invalid>: Oct 06 08:12AM


> IMHO, a list of any (std::any or boost::any) is the way to go in this
> particular case (unless the OP adds more information to consider using a
> list of variant)
 
The traditional object-oriented way is to have a
 
std::list<std::unique_ptr<SomeBaseClass>>
 
and then creating all the types you want to be able to add there
as derived classes of that SomeBaseClass.
 
This may be a bit more cumbersome in C++ because if you want to
store, for example, an int, you'll have to create your own class,
derived from SomeBaseClass, that behaves like an int.
legalize+jeeves@mail.xmission.com (Richard): Oct 06 05:31PM

[Please do not mail me a copy of your followup]
 
Ian Collins <ian-news@hotmail.com> spake the secret code
 
>Once you have a set of algorithms (along the lines of the standard
>container algorithms) to manipulate JSON objects, you can reuse them for
>processing pretty much anything.
 
Indeed. I do find myself using nodejs for this sort of fiddling.
Works great for things that aren't performance sensitive. Even so, I
wouldn't discount the throughput you can get through nodejs because
all the IO is asynchronous. I wrote a dashboard for a team I worked
on that scrubbed through all the source code looking for TODO comments
and such and it was much faster than I expected. That might have
changed if I had all the source code on a fast SSD instead of spinning
rust, though :).
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
bitrex <bitrex@de.lete.earthlink.net>: Oct 06 09:28AM -0400

Is there a way to extend std::char_traits to define my own custom
character sets, using some fundamental type as storage, such that I can
then use the usual iostream and string operations on a std::basic_string
which is templated with the custom type?
 
Just for the sake of argument say I wanted some kind of set where all
the printable letters of the alphabet were mapped to the integers modulo
ten, so if I instantiated a std::basic_string with i.e. "abcde" that
would be converted to "01234", and the latter is what I would get if I
used cout or the methods std::basic_string::data(),
std::basic_string::c_str(), etc.
bitrex <bitrex@de.lete.earthlink.net>: Oct 06 09:29AM -0400

On 10/06/2017 09:28 AM, bitrex wrote:
 
> Just for the sake of argument say I wanted some kind of set where all
> the printable letters of the alphabet were mapped to the integers modulo
> ten, so if I instantiated a std::basic_string with i.e.

^^ E.G.
"James R. Kuyper" <jameskuyper@verizon.net>: Oct 06 11:02AM -0400

On 2017-10-06 09:28, bitrex wrote:
> character sets, using some fundamental type as storage, such that I can
> then use the usual iostream and string operations on a std::basic_string
> which is templated with the custom type?
 
Yes. char_traits was specifically designed with such usage in mind.
Define a POD class type of your own that uses that fundamental type as
its storage unit, and then specialize std::char_traits<> for that class
type, meeting all of the requirements specified in table 62 of the
standard. If you do that, you should be able to use std::basic_string
with your character type.
 
> would be converted to "01234", and the latter is what I would get if I
> used cout or the methods std::basic_string::data(),
> std::basic_string::c_str(), etc.
 
That, on the other hand, I doubt you can do. I'd have to trace through a
large portion of the standard to be sure, but I believe that the string
oriented stuff all is designed on the assumption that characters are
constant: if you store an 'a' in a string, you must get back an 'a' when
you retrieve it from the string. You shouldn't get back a '0'. You
shouldn't try to figure out a way to make std::basic_string do this
implicitly - you should create code that explicitly performs the
conversion your talking about.
Daniel <danielaparker@gmail.com>: Oct 05 07:11PM -0700

On Thursday, October 5, 2017 at 6:18:19 PM UTC-4, James R. Kuyper wrote:
 
Could I ask a somewhat tangential question, since you seem to be well versed in this stuff? Is there a logical explanation why we have three char types: char, signed char, and unsigned char?
 
Thanks!
Daniel
Paavo Helde <myfirstname@osa.pri.ee>: Oct 06 12:45PM +0300

On 5.10.2017 23:46, Daniel wrote:
 
> Point taken :-) On the other hand, you can't sensibly use substr on a utf8
> encoded string either, at least for arbitrary indices. find can work, but only because of UTF-8's self-synchronizing features.
 
Why should I use substr() on UTF-8 with an arbitrary index? Substr() is
used for extracting a specific piece of the string, if I have no idea
what I am extracting then there is no point in extracting it.
 
Typically substr() is using an index from a previous find(), which works
fine on UTF-8 as you mentioned. Example: extract the part of the string
after the last slash. Nobody cares if there are any UTF-8 characters
before or after the slash, everything is working just fine.
 
Cheers
Paavo (using substr() on UTF-8 for 15 years already).
Bo Persson <bop@gmb.dk>: Oct 06 11:54AM +0200

On 2017-10-06 04:11, Daniel wrote:
> On Thursday, October 5, 2017 at 6:18:19 PM UTC-4, James R. Kuyper wrote:
 
> Could I ask a somewhat tangential question, since you seem to be well versed in this stuff? Is there a logical explanation why we have three char types: char, signed char, and unsigned char?
 
It goes all the way back to the 1970's when the C language was first
ported to a couple of different machines.
 
It turned out that on some instruction sets it was more efficient to
make char an unsigned type. So they did. And as long as you use 7-bit
ASCII it doesn't matter.
 
But it was also noticed that some people had already been using char for
calculations of small values (would now use int8_t). So it was decided
to add signed char to allow that on hardware that had plain char unsigned.
 
And, of course, you might then need unsigned char when moving code in
the other direction.
 
And there we are.
 
 
Bo Persson
Bo Persson <bop@gmb.dk>: Oct 06 12:02PM +0200

On 2017-10-05 22:46, Daniel wrote:
 
> so I thought I'd run that by here, to see what people here thought. All
> other things equal, I'd prefer to leverage existing things than to
> introduce new things. That's all.
 
There is a proposal for an array_view
 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0122r0.pdf
 
but there has not been enough agreement on the details (or possibly its
potential overlap with the Ranges proposal) for it to enter the standard.
 
The current string_view seems to be a subset that has "escaped" from
those discussions and made it into the standard on its own.
 
 
 
Bo Persson
Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 06 01:07PM

On Fri, 2017-10-06, Paavo Helde wrote:
 
> Typically substr() is using an index from a previous find(), which works
> fine on UTF-8 as you mentioned. Example: extract the part of the string
> after the last slash.
 
Or any kind of parsing of text where the important syntactic tokens
are ASCII.
 
> Nobody cares if there are any UTF-8 characters
> before or after the slash, everything is working just fine.
 
Which is of course why UTF-8 was designed as it was.
 
Often people seem to forget that it's not just /any/ soup of chars;
those in the ASCII range map 1:1 to actual ASCII characters.
 
ISTR that the original specification for UTF-8 summarizes pretty well
what you can do with these strings, and what you cannot do.
 
> Cheers
> Paavo (using substr() on UTF-8 for 15 years already).
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"James R. Kuyper" <jameskuyper@verizon.net>: Oct 06 10:47AM -0400

On 2017-10-05 22:11, Daniel wrote:
> On Thursday, October 5, 2017 at 6:18:19 PM UTC-4, James R. Kuyper wrote:
 
> Could I ask a somewhat tangential question, since you seem to be well versed in this stuff? Is there a logical explanation why we have three char types: char, signed char, and unsigned char?
 
No, but there is a historical one. In the early days of C, there was
only char, which was signed on some platforms, and unsigned on others.
This was allowed for the same reason that the representation of "int"
and "float" were allowed to be different on different implementations of
C. This allowed C to be implemented in the most efficient way for each
machine. All members of the basic execution character set are required
to be positive, which was not a problem for ASCII and it's many
variants. However, in EBCDIC, for example, many of those members have
the high bit set, so the only way to use EBCDIC as the character
encoding was to make char unsigned.
 
By the time the C language was standardized, there was a large body of
code that depended upon char being signed, and another large body of
code that depended upon char being unsigned, so that changing char to
mandate that it be exclusively one or the other would break far too much
code, either way. Instead, the committee decided to invent two new
types, unsigned char and signed char, for which the signedness was
guaranteed.
 
When C++ was created, it retained these features.
 
In practice, char should be used for text. unsigned char should be used
when you wish to examine the object representation of other types.
Unsigned char and signed char should be used when you need to store
small numbers, but only when you need to store so many of them that it's
important to minimize storage space.
Christian Gollwitzer <auriocus@gmx.de>: Oct 06 08:37AM +0200

Hi,
 
I've just watched the recent talk from Herb Sutter:
 
https://www.youtube.com/watch?v=4AfRAVcThyA
 
Wow, this is awesome. I've been wondering for years why C++ has such an
odd way to do metaprogramming, either you can use the outdated
preprocessor, which has no knowledge of types and can't even express a
simple loop without hardcore trickery, or you are stuck with an abuse of
the type system which is even more impenetrable.
 
Finally, there is a sane proposal on the table, and they even have a
prototype implementation in clang.
 
Christian
David Brown <david.brown@hesbynett.no>: Oct 06 08:48AM +0200

On 06/10/17 08:37, Christian Gollwitzer wrote:
 
> Finally, there is a sane proposal on the table, and they even have a
> prototype implementation in clang.
 
> Christian
 
I haven't looked at the video link, but I'm guessing you are talking
about metaclasses. (Why do people post links like this with no
explanation or information? I guess it is from the generation brought
up on pads and youtube as their main source of information. I greatly
prefer to /read/ stuff - varying the speed to match my interest as I go.)
 
Yes, metaclasses look like a fantastic idea that will open up a whole
lot of new ways to work in C++. I look forward to them.
 
But in the meantime, there is a lot that has happened in C++
metaprogramming between C++98 templates and now. Templates have
improved in a variety of ways, and "constexpr" functions - especially
with their updates in C++14 - give you a great deal. Yes, you can make
loops - with no trickery at all, just write the loop in a constepxr
function. And for the brave, gcc has concepts support tracking the
planned C++20 feature.
Christian Gollwitzer <auriocus@gmx.de>: Oct 06 09:31AM +0200

Am 06.10.17 um 08:48 schrieb David Brown:
> explanation or information? I guess it is from the generation brought
> up on pads and youtube as their main source of information. I greatly
> prefer to /read/ stuff - varying the speed to match my interest as I go.)
 
I'm sorry if this wasn't obvious enough. The talk is indeed about
metaclasses, but this metaclass thing rests upon an extended "constexpr"
which allows to emit code. So it is about compile-time code generation.
I posted the video link merely because I haven't seen it elsewhere.
There is a link on this youtube page to a github repo with the slides:
https://github.com/CppCon/CppCon2017/blob/master/Keynotes/Meta%20-%20Thoughts%20on%20Generative%20C%2B%2B/Meta%20-%20Thoughts%20on%20Generative%20C%2B%2B%20-%20Herb%20Sutter%20-%20CppCon%202017.pdf
 
I couldn't find a paper-like write-up for the talk.
 
> loops - with no trickery at all, just write the loop in a constepxr
> function. And for the brave, gcc has concepts support tracking the
> planned C++20 feature.
 
I haven't been following it too closely, but for instance such a beast:
 
https://codereview.stackexchange.com/questions/133668/constexpr-sin-function-c-14
 
drives me away. Do I really need to build my own sine function to be
able to use it in a constexpr? In order to get a trigonometric lookup
table currently I'm using a different language to generate C++ code,
which is of course not satisfying.
 
There is another talk about extending constexpr in this conference:
https://www.youtube.com/watch?v=PJwd4JLYJJY
 
 
Christian
David Brown <david.brown@hesbynett.no>: Oct 06 11:00AM +0200

On 06/10/17 09:31, Christian Gollwitzer wrote:
> able to use it in a constexpr? In order to get a trigonometric lookup
> table currently I'm using a different language to generate C++ code,
> which is of course not satisfying.
 
No, you don't need your own sine function - it seems to be fine to use
std::sin in constexpr functions. (I use the phrase "seems to be fine",
because it works in practice when I tested it, but I am not sure if the
standards guarantee it is correct.) Here is an example - it generates a
sine table with int16_t entries, such as one might want in a small
embedded system:
 
#include <stdint.h>
#include <cmath>
 
constexpr double const_sine(double x) {
return std::sin(x);
}
 
const auto pi = 3.14159265358979323846264338327;
const auto pi2 = 2 * pi;
 
template<class T, int N> struct array {
T elems[N];
 
constexpr T& operator[](size_t i) {
return elems[i];
}
constexpr const T& operator[](size_t i) const {
return elems[i];
}
};
 
const auto size = 128;
using Table = array<int16_t, size>;
 
constexpr Table makeTable() {
Table t{};
for (auto i = 0; i < size; i++) {
const auto angle = (i * pi2 / size);
const auto s = const_sine(angle);
t[i] = 32767 * s;
}
return t;
}
 
extern const Table sine_table = makeTable();
 
Ben Bacarisse <ben.usenet@bsb.me.uk>: Oct 06 11:18AM +0100


> On 06/10/17 09:31, Christian Gollwitzer wrote:
>> Am 06.10.17 um 08:48 schrieb David Brown:
>>> On 06/10/17 08:37, Christian Gollwitzer wrote:
<snip>
>>>> https://www.youtube.com/watch?v=4AfRAVcThyA
<snip>
>>> ... I greatly prefer to /read/ stuff - varying the speed to match
>>> my interest as I go.)
 
Me too. Video seems to me to a dreadful way to convey technical
information. It makes sense to have conferences about things, but the
old way was always to have published proceedings.
 
<snip>
>> I couldn't find a paper-like write-up for the talk.
 
There's this:
 
https://herbsutter.files.wordpress.com/2017/07/p0707r1.pdf
 
but it's not about the talk. It's a detailed technical description of
the proposal (presumably and early version).
 
<snip>
> std::sin in constexpr functions. (I use the phrase "seems to be fine",
> because it works in practice when I tested it, but I am not sure if the
> standards guarantee it is correct.)
 
clang says no and gcc says yes. These are all with -std=c++14 and
-pedantic (plus warning flags) to try to get standard conformance
without extensions.
 
clang says (of your example)
 
constexpr double const_sine(double x) {
^
t.cc:6:12: note: non-constexpr function 'sin' cannot be used in a constant
expression
return std::sin(x);
^
 
> }
 
> const auto pi = 3.14159265358979323846264338327;
> const auto pi2 = 2 * pi;
 
gcc wants these to be constexpr -- my gcc version (5.4.0) won't compile
the example without it -- but clang is not bothered. I wonder what's up
here. Neither gcc not clang compiled the example without change but for
different reasons. Am I missing some option?
 
(gcc also objects to size_t not being defined. I never know what
headers are obliged to define size_t and which ones are not, but I added
cstddef to be sure.)
 
<snip>
--
Ben.
David Brown <david.brown@hesbynett.no>: Oct 06 12:38PM +0200

On 06/10/17 12:18, Ben Bacarisse wrote:
 
> clang says no and gcc says yes. These are all with -std=c++14 and
> -pedantic (plus warning flags) to try to get standard conformance
> without extensions.
 
Yes, I have just tried that, and got the same results. I also note that
std::sin is not specified as "constexpr" in the standards (it's always
hard to add that kind of thing as an afterthought, especially if "errno"
may be involved).
 
> the example without it -- but clang is not bothered. I wonder what's up
> here. Neither gcc not clang compiled the example without change but for
> different reasons. Am I missing some option?
 
-std=gnu++14 or -std=c++14 should be all you need (it's the default for
later gcc versions).
 
 
> (gcc also objects to size_t not being defined. I never know what
> headers are obliged to define size_t and which ones are not, but I added
> cstddef to be sure.)
 
Testing on godbolt.org gave complaints on missing size_t for some
versions, and not others - varying according to version and target.
Adding <cstddef> sounds like a good idea.
 
I did not manage to get gcc to complain about pi and pi2 not being
constexpr, no matter which options I tried.
 
 
But the conclusion is that std::sin is not guaranteed by the standards
to be usable in constexpr like this, which is a shame - it is exactly
the kind of function people would want to use for building tables. Even
the simple:
 
constexpr auto pi = 4 * std::atan(1);
 
works in gcc, but not clang.
 
Time to moan to the C++ standards people, I think!
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)