Groups > comp.lang.c > #382985 > unrolled thread

Implicit String-Literal Concatenation

Started by	Lawrence D'Oliveiro <ldo@nz.invalid>
First post	2024-02-24 23:05 +0000
Last post	2024-02-29 19:08 +0100
Articles	20 on this page of 111 — 15 participants

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

  Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-24 23:05 +0000
    Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-25 17:38 +0100
      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-25 20:43 +0000
        Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-25 21:20 +0000
    Re: Implicit String-Literal Concatenation Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-02-25 16:45 +0000
    Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-25 20:25 +0000
    Re: Implicit String-Literal Concatenation Łukasz 'Maly' Ostrowski <l3vi4than@gmail.com> - 2024-02-26 21:12 +0100
      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-26 20:31 +0000
        Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-27 13:18 +0100
          Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-27 23:10 +0000
            Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-28 00:50 +0100
    Re: Implicit String-Literal Concatenation Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-26 20:42 +0000
    Re: Implicit String-Literal Concatenation porkchop@invalid.foo (Mike Sanders) - 2024-02-26 22:03 +0000
      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-26 23:17 +0000
        Re: Implicit String-Literal Concatenation porkchop@invalid.foo (Mike Sanders) - 2024-02-27 17:27 +0000
      Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-27 09:36 +0100
        Re: Implicit String-Literal Concatenation porkchop@invalid.foo (Mike Sanders) - 2024-02-27 17:31 +0000
        Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-27 18:56 +0000
          Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-27 23:21 +0100
            Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-27 22:52 +0000
              Re: Implicit String-Literal Concatenation Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-28 01:09 +0000
                Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-28 12:50 +0100
                  Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-28 20:56 +0000
                    Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-28 21:34 +0000
                      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-28 23:52 +0000
                        Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-29 00:15 +0000
                          Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-29 02:53 +0000
                            Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-29 09:20 +0000
                          Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 15:48 +0000
                            Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-29 17:03 +0100
                              Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 16:17 +0000
                                Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-29 18:12 +0100
                                  Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 17:30 +0000
                                    Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 13:20 -0800
                                      Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-29 21:44 +0000
                                        Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 14:06 -0800
                                          Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-01 18:09 +0100
                                            Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-01 10:49 -0800
                                              Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-01 22:06 +0100
                                Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 09:20 -0800
                    Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 08:58 +0100
                      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-29 21:05 +0000
                        Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-03-01 09:16 +0100
                          Re: Implicit String-Literal Concatenation Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-01 16:55 +0000
                            Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-03-01 18:28 +0100
        Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-27 20:25 +0000
          Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-27 12:35 -0800
            Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-27 23:03 +0000
          Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-27 22:12 +0000
            Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-28 12:54 +0100
              Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-28 13:13 +0000
                Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-28 15:08 +0100
                Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-28 13:36 -0800
                  Re: Implicit String-Literal Concatenation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-29 11:56 +0000
                    Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 16:19 +0100
                      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-29 21:36 +0000
                        Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 13:53 -0800
                        Re: Implicit String-Literal Concatenation Richard Harnden <richard.nospam@gmail.invalid> - 2024-03-01 12:59 +0000
                          Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-01 20:59 +0000
                    Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 08:08 -0800
                  Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-29 14:31 +0000
                    Re: Implicit String-Literal Concatenation Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-29 15:22 +0000
                      Re: Implicit String-Literal Concatenation "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-29 13:10 -0800
                        Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 13:45 -0800
                          Re: Implicit String-Literal Concatenation "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-29 14:03 -0800
                            Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 14:14 -0800
                              Re: Implicit String-Literal Concatenation "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-02 13:48 -0800
                              Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-05 04:48 +0000
                                Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-04 20:55 -0800
                                  Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-07 21:08 +0000
                                    Re: Implicit String-Literal Concatenation Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-07 21:44 +0000
                                      Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-07 14:25 -0800
                                        Re: Implicit String-Literal Concatenation Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-07 23:00 +0000
                                          Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-07 15:46 -0800
                                        Re: Implicit String-Literal Concatenation "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-07 16:17 -0800
                                        Re: Implicit String-Literal Concatenation Richard Harnden <richard.nospam@gmail.invalid> - 2024-03-08 00:26 +0000
                                    Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-07 14:16 -0800
                    Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 16:30 +0100
                      Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 08:25 -0800
                    Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 08:18 -0800
                      Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-29 18:17 +0100
                        Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 09:22 -0800
                          Re: Implicit String-Literal Concatenation Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-29 19:26 +0000
                            Re: Implicit String-Literal Concatenation James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-29 14:45 -0500
                Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-28 13:41 -0800
              Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-28 13:57 -0800
                Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-28 23:01 +0000
                  Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-28 15:31 -0800
                    Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-29 00:47 +0000
                      Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-28 17:12 -0800
                      Re: Implicit String-Literal Concatenation tTh <tth@none.invalid> - 2024-02-29 16:29 +0100
                        Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 16:15 +0000
                      Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 15:53 +0000
                        Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 09:06 -0800
                          Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 17:28 +0000
                            Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 18:58 +0100
                              Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 18:05 +0000
                                Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 18:09 +0000
                                  Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-29 21:27 +0000
                                    Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-03-01 11:52 +0000
                                      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-05 04:47 +0000
                                        Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-03-05 15:09 +0000
                                          Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-06 01:49 +0000
                                Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 20:51 +0100
                Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 10:10 +0100
                  Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-29 10:18 +0000
                    Re: Implicit String-Literal Concatenation tTh <tth@none.invalid> - 2024-02-29 16:34 +0100
                      Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-03-01 11:58 +0000
                        Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-03-01 13:17 +0100
                  Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 09:03 -0800
                    Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 19:08 +0100

