Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #124821 > unrolled thread

Re: Resources to learn common lisp?

Back to article view | Back to comp.lang.c++

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Resources to learn common lisp? "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-18 11:05 +0800
    Re: Resources to learn common lisp? red floyd <no.spam.here@its.invalid> - 2026-09-17 21:43 -0700
    Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-18 10:28 +0000
      Re: Resources to learn common lisp? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-18 21:33 +0800
        Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-18 13:51 +0000
          Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-18 14:41 +0000
        Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-18 14:23 +0000
          Re: Resources to learn common lisp? "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-19 00:07 +0800
            Resources to learn Japanese (was: Resources to learn common lisp?) ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-18 16:52 +0000
    Re: Resources to learn common lisp? boltar@caprica.universe - 2026-09-18 15:11 +0000
      Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-18 15:25 +0000
        Re: Resources to learn common lisp? boltar@caprica.universe - 2026-09-18 15:49 +0000
          Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-18 16:05 +0000
            Re: Resources to learn common lisp? boltar@caprica.universe - 2026-09-19 08:29 +0000
              Re: Resources to learn common lisp? "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-19 16:50 +0800
          Re: Resources to learn common lisp? David Brown <david.brown@hesbynett.no> - 2026-09-18 18:18 +0200
            Re: Resources to learn common lisp? "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-19 00:35 +0800
        Why no string switch? (was: Resources to learn common lisp?) ram@zedat.fu-berlin.de (Stefan Ram) - 2026-09-19 12:46 +0000
          Re: Why no string switch? (was: Resources to learn common lisp?) boltar@caprica.universe - 2026-09-19 14:47 +0000
          Re: Why no string switch? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-19 15:42 -0700
            Re: Why no string switch? boltar@caprica.universe - 2026-09-20 07:36 +0000
              Re: Why no string switch? David Brown <david.brown@hesbynett.no> - 2026-09-20 10:06 +0200
      Re: Resources to learn common lisp? "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-18 23:39 +0800

Page 1 of 2  [1] 2  Next page →

#124821 — Re: Resources to learn common lisp?

On 8/27/2026 6:47 PM, Stefan Ram wrote:

>      // Helper to sanitize a word to lowercase alphanumeric characters
>      auto sanitize = [](std::string w) {
>          auto clean = w | std::views::filter([](char c) { return std::isalnum(c); })
>                         | std::views::transform([](char c) { return std::tolower(c); });
>          return std::string(clean.begin(), clean.end());
>      };
Dear Stefan,

I also failed to notice at first glance that your word counting program,
while quite brilliant -- I'll probably give it a try this weekend -- is
failing to properly count "they're", "dog's" and such.  I'm not sure
modern C++ has a std::isenglishword() function, so my proposal would be
something like

   return std::isalnum( c ) || c == '\'' ;