Page 1 of 6 [1] 2 3 4 5 6 Next page →

#382985 — Implicit String-Literal Concatenation

From	Lawrence D'Oliveiro <ldo@nz.invalid>
Date	2024-02-24 23:05 +0000
Subject	Implicit String-Literal Concatenation
Message-ID	<urdsob$1e8e4$7@dont-email.me>

I like using this for long strings:

    fputs
      (
        "When an uncleft or a bulkbit wins one or more bernstonebits above\n"
        "its own, it takes on a backward lading. When it loses one or\n"
        "more, it takes on a forward lading. Such a mote is called a\n"
        "*farer*, for that the drag between unlike ladings flits it. When\n"
        "bernstonebits flit by themselves, it may be as a bolt of\n"
        "lightning, a spark off some faststanding chunk, or the everyday\n"
        "flow of bernstoneness through wires.\n",
        stdout
      );

Of languages that derive ideas from C, only C++ and Python seem to have
kept this. Java, JavaScript and PHP have not, for some reason.

[toc] | [next] | [standalone]

#383007

From	Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Date	2024-02-25 17:38 +0100
Message-ID	<urfqef$1us0r$1@dont-email.me>
In reply to	#382985

On 25.02.2024 00:05, Lawrence D'Oliveiro wrote:
> I like using this for long strings:
> 
>     fputs
>       (
>         "When an uncleft or a bulkbit wins one or more bernstonebits above\n"
>         "its own, it takes on a backward lading. When it loses one or\n"
>         "more, it takes on a forward lading. Such a mote is called a\n"
>         "*farer*, for that the drag between unlike ladings flits it. When\n"
>         "bernstonebits flit by themselves, it may be as a bolt of\n"
>         "lightning, a spark off some faststanding chunk, or the everyday\n"
>         "flow of bernstoneness through wires.\n",
>         stdout
>       );

I also liked to be able to use this feature _in some cases_ in C++.

Not in the given case, though, where I like to more clearly see the
newlines, so I'd prefer  cout << "..." << endl

> 
> Of languages that derive ideas from C, only C++ and Python seem to have
> kept this. Java, JavaScript and PHP have not, for some reason.

In Java you have at least the string concatenation operator + which
is, IMO, pretty good for that line structuring across source lines.