but that fails if the input has Bri'ish quotes 'like this', or TeX
quotes `like this' or even ``like this.''

Has Bjarne thought to include PCRE2 in C++ already?  Can we use a reg-
ular expression to match ' only if it's inside a word?  Do we want to
account for Unicode single curly quotes too?

I have added comp.lang.perl to this discussion, on the off chance this
is already a solved problem with a regular expression.

I have added comp.lang.c++ for the obvious reason.

I am not aware of comp.lang.c++.boost being a real group, do you think
it should be proposed in news.groups.proposals?


Best wishes, and happy word counting in C++!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

[toc] | [next] | [standalone]

#124822

On 9/17/2026 8:05 PM, Johann "Myrkraverk" Oskarsson wrote:
> On 8/27/2026 6:47 PM, Stefan Ram wrote:

> Has Bjarne thought to include PCRE2 in C++ already?  Can we use a reg-
> ular expression to match ' only if it's inside a word?  Do we want to
> account for Unicode single curly quotes too?
> 
> C++ has had a regex library since C++11.

[toc] | [prev] | [next] | [standalone]

#124824

"Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> wrote or quoted:
>Has Bjarne thought to include PCRE2 in C++ already?  Can we use a reg-
>ular expression to match ' only if it's inside a word?  Do we want to
>account for Unicode single curly quotes too?

  "::std::regex" was introduced in C++11 (2011), but due to
  performance problems, it's scheduled to be deprecated.

Newsgroups: comp.lang.misc,comp.lang.c++

[toc] | [prev] | [next] | [standalone]

#124825

On 18/09/2026 6:28 PM, Stefan Ram wrote:
> "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> wrote or quoted:
>> Has Bjarne thought to include PCRE2 in C++ already?  Can we use a reg-
>> ular expression to match ' only if it's inside a word?  Do we want to
>> account for Unicode single curly quotes too?
> 
>    "::std::regex" was introduced in C++11 (2011), but due to
>    performance problems, it's scheduled to be deprecated.
> 
> Newsgroups: comp.lang.misc,comp.lang.c++
> 
> 

Dear Stefan,

Well, in my defense, I haven't used much of C++ since C++98 -- by that I
mean the standard -- since most C++ A.P.Is. are usable with roughly that
knowledge.  I have Meyers' /Effective Modern C++/ on my shelf, but it's
still in my to-read-in-the-near-future pile; thanks to tsundoku.

I also have Stroustrup's 4th edition, but I'm not sure it's worth read-
ing to catch up on the latest?  What do you think?

Now, on the subject of regular expressions, we are now in a quandary, do
we try to fix your word counting program with std::regex, and have it be
uncompilable in the near future, or do we just use PCRE2 and have it be
compilable forever?

I use the word /try/ here because I'm not offhand sure a good word
counting program can be done with strictly a regular expression, and
I am in no hurry to adopt John Levin's [1] for this purpose, and use
L.A.R.L.  I'm leaving off comp.compilers because my Usenet provider
seems to have trouble with posts to moderated Usenet groups, and I
haven't emailed them about it yet; plus this is probably a bit too
simple to bother the compiler experts about, now that I think about
it for the second time.

I am however willing to attempt to use PCRE2 in a C++ program over the
weekend so let's see what happens, and if I have the time for such an
adventure and so forth; no promises.  I mean, compiling PCRE2 with MSVC
can't be that hard, can it?


Best wishes, and happy C++!

[1] The one in the book /Flex & Bison/.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

[toc] | [prev] | [next] | [standalone]

#124826

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote or quoted:
>I also have Stroustrup's 4th edition, but I'm not sure it's worth read-
>ing to catch up on the latest?  What do you think?

  "The C++ Programming Language", fourth edition is excellent to catch
  up on C++11, but we are approaching C++26 now and a lot has changed. 

  You could read the working draft N5046 as of 2026-05-12, but it's a
  bit technical. C++ is moving too fast currently for textbook authors 
  to keep up, so maybe try websites like cppreference!

  The chatbot's comment:

| The transition "but it's a bit technical" is a bit of an
| understatement - the ISO working draft is famously dry and
| notoriously difficult to read for general learning.

  .

[toc] | [prev] | [next] | [standalone]

#124828

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>You could read the working draft N5046 as of 2026-05-12, but it's a
>bit technical. C++ is moving too fast currently for textbook authors 
>to keep up, so maybe try websites like cppreference!

  . . . and the C++ Core Guidelines.

Newsgroups: comp.lang.c++

[toc] | [prev] | [next] | [standalone]

#124827

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote or quoted:
>I use the word /try/ here because I'm not offhand sure a good word
>counting program can be done with strictly a regular expression,

  During this thread I did not think about it as a real
  application, but just as a example for programming. But if
  you ask me about it, the most important thing for a really
  good word-counting program is one's definition of "word".

[toc] | [prev] | [next] | [standalone]

#124834

On 9/18/2026 11:18 PM, Stefan Ram wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote or quoted:
>>> I use the word /try/ here because I'm not offhand sure a good word
>>> counting program can be done with strictly a regular expression,
>> During this thread I did not think about it as a real
>> application, but just as a example for programming. But if
>> you ask me about it, the most important thing for a really
>> good word-counting program is one's definition of "word".
> 
>    For one example, I wrote a program in 2020 to count the fre-
>    quencies of Japanese "words", where I had my program figure
>    out which characters go together by itself using something
>    that vaguely resembles byte-pair encoding (BPE), but I came
>    up with it myself before I ever heard of BPE.

Dear Stefan,

You did not specify what programming language you used for your project,
but I've used KyTea in C++ with great success, so I'm re-adding comp.
lang.c++.

   https://www.phontron.com/kytea

   https://github.com/neubig/kytea

> 
>    Japanese words are usually not separated by spaces. So, my
>    program just observes which combinations of characters appear
>    most frequently in my collection of Japanese texts, but also
>    can deal with words that appear both separated from other words
>    and also as parts of other words. For example, below both "ああ"
>    and "あ" are listed, and the 2*32232 occurences of "あ" in "ああ"
>    are not counted again to get the 22929 occurences of "あ".
> 
>    These are "words" by the definition of my program - which might
>    not agree with other definitions.

For brute force methods, you can also use Jim Breen's dictionary files,
but I have not worked with them directly yet, so cannot say how well
that works in practice.

> 
>    So, now you know which "words" you should learn first because
>    they are most common - from the output of my program (start):
> 
>    It says, "Hai" ("yes") is the most common Japanese word! Readers
>    might be surprised by "ああ" - this appears often in the spoken
>    language I was interested in, but rarely in formal texts.

That's interesting.  I've added japan.lang.japanese, tnn.os.bsd386.
japanese, and uiuc.org.japanese to this discussion, in case someone
there wants to comment on frequent words that don't appear in formal
texts.

> 
>    And we see that the few kanji I know ("何", "私", and "今") are
>    indeed very common! Again the 15591 hits of "何" in isolation
>    are counted only when its not part of the "何か", "何で", and
>    "何だ", which are listed and counted separately. And this also
>    applies to longer sequences correspondingly.
> 
[snip dictionary output].

I also know a few kanji.  Some we can blame on misspent youth, but that
is neither here nor there.  For instance, knowing how "mochiron" = /of
course/ is written in kanji "勿論" is of no use when taking the N5 exam.

A lot of Japanese people don't know this combination of kanji, and will
have to look it up in a dictionary -- or so I've been told.

I don't have a Japanese input method running, and had to copy this from
Jim Breen's website, so I'll refrain from pretending to know much more
of Japanese; mine has gotten quite rusty.

I am working on starting a local /Japanese study group/, but it's been
hard to get everyone together with a regular schedule.  So let's see how
that adventure goes.

I've added comp.edu.languages.natural to this discussion as well.

What educational material do you use when studying Japanese?  For my
next adventure, I've selected

   https://shop.thegreatcourses.com/learning-japanese-a-gateway-into-culture

and I also have a few books on the subject.


Best wishes, and happy Japanese language studies!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

[toc] | [prev] | [next] | [standalone]

#124837 — Resources to learn Japanese (was: Resources to learn common lisp?)

"Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> wrote or quoted:
>What educational material do you use when studying Japanese?

  By the way, a Newsgroups header with many newsgroups is sometimes used
  by spammers, and some newsreader does not even show posts crossposted
  to more than two or three newsgroups. "japan.lang.japanese" might
  be intended for messages in Japanese, and a Subject about Common Lisp
  might look even more like spam in Japanese newsgroups. So I just set
  a Followup-To to a group of which I know that it has had at least
  some traffic in recent years (one can ignore the "sci").

  A snippet from a search engine:

|Netiquette - The Document Foundation Wiki
|18 May 2024 ... Avoid Crossposting. It is almost never
|appropriate to send the same ... Or, if you must, make sure
|you set the Followup-To ...

  Well, my own level is far below N5 (absolute beginner); I only know
  few tiny fragments of Japanese. So all study material I know is
  actually far above my own level. But without further ado, here's the
  best site I know; it's much too advanced for me, but it's very good.

  If nothing has changed, it should contain loads of free
  downloadable mp3s and a PDF with transcripts. The site should
  be findable by "Japanese Audio Flashcard Lessons", and the
  domain name contains "japaneseaudiolessons".

  The audio starts with:

|This is Japanese audio flashcards, lesson one.
|"Please show the passport!" - use the "te" or "de" form of the verb!
|パスポートを見せてください。
|Pasupooto wo misete kudasai.

  When starting an mp3, you get an English prompt and then should
  responds with the Japanese translation which you then can also
  hear. I like this, because I can listen to it when I am doing
  something else but still have the capacity to listen. Also,
  I prefer to learn a language by listening instead of reading.

Newsgroups: comp.lang.misc,comp.lang.c++,comp.edu.languages.natural,japan.lang.japanese,tnn.os.bsd386.japanese,uiuc.org.japanese

Followup-To: sci.lang.japan

[toc] | [prev] | [next] | [standalone]

#124829

On Fri, 18 Sep 2026 11:05:46 +0800
"Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> gabbled:
>Has Bjarne thought to include PCRE2 in C++ already?  Can we use a reg-
>ular expression to match ' only if it's inside a word?  Do we want to
>account for Unicode single curly quotes too?

Instead of ever niche academic circle jerking wrt C++ expansion, it would be
nice if some more basic stuff was added first that other languages have 
supported since their inception. Eg, how about a switch() construct that 
operated on more than just POD types?

std::string mystr = "hello";
:
:
switch(mystr)
{
case "hello": ...
case "world": ...
:
}

etc.

So long as the object had operator==() defined I see no problem with overloading
switch in this way.

The amount of times I've had to write endless if-else's instead of this I've
lost count of.

[toc] | [prev] | [next] | [standalone]

#124830

boltar@caprica.universe writes:   Eg, how about a switch() construct that 
>operated on more than just POD types?

  Expected in C++29:

inspect (mystr) {
    "hello" => { /* ... */ },
    "world" => { /* ... */ },
    _       => { /* default */ }
};

Newsgroups: comp.lang.misc,comp.lang.c++

[toc] | [prev] | [next] | [standalone]

#124832

On 18 Sep 2026 15:25:17 GMT
ram@zedat.fu-berlin.de (Stefan Ram) gabbled:
>boltar@caprica.universe writes:   Eg, how about a switch() construct that 
>>operated on more than just POD types?
>
>  Expected in C++29:
>
>inspect (mystr) {
>    "hello" => { /* ... */ },
>    "world" => { /* ... */ },
>    _       => { /* default */ }
>};

Wtf?? Why an entirely new construct, just overload switch! Also I can 
guarantee than there's a ton of current code that will already be using the
word "inspect" in some way.

[toc] | [prev] | [next] | [standalone]

#124833

boltar@caprica.universe wrote or quoted:
>      Why an entirely new construct, just overload switch!

  Switch already has fall-through semantic which is not desired
  for the new inspect statement. Also parsing both the old and
  the new "case" syntax can become difficult.

>Also I can guarantee than there's a ton of current code that
>will already be using the word "inspect" in some way.

  If the compiler sees "inspect (variable) { ... }", it parses
  it as a pattern-matching block.

  If it sees "int inspect = 5;" or "my_object.inspect()", it treats
  it as a completely valid standard identifier.

Newsgroups: comp.lang.misc,comp.lang.c++
Followup-to: comp.lang.c++

[toc] | [prev] | [next] | [standalone]

#124839

On 18 Sep 2026 16:05:52 GMT
ram@zedat.fu-berlin.de (Stefan Ram) gabbled:
>boltar@caprica.universe wrote or quoted:
>>      Why an entirely new construct, just overload switch!
>
>  Switch already has fall-through semantic which is not desired
>  for the new inspect statement. Also parsing both the old and

Says who?

>  the new "case" syntax can become difficult.

Rubbish. Other languages manage.

>>Also I can guarantee than there's a ton of current code that
>>will already be using the word "inspect" in some way.
>
>  If the compiler sees "inspect (variable) { ... }", it parses
>  it as a pattern-matching block.
>
>  If it sees "int inspect = 5;" or "my_object.inspect()", it treats
>  it as a completely valid standard identifier.

So we treat "inspect" differently to every other keyword in that it can be
used as a variable/function/whatever name too? Well that won't be confusing
at all!

[toc] | [prev] | [next] | [standalone]

#124840

On 9/19/2026 4:29 PM, boltar@caprica.universe wrote:
> On 18 Sep 2026 16:05:52 GMT
> ram@zedat.fu-berlin.de (Stefan Ram) gabbled:
>> boltar@caprica.universe wrote or quoted:
>>>       Why an entirely new construct, just overload switch!
>>
>>   Switch already has fall-through semantic which is not desired
>>   for the new inspect statement. Also parsing both the old and
> 
> Says who?
> 
>>   the new "case" syntax can become difficult.
> 
> Rubbish. Other languages manage.
> 
>>> Also I can guarantee than there's a ton of current code that
>>> will already be using the word "inspect" in some way.
>>
>>   If the compiler sees "inspect (variable) { ... }", it parses
>>   it as a pattern-matching block.
>>
>>   If it sees "int inspect = 5;" or "my_object.inspect()", it treats
>>   it as a completely valid standard identifier.
> 
> So we treat "inspect" differently to every other keyword in that it can be
> used as a variable/function/whatever name too? Well that won't be confusing
> at all!

I don't think that's a problem.  C++ has already maximized the confu-
sion.  What we now have is a saturation of confuddlement, so we can just
change the syntax as we please.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

[toc] | [prev] | [next] | [standalone]

#124835

On 18/09/2026 17:49, boltar@caprica.universe wrote:
> On 18 Sep 2026 15:25:17 GMT
> ram@zedat.fu-berlin.de (Stefan Ram) gabbled:
>> boltar@caprica.universe writes:   Eg, how about a switch() construct that
>>> operated on more than just POD types?
>>
>>   Expected in C++29:
>>
>> inspect (mystr) {
>>     "hello" => { /* ... */ },
>>     "world" => { /* ... */ },
>>     _       => { /* default */ }
>> };
> 
> Wtf?? Why an entirely new construct, just overload switch! Also I can
> guarantee than there's a ton of current code that will already be using the
> word "inspect" in some way.
> 

"inspect" is /not/ expected in C++29 - Stefan is a bit out of date.  It 
was one of several alternative proposals for a new pattern-matching 
feature.  The current candidate is "match", with a syntax like :

	x match {
		0 => std::printf("zero");
		1 => std::printf("one");
		_ => std::printf("something else");
	}

This works like a normal "switch", but there is no fall-through (so no 
"break" statements), and it is not weirdly unstructured.

	s match {
		"zero" => std::printf("zero");
		"one" => std::printf("one");
		_ => std::printf("something else");
	}

It will work with any literal types.  It can also be used to match 
variant types, polymorphic types, etc.

And there are few situations where an existing identifier "match" could 
be in conflict with the new keyword.  (You could cause trouble with a 
macro called "match", but that seems unlikely in real code.)

[toc] | [prev] | [next] | [standalone]

#124836

On 9/19/2026 12:18 AM, David Brown wrote:
> On 18/09/2026 17:49, boltar@caprica.universe wrote:
>> On 18 Sep 2026 15:25:17 GMT
>> ram@zedat.fu-berlin.de (Stefan Ram) gabbled:
>>> boltar@caprica.universe writes:   Eg, how about a switch() construct 
>>> that
>>>> operated on more than just POD types?
>>>
>>>   Expected in C++29:
>>>
>>> inspect (mystr) {
>>>     "hello" => { /* ... */ },
>>>     "world" => { /* ... */ },
>>>     _       => { /* default */ }
>>> };
>>
>> Wtf?? Why an entirely new construct, just overload switch! Also I can
>> guarantee than there's a ton of current code that will already be 
>> using the
>> word "inspect" in some way.
>>
> 
> "inspect" is /not/ expected in C++29 - Stefan is a bit out of date.  It 
> was one of several alternative proposals for a new pattern-matching 
> feature.  The current candidate is "match", with a syntax like :
> 
>      x match {
>          0 => std::printf("zero");
>          1 => std::printf("one");
>          _ => std::printf("something else");
>      }
> 
> This works like a normal "switch", but there is no fall-through (so no 
> "break" statements), and it is not weirdly unstructured.
> 
>      s match {
>          "zero" => std::printf("zero");
>          "one" => std::printf("one");
>          _ => std::printf("something else");
>      }
> 
> It will work with any literal types.  It can also be used to match 
> variant types, polymorphic types, etc.
> 
> And there are few situations where an existing identifier "match" could 
> be in conflict with the new keyword.  (You could cause trouble with a 
> macro called "match", but that seems unlikely in real code.)

This is more akin to the original -- I believe -- the ML of Edinburgh.
Which is also what people have come to expect from Rust.  Though full
disclosure, I haven't reached the pattern matching in my studies of Rust
yet, and my ML is rusty.

So I think this is going in the right direction, by giving people what
they expect from other programming languages.  The keyword conflict is
unfortunate, though.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

[toc] | [prev] | [next] | [standalone]

#124841 — Why no string switch? (was: Resources to learn common lisp?)

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>inspect (mystr) {
>    "hello" => { /* ... */ },

  Why there is no string "switch" statement in C++

  C++ is a systems programming language with zero-cost abstraction.

  The core language consists of predictable, low-level primitives
  (like "if", "while", "switch", or "+") that map to basic machine
  instructions and require minimal runtime overhead.
 
  If a native C++ inspect statement allowed matching a string variable
  against string cases, a single "primitive-looking" statement would 
  actually execute an O(N) string-comparison loop at runtime. Depending
  on how the compiler tries to optimize it, it might generate a sequen-
  tial chain of string comparisons, a trie structure, or a hashing rou-
  tine.

  Introducing a feature into the core language grammar that can intro-
  spect, match, and switch on complex string types blurs the historical
  boundary between lightweight primitive instructions in the core lan-
  guage and complex library types, making it more difficult for program-
  mers to "see" the run-time costs of core language features.

Newsgroups: comp.lang.misc,comp.lang.c++
Followup-To: comp.lang.c++

[toc] | [prev] | [next] | [standalone]

#124842 — Re: Why no string switch? (was: Resources to learn common lisp?)

On 19 Sep 2026 12:46:17 GMT
ram@zedat.fu-berlin.de (Stefan Ram) gabbled:
>ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>>inspect (mystr) {
>>    "hello" => { /* ... */ },
>
>  Why there is no string "switch" statement in C++
>
>  C++ is a systems programming language with zero-cost abstraction.
>
>  The core language consists of predictable, low-level primitives
>  (like "if", "while", "switch", or "+") that map to basic machine
>  instructions and require minimal runtime overhead.
> 
>  If a native C++ inspect statement allowed matching a string variable
>  against string cases, a single "primitive-looking" statement would 
>  actually execute an O(N) string-comparison loop at runtime. Depending
>  on how the compiler tries to optimize it, it might generate a sequen-
>  tial chain of string comparisons, a trie structure, or a hashing rou-
>  tine.

And? for() used to just be a simple comparison check loop then ranged for
loops were introduced. Functions had to be defined inline then lambdas were
introduced. Whats your point? There's no reason switch() can't be internally 
overloaded so a POD switch continues to be compiled down to a simple jump table 
whilst more complicated comparisons generate an if-else tree.

>  Introducing a feature into the core language grammar that can intro-
>  spect, match, and switch on complex string types blurs the historical
>  boundary between lightweight primitive instructions in the core lan-
>  guage and complex library types, making it more difficult for program-
>  mers to "see" the run-time costs of core language features.

That might be the case if the last 15 years of C++ development didn't prove
otherwise.

[toc] | [prev] | [next] | [standalone]

#124844 — Re: Why no string switch?

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>>inspect (mystr) {
>>    "hello" => { /* ... */ },
>
> Why there is no string "switch" statement in C++
>
> C++ is a systems programming language with zero-cost abstraction.
>
> The core language consists of predictable, low-level primitives
> (like "if", "while", "switch", or "+") that map to basic machine
> instructions and require minimal runtime overhead.
>
> If a native C++ inspect statement allowed matching a string variable
> against string cases, a single "primitive-looking" statement would 
> actually execute an O(N) string-comparison loop at runtime. Depending
> on how the compiler tries to optimize it, it might generate a sequen-
> tial chain of string comparisons, a trie structure, or a hashing rou-
> tine.
>
> Introducing a feature into the core language grammar that can intro-
> spect, match, and switch on complex string types blurs the historical
> boundary between lightweight primitive instructions in the core lan-
> guage and complex library types, making it more difficult for program-
> mers to "see" the run-time costs of core language features.

    std::cout << x << '\n';

This looks like it's just using core language features, but it can
result in arbitrarily complex actions because operator<< is overloaded.
There are plenty of other examples.

The fact that C++ doesn't currently have switch on strings or equivalent
doesn't greatly bother me, but if such a feature were added it would be
consistent with a lot of other high-level C++ features that look like
core language syntax.  (And presumably it would be designed to work
on arbitrary types, not just strings.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web