In Awk (another "C like"), string concatenations have no visible
operators so we can for example write   print "Hell" "o " "world"
But since lines have a much more restricted definition you cannot
without line continuation escape spread these strings across many
lines. (It's not too bad to add a terminating '\' where desired.)

As far as you're asking "for some reason", I could just speculate
(and abstain).

Janis

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

#383015

From	Lawrence D'Oliveiro <ldo@nz.invalid>
Date	2024-02-25 20:43 +0000
Message-ID	<urg8pj$21p1q$5@dont-email.me>
In reply to	#383007

On Sun, 25 Feb 2024 17:38:38 +0100, Janis Papanagnou wrote:

> In Java you have at least the string concatenation operator + which is,
> IMO, pretty good for that line structuring across source lines.

Implicit concatenation works well in Python because you also have the
“%” operator overloaded to perform printf-style formatting with a
string. If you had to use “+” then, because that binds less tightly
than “%”, you would have to have parentheses as well, which are
unnecessary with implicit concatenation. E.g.

    # depreciation entries
    sql.cursor.execute \
      (
            "insert into payments set when_made = %(when_made)s,"
            " description = %(description)s, other_party_name = \"\","
            " amount = %(amount)d, kind = \"D\", tax_year = %(tax_year)d"
        %
            {
                "when_made" : end_for_tax_year(tax_year) - 1,
                "description" :
                    sql_string
                      (
                            "%s: %s $%s at %d%% from %s"
                        %
                            (
                                entry["description"],
                                entry["method"],
                                format_amount(entry["initial_value"]),
                                entry["rate"],
                                format_date(entry["when_purchased"]),
                            )
                      ),
                "amount" : - entry["amount"],
                "tax_year" : tax_year,
            }
      )

Or, for added fun, how about parameterizing a format:

    num_format = "%%.%dg" % nr_digits
    ...
    for axis in range(3) :
        out.write \
          (
                "        (%s, %s),\n"
            %
                (num_format, num_format)
            %
                (
                    min(v.co[axis] for v in the_mesh.vertices),
                    max(v.co[axis] for v in the_mesh.vertices)
                )
          )
    #end for

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

#383016

From	bart <bc@freeuk.com>
Date	2024-02-25 21:20 +0000
Message-ID	<urgaud$22qdb$1@dont-email.me>
In reply to	#383015

On 25/02/2024 20:43, Lawrence D'Oliveiro wrote:
> On Sun, 25 Feb 2024 17:38:38 +0100, Janis Papanagnou wrote:
> 
>> In Java you have at least the string concatenation operator + which is,
>> IMO, pretty good for that line structuring across source lines.
> 
> Implicit concatenation works well in Python because you also have the
> “%” operator overloaded to perform printf-style formatting with a
> string. If you had to use “+” then, because that binds less tightly
> than “%”,

You mean it binds less tightly than implicit concatenation? So that:

    "abc" % "def" "ghi"       means  "abc" % ("def" "ghi")
    "abc" % "def" + "ghi"     means  ("abc" % "def") "ghi"


> you would have to have parentheses as well, which are
> unnecessary with implicit concatenation. E.g.
> 
>      # depreciation entries
>      sql.cursor.execute \
>        (
>              "insert into payments set when_made = %(when_made)s,"
>              " description = %(description)s, other_party_name = \"\","
>              " amount = %(amount)d, kind = \"D\", tax_year = %(tax_year)d"
>          %
>              {
>                  "when_made" : end_for_tax_year(tax_year) - 1,
>                  "description" :
>                      sql_string
>                        (
>                              "%s: %s $%s at %d%% from %s"
>                          %
>                              (
>                                  entry["description"],
>                                  entry["method"],
>                                  format_amount(entry["initial_value"]),
>                                  entry["rate"],
>                                  format_date(entry["when_purchased"]),
>                              )
>                        ),
>                  "amount" : - entry["amount"],
>                  "tax_year" : tax_year,
>              }
>        )
> 
> Or, for added fun, how about parameterizing a format:
> 
>      num_format = "%%.%dg" % nr_digits
>      ...
>      for axis in range(3) :
>          out.write \
>            (
>                  "        (%s, %s),\n"
>              %
>                  (num_format, num_format)
>              %
>                  (
>                      min(v.co[axis] for v in the_mesh.vertices),
>                      max(v.co[axis] for v in the_mesh.vertices)
>                  )
>            )
>      #end for

Although I can't see it made much difference here. Is this an example of 
how bad it can be without implicit concatenation, or is it this 
complicated despite that?

Since I can't see any "+" operators between strings, yet what follows 
"%" is usually something starting with "(" or "{", not a string constant.

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

#383008

From	Blue-Maned_Hawk <bluemanedhawk@invalid.invalid>
Date	2024-02-25 16:45 +0000
Message-ID	<pan$e03fe$425473e6$292cfbdb$faf6f045@invalid.invalid>
In reply to	#382985

I've used this to make strings with embedded newlines look in the source 
file closer to how they'd look on output.


-- 
Blue-Maned_HawkÃÃÃÃÂ¢shortens to 
HawkÃÃÃÃÂ¢/
blu.mÃin.dÃÃÃÃÃÂ°ak/
ÃÃÃÃÂ¢he/him/his/himself/Mr.
blue-maned_hawk.srht.site
2017 called, but i couldn't understand what they were saying over all the 
screams.

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

#383014

From	Lawrence D'Oliveiro <ldo@nz.invalid>
Date	2024-02-25 20:25 +0000
Message-ID	<urg7n4$21p1q$4@dont-email.me>
In reply to	#382985

On Sat, 24 Feb 2024 23:05:47 -0000 (UTC), Lawrence D'Oliveiro wrote:

> Of languages that derive ideas from C, only C++ and Python seem to have
> kept this. Java, JavaScript and PHP have not, for some reason.

I’d forgotten to check Perl; it doesn’t have implicit concatenation 
either.

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

#383059

From	Łukasz 'Maly' Ostrowski <l3vi4than@gmail.com>
Date	2024-02-26 21:12 +0100
Message-ID	<1qf797ippluag.1p27j2yyk4ydt.dlg@40tude.net>
In reply to	#382985

On Sat, 24 Feb 2024 23:05:47 -0000 (UTC), Lawrence D'Oliveiro wrote:
> Of languages that derive ideas from C, only C++ and Python seem to have
> kept this. Java, JavaScript and PHP have not, for some reason.
Java (Text Blocks):
String s = """
multi
line
string""";

JavaScript (Template Literal):
let s = `multi
line
string`;

Still more convenient than C.

PHP? Don't care about PHP, it's shit, not even checking, most likely
some kind of a Perl-ish <<<EOF expression.

-- 
Kindest regards,
Łukasz 'Mały' Ostrowski.

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

#383060

From	Lawrence D'Oliveiro <ldo@nz.invalid>
Date	2024-02-26 20:31 +0000
Message-ID	<urisel$2nq9h$2@dont-email.me>
In reply to	#383059

On Mon, 26 Feb 2024 21:12:39 +0100, Łukasz 'Maly' Ostrowski wrote:

> Java (Text Blocks):
> String s = """
> multi line string""";

Python has those, too. I use them sometimes. Generally I’m not fond of 
them, because I think they’re wrongly defined.

> JavaScript (Template Literal):
> let s = `multi line string`;

I think Python has something like that now, too. F-strings?

> Still more convenient than C.

I still like having the choice of implicit concatenation, because then I 
fully control what appears in the string.

Tip: I have Emacs macros defined to strip and add the quoting/escaping, 
because I find the strings are easier to edit without that.

> PHP? Don't care about PHP, it's shit, not even checking, most likely
> some kind of a Perl-ish <<<EOF expression.

PHP is shit, not because of what it copied from Perl, but from what it 
didn’t copy. Nowadays it is trying to copy from Python, and it is making 
the same mistake.

The <<EOD construct that Perl has comes from POSIX shells, and it is very 
useful in both places. Bash also adds a <<<-construct.

Question: How would you do two separate <<-strings in the same shell 
command?

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

#383100

From	Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Date	2024-02-27 13:18 +0100
Message-ID	<urkjue$36npm$1@dont-email.me>
In reply to	#383060

On 26.02.2024 21:31, Lawrence D'Oliveiro wrote:
> 
> The <<EOD construct that Perl has comes from POSIX shells, and it is very 
> useful in both places. Bash also adds a <<<-construct.

Yes, bash adopted the '<<<' "here-strings".

> Question: How would you do two separate <<-strings in the same shell 
> command?

Can you give an example what you intend here? (With what semantics?)

Since '<<' is redirecting the here-document text to stdin of the
command you can have only one channel.

Janis

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

#383123

From	Lawrence D'Oliveiro <ldo@nz.invalid>
Date	2024-02-27 23:10 +0000
Message-ID	<urlq4p$3ep9p$7@dont-email.me>
In reply to	#383100

On Tue, 27 Feb 2024 13:18:20 +0100, Janis Papanagnou wrote:

> On 26.02.2024 21:31, Lawrence D'Oliveiro wrote:
>> 
>> Question: How would you do two separate <<-strings in the same shell
>> command?
> 
> Can you give an example what you intend here? (With what semantics?)
> 
> Since '<<' is redirecting the here-document text to stdin of the command
> you can have only one channel.

Perl lets you do something like

    func(<<EOD1, <<EOD2);
    ... contents of first string ...
    EOD1
    ... contents of second string ...
    EOD2

But this doesn’t work in Bash. However, in a Posix shell, remember you can 
specify the number of the file descriptor you want to redirect, e.g.

    diff -u /dev/fd/8 /dev/fd/9 8<<'EOD1' 9<<'EOD2'
    ... contents of first string ...
    EOD1
    ... contents of second string ...
    EOD2

Note I add the single quotes to prevent expansion of “$”-sequences within 
the strings. (I think this might be needed in Perl, too.)

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

#383124

From	Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Date	2024-02-28 00:50 +0100
Message-ID	<urlsgn$3fkrn$1@dont-email.me>
In reply to	#383123

On 28.02.2024 00:10, Lawrence D'Oliveiro wrote:
> On Tue, 27 Feb 2024 13:18:20 +0100, Janis Papanagnou wrote:
> 
>> On 26.02.2024 21:31, Lawrence D'Oliveiro wrote:
>>>
>>> Question: How would you do two separate <<-strings in the same shell
>>> command?
>>
>> Can you give an example what you intend here? (With what semantics?)
>>
>> Since '<<' is redirecting the here-document text to stdin of the command
>> you can have only one channel.
> 
> Perl lets you do something like
> 
>     func(<<EOD1, <<EOD2);
>     ... contents of first string ...
>     EOD1
>     ... contents of second string ...
>     EOD2
> 
> But this doesn’t work in Bash. However, in a Posix shell, remember you can 
> specify the number of the file descriptor you want to redirect, e.g.
> 
>     diff -u /dev/fd/8 /dev/fd/9 8<<'EOD1' 9<<'EOD2'
>     ... contents of first string ...
>     EOD1
>     ... contents of second string ...
>     EOD2
> 
> Note I add the single quotes to prevent expansion of “$”-sequences within 
> the strings. (I think this might be needed in Perl, too.)

I see. - Yes, you can do that in POSIX shells as well. - Note that I set
F'up-to CUS. And post the response there as a f'up to this post.

Janis

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

#383061

From	Kaz Kylheku <433-929-6894@kylheku.com>
Date	2024-02-26 20:42 +0000
Message-ID	<20240226123520.857@kylheku.com>
In reply to	#382985

On 2024-02-24, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> I like using this for long strings:
>
>     fputs
>       (
>         "When an uncleft or a bulkbit wins one or more bernstonebits above\n"
>         "its own, it takes on a backward lading. When it loses one or\n"
>         "more, it takes on a forward lading. Such a mote is called a\n"
>         "*farer*, for that the drag between unlike ladings flits it. When\n"
>         "bernstonebits flit by themselves, it may be as a bolt of\n"
>         "lightning, a spark off some faststanding chunk, or the everyday\n"
>         "flow of bernstoneness through wires.\n",
>         stdout
>       );
>
> Of languages that derive ideas from C, only C++ and Python seem to have
> kept this. Java, JavaScript and PHP have not, for some reason.

Implicit string catenation means you need punctuation to separate
elements that are not catenated.

It's a nonstarter in Lisp where you want

 ("ab" "cd" "ef")

to have three elements, not one. So if it worked that way, we would
need

 ("ab", "cd", "ef")

which is too horrible a price to pay for string literal catenation.

ANSI Lisp just allows line breaks in strings. However, all the white
space is combined into it.

Allow line breaks in string literals means that if you forget to
close a quote, it might not be diagnosed until the end of file!
The strictness of having to close a string in the same line is
worthwhile for diagnosis.

In TXR Lisp, I solved multiple problems with a backslash continuation.

  "abc    \
  def"

encodes the string "abcdef". All unescaped whitespace around the
backslash is deleted. If you want "abc def", you can plant an escaped
space in there:

  "abc \    \
  def"

or

  "abc    \
  \ def"

Unfortunately, it does mean we have the run of backslashes down the
right side:

  "abc \
   def \
   ghi \
   ... "

I can live with that.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#383071

From	porkchop@invalid.foo (Mike Sanders)
Date	2024-02-26 22:03 +0000
Message-ID	<urj1qv$2p32o$1@dont-email.me>
In reply to	#382985

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> I like using this for long strings:
> 
>     fputs
>       (
>         "When an uncleft or a bulkbit wins one or more bernstonebits above\n"
>         "its own, it takes on a backward lading. When it loses one or\n"
>         "more, it takes on a forward lading. Such a mote is called a\n"
>         "*farer*, for that the drag between unlike ladings flits it. When\n"
>         "bernstonebits flit by themselves, it may be as a bolt of\n"
>         "lightning, a spark off some faststanding chunk, or the everyday\n"
>         "flow of bernstoneness through wires.\n",
>         stdout
>       );
> 
> Of languages that derive ideas from C, only C++ and Python seem to have
> kept this. Java, JavaScript and PHP have not, for some reason.

Easy solution Lawrence. Why not use something like bin2c:

<https://www.segger.com/free-utilities/bin2c/>

void Usage() {

    #include "my_text"

    printf("%s\n", my_var);

}


-- 
:wq
Mike Sanders

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

#383075

From	Lawrence D'Oliveiro <ldo@nz.invalid>
Date	2024-02-26 23:17 +0000
Message-ID	<urj66g$2puef$4@dont-email.me>
In reply to	#383071

On Mon, 26 Feb 2024 22:03:11 -0000 (UTC), Mike Sanders wrote:

> Easy solution Lawrence. Why not use something like bin2c:

My tool for easy editing of such embedded text is the Emacs macros in 
multiquote.el, here <https://gitlab.com/ldo/emacs-prefs>.

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

#383110

From	porkchop@invalid.foo (Mike Sanders)
Date	2024-02-27 17:27 +0000
Message-ID	<url62n$3amuj$1@dont-email.me>
In reply to	#383075

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> My tool for easy editing of such embedded text is the Emacs macros in 
> multiquote.el, here <https://gitlab.com/ldo/emacs-prefs>.

Neato-burritto, built his own tool chain, 'atta-boy. Interesting page.

-- 
:wq
Mike Sanders

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

#383087

From	David Brown <david.brown@hesbynett.no>
Date	2024-02-27 09:36 +0100
Message-ID	<urk6um$33nqv$1@dont-email.me>
In reply to	#383071

On 26/02/2024 23:03, Mike Sanders wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> 
>> I like using this for long strings:
>>
>>      fputs
>>        (
>>          "When an uncleft or a bulkbit wins one or more bernstonebits above\n"
>>          "its own, it takes on a backward lading. When it loses one or\n"
>>          "more, it takes on a forward lading. Such a mote is called a\n"
>>          "*farer*, for that the drag between unlike ladings flits it. When\n"
>>          "bernstonebits flit by themselves, it may be as a bolt of\n"
>>          "lightning, a spark off some faststanding chunk, or the everyday\n"
>>          "flow of bernstoneness through wires.\n",
>>          stdout
>>        );
>>
>> Of languages that derive ideas from C, only C++ and Python seem to have
>> kept this. Java, JavaScript and PHP have not, for some reason.
> 
> Easy solution Lawrence. Why not use something like bin2c:
> 
> <https://www.segger.com/free-utilities/bin2c/>

Because it generates files that have Segger copyright notices stamped on 
them?  At least, that's how it appears from that web page.

There are lots of open source alternatives that do similar things, with 
different variations in the way they generate the output.  Or you can 
write your own in about 10 lines of Python, which of course makes it a 
lot easier to customise to fit your own styles and requirements.

And with C23, we will get #embed, though it is not yet supported by 
major tools.

<https://en.cppreference.com/w/c/preprocessor/embed>

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

#383111

From	porkchop@invalid.foo (Mike Sanders)
Date	2024-02-27 17:31 +0000
Message-ID	<url69o$3amuj$2@dont-email.me>
In reply to	#383087

David Brown <david.brown@hesbynett.no> wrote:

> Because it generates files that have Segger copyright notices stamped on 
> them?  At least, that's how it appears from that web page.

Then we build our own...
 
> There are lots of open source alternatives that do similar things, with 
> different variations in the way they generate the output.  Or you can 
> write your own in about 10 lines of Python, which of course makes it a 
> lot easier to customise to fit your own styles and requirements.

Yeah even simpler ways too, sed/awk/etc

> And with C23, we will get #embed, though it is not yet supported by 
> major tools.
> 
> <https://en.cppreference.com/w/c/preprocessor/embed>

Did not know that was coming down the pike, thanks for sharing the info
David.

-- 
:wq
Mike Sanders

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

#383113

From	bart <bc@freeuk.com>
Date	2024-02-27 18:56 +0000
Message-ID	<urlb8p$3bvbc$1@dont-email.me>
In reply to	#383087

On 27/02/2024 08:36, David Brown wrote:
> On 26/02/2024 23:03, Mike Sanders wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> I like using this for long strings:
>>>
>>>      fputs
>>>        (
>>>          "When an uncleft or a bulkbit wins one or more bernstonebits 
>>> above\n"
>>>          "its own, it takes on a backward lading. When it loses one 
>>> or\n"
>>>          "more, it takes on a forward lading. Such a mote is called a\n"
>>>          "*farer*, for that the drag between unlike ladings flits it. 
>>> When\n"
>>>          "bernstonebits flit by themselves, it may be as a bolt of\n"
>>>          "lightning, a spark off some faststanding chunk, or the 
>>> everyday\n"
>>>          "flow of bernstoneness through wires.\n",
>>>          stdout
>>>        );
>>>
>>> Of languages that derive ideas from C, only C++ and Python seem to have
>>> kept this. Java, JavaScript and PHP have not, for some reason.
>>
>> Easy solution Lawrence. Why not use something like bin2c:
>>
>> <https://www.segger.com/free-utilities/bin2c/>
> 
> Because it generates files that have Segger copyright notices stamped on 
> them?  At least, that's how it appears from that web page.
> 
> There are lots of open source alternatives that do similar things, with 
> different variations in the way they generate the output.  Or you can 
> write your own in about 10 lines of Python, which of course makes it a 
> lot easier to customise to fit your own styles and requirements.
> 
> And with C23, we will get #embed, though it is not yet supported by 
> major tools.
> 
> <https://en.cppreference.com/w/c/preprocessor/embed>

Actually I've had such feature, for text files, for some years in my 
older compiler:

     #include <stdio.h>

     int main(void) {
         puts(strinclude(__FILE__));
     }

This prints out the contents of this sourcefile. Binary files don't work 
because of embedded zeros, but could have been made to.

Some stuff is just very easy to do; other stuff like designator chains 
less easy and also less useful.

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

#383118

From	David Brown <david.brown@hesbynett.no>
Date	2024-02-27 23:21 +0100
Message-ID	<urln99$3ejjt$1@dont-email.me>
In reply to	#383113

On 27/02/2024 19:56, bart wrote:
> On 27/02/2024 08:36, David Brown wrote:
>> On 26/02/2024 23:03, Mike Sanders wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>>> I like using this for long strings:
>>>>
>>>>      fputs
>>>>        (
>>>>          "When an uncleft or a bulkbit wins one or more 
>>>> bernstonebits above\n"
>>>>          "its own, it takes on a backward lading. When it loses one 
>>>> or\n"
>>>>          "more, it takes on a forward lading. Such a mote is called 
>>>> a\n"
>>>>          "*farer*, for that the drag between unlike ladings flits 
>>>> it. When\n"
>>>>          "bernstonebits flit by themselves, it may be as a bolt of\n"
>>>>          "lightning, a spark off some faststanding chunk, or the 
>>>> everyday\n"
>>>>          "flow of bernstoneness through wires.\n",
>>>>          stdout
>>>>        );
>>>>
>>>> Of languages that derive ideas from C, only C++ and Python seem to have
>>>> kept this. Java, JavaScript and PHP have not, for some reason.
>>>
>>> Easy solution Lawrence. Why not use something like bin2c:
>>>
>>> <https://www.segger.com/free-utilities/bin2c/>
>>
>> Because it generates files that have Segger copyright notices stamped 
>> on them?  At least, that's how it appears from that web page.
>>
>> There are lots of open source alternatives that do similar things, 
>> with different variations in the way they generate the output.  Or you 
>> can write your own in about 10 lines of Python, which of course makes 
>> it a lot easier to customise to fit your own styles and requirements.
>>
>> And with C23, we will get #embed, though it is not yet supported by 
>> major tools.
>>
>> <https://en.cppreference.com/w/c/preprocessor/embed>
> 
> Actually I've had such feature, for text files, for some years in my 
> older compiler:
> 
>      #include <stdio.h>
> 
>      int main(void) {
>          puts(strinclude(__FILE__));
>      }
> 
> This prints out the contents of this sourcefile. Binary files don't work 
> because of embedded zeros, but could have been made to.
> 
> Some stuff is just very easy to do; other stuff like designator chains 
> less easy and also less useful.

The #embed pre-processor directive turns the file into a list of integer 
constants, one per byte (unless an implementation offers other options). 
  That makes it a little less convenient for strings than your solution, 
but more convenient for data files.  There's no harm in supporting both!

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

#383121

From	Lawrence D'Oliveiro <ldo@nz.invalid>
Date	2024-02-27 22:52 +0000
Message-ID	<urlp3h$3ep9p$5@dont-email.me>
In reply to	#383118

On Tue, 27 Feb 2024 23:21:28 +0100, David Brown wrote:

> The #embed pre-processor directive turns the file into a list of integer
> constants, one per byte (unless an implementation offers other options).

What a waste of time.

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

Page 1 of 6 [1] 2 3 4 5 6 Next page →

csiph-web

Implicit String-Literal Concatenation

Contents

#382985 — Implicit String-Literal Concatenation

#383007

#383015

#383016

#383008

#383014

#383059

#383060

#383100

#383123

#383124

#383061

#383071

#383075

#383110

#383087

#383111

#383113

#383118

#383121