Groups > ger.ct > #616895 > unrolled thread

Weißes Haus warnt vor C++

Started by	"F. W." <me@home.invalid>
First post	2024-03-01 08:14 +0100
Last post	2024-03-04 18:34 +0100
Articles	20 on this page of 120 — 14 participants

Back to article view | Back to ger.ct

  Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-01 08:14 +0100
    Re: Weißes Haus warnt vor C++ Goetz Schultz <ng.expire1225@goetz.co.uk> - 2024-03-01 14:13 +0000
      Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-01 15:53 +0100
    Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-01 15:54 +0100
      Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-04 08:07 +0100
        Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-04 17:55 +0100
          Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-05 10:09 +0100
            Re: Weißes Haus warnt vor C++ Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-05 10:30 +0100
              Re: Weißes Haus warnt vor C++ Thomas Klix <wotokl@web.de> - 2024-03-05 14:26 +0100
              Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-06 06:57 +0100
                Re: Weißes Haus warnt vor C++ Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-06 10:22 +0100
                  Re: Weißes Haus warnt vor C++ "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2024-03-06 09:30 +0000
                    Re: Tabellenformate Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-06 10:58 +0100
                  Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-06 10:35 +0100
                    Re: Weißes Haus warnt vor C++ Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-06 12:10 +0100
                      Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-06 15:28 +0100
                      Re: Metaprogrammierung Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-07 13:12 +0100
                        Re: Metaprogrammierung Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-07 13:45 +0100
                        Re: Metaprogrammierung Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-07 15:37 +0100
                      Re: Metaprogrammierung Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-07 13:41 +0100
                        Re: Metaprogrammierung Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-07 15:22 +0100
                          Re: Metaprogrammierung Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-07 16:15 +0100
                            Re: Metaprogrammierung Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-07 17:59 +0100
                              Re: Metaprogrammierung Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-07 18:59 +0100
                          Re: Metaprogrammierung Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-08 12:31 +0100
                            Re: Metaprogrammierung Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-08 13:02 +0100
                              Re: Metaprogrammierung Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-08 13:10 +0100
                              Re: Metaprogrammierung Andreas Fecht <forum@aftec.de> - 2024-03-08 15:12 +0100
                                Re: Metaprogrammierung Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-08 15:44 +0100
                  Re: Langsamkeit von Python Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-06 11:15 +0100
                    Re: Langsamkeit von Python Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-06 12:05 +0100
                  Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-06 11:34 +0100
                Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-06 11:33 +0100
                  Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-06 15:30 +0100
                    Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-06 16:18 +0100
                      Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-07 07:00 +0100
                        Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-07 13:39 +0100
                          Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-07 14:00 +0100
                            Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-07 14:19 +0100
                              Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-08 08:40 +0100
                                Re: Weißes Haus warnt vor C++ Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-08 12:37 +0100
                                  Re: Weißes Haus warnt vor C++ "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2024-03-08 12:57 +0000
                                    Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-08 15:22 +0100
                                    Re: Weißes Haus warnt vor C++ Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-08 16:20 +0100
                                      Re: Datenbanken Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-09 16:01 +0100
                                        Re: Datenbanken Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-09 19:28 +0100
                                    Re: Datenbanken "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2024-03-11 08:21 +0000
                                      Re: Datenbanken "F. W." <me@home.invalid> - 2024-03-11 09:27 +0100
                                      Re: Datenbanken Michael Bode <m.g.bode@web.de> - 2024-03-11 21:13 +0100
                                        Re: Datenbanken Heinz Brückner <Ha-He-Brueck@t-online.de> - 2024-03-12 13:21 +0100
                                          Re: Datenbanken "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2024-03-12 13:12 +0000
                                          Re: Datenbanken Michael Bode <m.g.bode@web.de> - 2024-03-12 19:17 +0100
                                  Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-11 09:24 +0100
                                    Re: Weißes Haus warnt vor C++ Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-03-11 10:39 +0000
                                      Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-12 06:46 +0100
                                        Re: Weißes Haus warnt vor C++ Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-03-12 14:23 +0000
                                          Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-14 07:57 +0100
                                            Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-14 10:15 +0100
                                            Re: Weißes Haus warnt vor C++ Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-03-14 10:03 +0000
                                              Re: Weißes Haus warnt vor C++ "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2024-03-14 11:21 +0000
                                                Re: SQL Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-03-14 19:21 +0000
                                                Re: SQL Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-14 20:29 +0100
                                              Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-14 13:21 +0100
                                                Re: Weißes Haus warnt vor C++ Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-03-14 12:32 +0000
                                                  Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-14 13:56 +0100
                                                    Re: Weißes Haus warnt vor C++ Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-14 14:24 +0100
                                                      Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-14 14:45 +0100
                                                  Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-14 15:27 +0100
                                                Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-14 13:52 +0100
                                                  Re: Weißes Haus warnt vor C++ "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2024-03-14 13:23 +0000
                                                    Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-14 14:46 +0100
                                                  Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-14 15:30 +0100
                                                    Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-14 17:31 +0100
                                            Re: Weißes Haus warnt vor C++ Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-14 13:54 +0100
                                              Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-14 15:32 +0100
                                                Re: Weißes Haus warnt vor C++ Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-14 16:39 +0100
                                Re: Weißes Haus warnt vor C++ Georg Gruber <g.gruber_hauwech@gmx.net> - 2024-03-08 13:25 +0100
                                Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-08 13:51 +0100
                                  Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-11 07:46 +0100
            Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-05 12:08 +0100
              Re: Weißes Haus warnt vor C++ Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-05 12:48 +0100
                Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-05 14:11 +0100
                  Re: Weißes Haus warnt vor C++ Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-05 14:43 +0100
                    Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-05 14:50 +0100
              Re: Weißes Haus warnt vor C++ Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-06 02:29 +0100
                Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-06 07:34 +0100
              Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-06 06:59 +0100
                Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-06 09:14 +0100
                  Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-06 10:37 +0100
                    Re: Weißes Haus warnt vor C++ Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-03-06 11:18 +0100
                      Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-06 11:56 +0100
                        Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-06 17:36 +0100
                          Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-07 07:02 +0100
                    Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-06 11:36 +0100
                      Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-06 11:57 +0100
                        Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-06 16:27 +0100
                          Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-07 07:03 +0100
                            Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-07 13:40 +0100
                              Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-07 14:01 +0100
                                Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-07 15:01 +0100
                                  Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-08 08:42 +0100
                                    Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-08 13:54 +0100
                                      Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-11 07:47 +0100
                                        Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-11 09:23 +0100
                                          Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-11 09:29 +0100
                                            Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-11 09:48 +0100
                                              Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-11 10:34 +0100
                                                Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-11 11:27 +0100
                                                  Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-12 06:47 +0100
                                                    Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-12 07:40 +0100
                                                      Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-14 15:35 +0100
                                                        Re: Weißes Haus warnt vor C++ Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-14 17:32 +0100
                                                Re: Weißes Haus warnt vor C++ Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-03-11 16:30 +0100
                                                  Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-12 06:48 +0100
                                                    Re: Weißes Haus warnt vor C++ Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-03-12 17:56 +0100
                                                      Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-14 15:36 +0100
                                                        Re: Weißes Haus warnt vor C++ Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2024-03-14 19:09 +0100
                                                Re: Weißes Haus warnt vor C++ Ulrich D i e z <ud.usenetcorrespondence@web.de> - 2024-03-12 11:16 +0100
                                                  Re: Weißes Haus warnt vor C++ "F. W." <me@home.invalid> - 2024-03-12 11:56 +0100
      Re: Weißes Haus warnt vor C++ "Wendelin Uez" <wuez@online.de> - 2024-03-04 18:34 +0100

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

#616895 — Weißes Haus warnt vor C++

From	"F. W." <me@home.invalid>
Date	2024-03-01 08:14 +0100
Subject	Weißes Haus warnt vor C++
Message-ID	<urrv87$ps5g$1@solani.org>

https://winfuture.de/news,141447.html

Es wird empfohlen, "speichersichere Sprachen" zu benutzen. Dazu gehören
alle modernen Programmiersprachen, aber auch ältere Semester wie Java
oder Javascript.

FW

[toc] | [next] | [standalone]

#616924

From	Goetz Schultz <ng.expire1225@goetz.co.uk>
Date	2024-03-01 14:13 +0000
Message-ID	<ursnpf$18l04$1@dont-email.me>
In reply to	#616895

On 01/03/2024 07:14, F. W. wrote:
> https://winfuture.de/news,141447.html
> 
> Es wird empfohlen, "speichersichere Sprachen" zu benutzen. Dazu gehören
> alle modernen Programmiersprachen, aber auch ältere Semester wie Java
> oder Javascript.
> 
> FW

Memory Leaks - Java

Soso. Ich habe das irgendwie anders erlebt. Da haben sich Java-Apps 
immer mehr Speicher gegönnt bis das System stand bzw. die App 
eingefroren ist. Danach konnte man immer "Out-of-memory" in den Logs finden.

-- 

Cheers,
    G.

Quis custodiet ipsos custodes?
---------------------------->8------------------------------
   /"\
   \ /  ASCII Ribbon Campaign
    X   against HTML e-mail
   / \
---------------------------->8------------------------------

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

#616931

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2024-03-01 15:53 +0100
Message-ID	<ursq47$19hqe$1@raubtier-asyl.eternal-september.org>
In reply to	#616924

Am 01.03.2024 um 15:13 schrieb Goetz Schultz:
> Soso. Ich habe das irgendwie anders erlebt. Da haben sich Java-Apps 
> immer mehr Speicher gegönnt bis das System stand bzw. die App 
> eingefroren ist. Danach konnte man immer "Out-of-memory" in den Logs 
> finden.

Memory-leaks können unter Java theoretisch passieren, sind aber unwahr-
scheinlich. Dass Java so viel RAM belegt liegt daran, dass der Memory
Allocator wirklich erst schnell wird wenn man dem ein Vielfaches des
wirklich benötigten Speichers braucht. Eine Garbage Collection kopiert
nämlich den leben Teil eines ganzen Heaps zu einem neuen Heap um, und
das ist realtiv teuer. Die Allokation zwischen den GC-Phasen kann aber
effizient sein, bzw. sogar effizienter als das in C oder C++ möglich
wäre, denn normalerweise werden neue Allokationen einfach nach dem
bump-the-pointer -Schema hinten an den Heap drangehangen. Blöcke die
nicht mehr benötigt werden werden so gar nicht freigegeben, sondern
werden mit den tatsächlich noch belegten Speicherblöcken beim GC frei,
bzw. der benutzte Teil wird wie gesagt in einen neuen Heap umkopiert.
Ein out of memory kann man in Java leicht produzieren indem man den
Heap per Kommandozeilen-Option klein genug hält. Ggf. gibt's dann auch
kein out of memory, aber eine sehr häufige GC und eine schlechte Per-
formance.

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

#616932

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2024-03-01 15:54 +0100
Message-ID	<ursq74$19hqe$2@raubtier-asyl.eternal-september.org>
In reply to	#616895

Am 01.03.2024 um 08:14 schrieb F. W.:

> https://winfuture.de/news,141447.html
> Es wird empfohlen, "speichersichere Sprachen" zu benutzen. Dazu gehören
> alle modernen Programmiersprachen, aber auch ältere Semester wie Java
> oder Javascript.

C++ ist für System-nahe und performante Software gedacht.
An der Stelle kommt man sicher nicht mit Java oder JavaScript.

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

#617000

From	"F. W." <me@home.invalid>
Date	2024-03-04 08:07 +0100
Message-ID	<us3rvr$tvf4$2@solani.org>
In reply to	#616932

Am 01.03.24 um 15:54 schrieb Bonita Montero:

> Am 01.03.2024 um 08:14 schrieb F. W.:

>> https://winfuture.de/news,141447.html Es wird empfohlen,
>> "speichersichere Sprachen" zu benutzen. Dazu gehören alle modernen
>> Programmiersprachen, aber auch ältere Semester wie Java oder
>> Javascript.

> C++ ist für System-nahe und performante Software gedacht. An der
> Stelle kommt man sicher nicht mit Java oder JavaScript.

Ich denke, man meinte auch den Einsatz von C++ im kommerziellen Bereich.

FW

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

#617010

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2024-03-04 17:55 +0100
Message-ID	<us4ue5$38edb$1@raubtier-asyl.eternal-september.org>
In reply to	#617000

Am 04.03.2024 um 08:07 schrieb F. W.:
> Am 01.03.24 um 15:54 schrieb Bonita Montero:
> 
>> Am 01.03.2024 um 08:14 schrieb F. W.:
> 
>>> https://winfuture.de/news,141447.html Es wird empfohlen,
>>> "speichersichere Sprachen" zu benutzen. Dazu gehören alle modernen
>>> Programmiersprachen, aber auch ältere Semester wie Java oder
>>> Javascript.
> 
>> C++ ist für System-nahe und performante Software gedacht. An der
>> Stelle kommt man sicher nicht mit Java oder JavaScript.
> 
> Ich denke, man meinte auch den Einsatz von C++ im kommerziellen Bereich.
> 
> FW

Macht ja für meine Aussage keinen Unterschied.

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

#617033

From	"F. W." <me@home.invalid>
Date	2024-03-05 10:09 +0100
Message-ID	<us6nh1$uuqq$5@solani.org>
In reply to	#617010

Am 04.03.24 um 17:55 schrieb Bonita Montero:

> Am 04.03.2024 um 08:07 schrieb F. W.:
>> Am 01.03.24 um 15:54 schrieb Bonita Montero:
>> 
>>> Am 01.03.2024 um 08:14 schrieb F. W.:
>> 
>>>> https://winfuture.de/news,141447.html Es wird empfohlen, 
>>>> "speichersichere Sprachen" zu benutzen. Dazu gehören alle 
>>>> modernen Programmiersprachen, aber auch ältere Semester wie 
>>>> Java oder Javascript.
>> 
>>> C++ ist für System-nahe und performante Software gedacht. An der 
>>> Stelle kommt man sicher nicht mit Java oder JavaScript.
>> 
>> Ich denke, man meinte auch den Einsatz von C++ im kommerziellen 
>> Bereich.
>> 
>> FW
> 
> Macht ja für meine Aussage keinen Unterschied.
> 

Konform: wäre ich Projektleiter für eine reine Anwendung (wie z. B. die
Campingplatz-Verwaltung, die ich mal verantwortet habe), dann würde ich
heute kein C/C++ mehr wählen.

Java wäre das Werkzeug meiner Wahl. Obwohl ich damit auch Kopfschmerzen
hätte (JVM). Aber die Zeiten von Pascal sind wohl vorbei. :-)

FW

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

#617036

From	Hermann Riemann <nospam.ng@hermann-riemann.de>
Date	2024-03-05 10:30 +0100
Message-ID	<l4o71fFbivgU1@mid.individual.net>
In reply to	#617033

Am 05.03.24 um 10:09 schrieb F. W.:
>>>> C++ ist für System-nahe und performante Software gedacht. An der 
>>>> Stelle kommt man sicher nicht mit Java oder JavaScript.
>>>
>>> Ich denke, man meinte auch den Einsatz von C++ im kommerziellen Bereich.
>>>
>>> FW
>>
>> Macht ja für meine Aussage keinen Unterschied.
>>
> 
> Konform: wäre ich Projektleiter für eine reine Anwendung (wie z. B. die
> Campingplatz-Verwaltung, die ich mal verantwortet habe), dann würde ich
> heute kein C/C++ mehr wählen.

Das hängt von er Größe des Campingplatzes ab.
Vermutlich würde Python + cgi reichen.
Um Abrechnungen einer Hausverwaltung nachzuvollziehen, hat es gereicht.
Sogar auf raspberry pi, der im Gegensatz zu meinen PCs problemlos
per Bahn transportiert werden konnte.

> Java wäre das Werkzeug meiner Wahl. Obwohl ich damit auch Kopfschmerzen
> hätte (JVM). Aber die Zeiten von Pascal sind wohl vorbei. :-)

Wenn es zeitkritisch wäre,
wäre vielleicht eine andere Sprache  ( Rust, R )? empfehlenswert.

Für ganz große Projekte würde ich mit Programm Generatoren
über lisp gehen

Hermann
    für dessen eigene Verwaltung Python reicht.

-- 
<http://www.hermann-riemann.de>

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

#617058

From	Thomas Klix <wotokl@web.de>
Date	2024-03-05 14:26 +0100
Message-ID	<us76hd$ner4$1@kx-sid.kx-net.de>
In reply to	#617036

Stefan Ram <ram@zedat.fu-berlin.de> at 5 Mar 2024 11:06:47 GMT:
> ram@zedat.fu-berlin.de (Stefan Ram) schrieb oder zitierte:
>>|Kampf zwischen prozeduraler und funktionaler Programmierung
>
>   Korrektur:
>
>   Hier hatte ich als Vorlage einen Text von mir genommen, bei dem
>   ich "objektorientierter" gegen "funktionaler" ausgetauscht hatte.

Warum tut man so etwas?

>   In Wirklichkeit behandelte Joel Spolsky aber den Vergleich zwischen
>   "prozeduraler" und /objektorientierte/ Programmierung! (Ansonsten
>   stimmt mein Zitat aus "How Microsoft Lost the API War" wohl.)

Wenn du es verfälschst, ist es kein Zitat mehr.

Thomas

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

#617091

From	"F. W." <me@home.invalid>
Date	2024-03-06 06:57 +0100
Message-ID	<us90kt$10jn4$2@solani.org>
In reply to	#617036

Am 05.03.24 um 10:30 schrieb Hermann Riemann:

>> Konform: wäre ich Projektleiter für eine reine Anwendung (wie z. B.
>> die Campingplatz-Verwaltung, die ich mal verantwortet habe), dann
>> würde ich heute kein C/C++ mehr wählen.

> Das hängt von er Größe des Campingplatzes ab.

Nein. Man kann damit 50 Parzellen verwalten und 50.000 Parzellen auch.
So müssen Anwendungen geplant sein.

> Vermutlich würde Python + cgi reichen.

Python kann man nicht kompilieren.

>> Java wäre das Werkzeug meiner Wahl. Obwohl ich damit auch 
>> Kopfschmerzen hätte (JVM). Aber die Zeiten von Pascal sind wohl 
>> vorbei. :-)

> Wenn es zeitkritisch wäre, wäre vielleicht eine andere Sprache  ( 
> Rust, R )? empfehlenswert.

Bei den damaligen, schnellen PC waren nicht mal Datenbanken notwendig.

> Für ganz große Projekte würde ich mit Programm Generatoren über lisp
>  gehen

LISP dürfte schon an neuen Anwendungsentwicklern scheitern.

FW

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

#617099

From	Hermann Riemann <nospam.ng@hermann-riemann.de>
Date	2024-03-06 10:22 +0100
Message-ID	<l4qqutFnrdkU1@mid.individual.net>
In reply to	#617091

Am 06.03.24 um 06:57 schrieb F. W.:
> Am 05.03.24 um 10:30 schrieb Hermann Riemann:
> 
>>> Konform: wäre ich Projektleiter für eine reine Anwendung (wie z. B.
>>> die Campingplatz-Verwaltung, die ich mal verantwortet habe), dann
>>> würde ich heute kein C/C++ mehr wählen.
> 
>> Das hängt von er Größe des Campingplatzes ab.
> 
> Nein. Man kann damit 50 Parzellen verwalten und 50.000 Parzellen auch.
> So müssen Anwendungen geplant sein.

Bei 50 Parzellen könnte Python reichen,
bei 50000 nicht. Python ist ca 30 mal langsamer als in
Maschinensprache übersetzte Programme.

>> Vermutlich würde Python + cgi reichen.

> Python kann man nicht kompilieren.

Nur teilweise in Pseudocode ( .pyc Dateien )

>>> Java wäre das Werkzeug meiner Wahl. Obwohl ich damit auch 
>>> Kopfschmerzen hätte (JVM). Aber die Zeiten von Pascal sind wohl 
>>> vorbei. :-)
> 
>> Wenn es zeitkritisch wäre, wäre vielleicht eine andere Sprache  ( 
>> Rust, R )? empfehlenswert.

> Bei den damaligen, schnellen PC waren nicht mal Datenbanken notwendig.

Waren es da nur 50 Parzellen?

Bisher habe ich keine Datenbanken verwendet.
Meine Daten hinterlege ich csv ähnlichen (oder html) Dateien.  hinterlegt.
Leerzeichen als Trenner wie /etc/hosts sind ein Spezialfall von csv

>> Für ganz große Projekte würde ich mit Programm Generatoren über lisp
>>  gehen

> LISP dürfte schon an neuen Anwendungsentwicklern scheitern.

Ich habe damals Lisp (1.5) ohne menschliche Hilfe ( und ohne Kurs )
anhand eines Manuals und eigene Testprogramme gelernt.
Und das noch mit Lochkarten, Papier Listen und
und als Standard Fehlermeldung: "Schlechte Klammerzählung".
"bad bracket count"
Wenn jemand nicht an einer Programmierspache klemmt,
so sind ungewöhnliche Sprachen wie Forth oder APL
  kein ernsthaftes Problem.

-- 
<http://www.hermann-riemann.de>

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

#617100

From	"Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de>
Date	2024-03-06 09:30 +0000
Message-ID	<l4qrdbFnr4sU1@mid.individual.net>
In reply to	#617099

Hermann Riemann <nospam.ng@hermann-riemann.de> wrote:
>Am 06.03.24 um 06:57 schrieb F. W.:
>> Am 05.03.24 um 10:30 schrieb Hermann Riemann:
>> 
>>>> Konform: wäre ich Projektleiter für eine reine Anwendung (wie z. B.
>>>> die Campingplatz-Verwaltung, die ich mal verantwortet habe), dann
>>>> würde ich heute kein C/C++ mehr wählen.
>> 
>>> Das hängt von er Größe des Campingplatzes ab.
>> 
>> Nein. Man kann damit 50 Parzellen verwalten und 50.000 Parzellen auch.
>> So müssen Anwendungen geplant sein.

>Bei 50 Parzellen könnte Python reichen,
>bei 50000 nicht. Python ist ca 30 mal langsamer als in
>Maschinensprache übersetzte Programme.

>>> Vermutlich würde Python + cgi reichen.

>> Python kann man nicht kompilieren.

>Nur teilweise in Pseudocode ( .pyc Dateien )

>>>> Java wäre das Werkzeug meiner Wahl. Obwohl ich damit auch 
>>>> Kopfschmerzen hätte (JVM). Aber die Zeiten von Pascal sind wohl 
>>>> vorbei. :-)
>> 
>>> Wenn es zeitkritisch wäre, wäre vielleicht eine andere Sprache  ( 
>>> Rust, R )? empfehlenswert.

>> Bei den damaligen, schnellen PC waren nicht mal Datenbanken notwendig.

>Waren es da nur 50 Parzellen?

>Bisher habe ich keine Datenbanken verwendet.
>Meine Daten hinterlege ich csv ähnlichen (oder html) Dateien.  hinterlegt.
Das ist natürlich bei grösseren Datenmengen suboptimal.
Eine Sqlite-Datenbank wäre in vielen Fällen die bessere Lösung.
Die Einbindung in Python ist nahezu trivial.

-- 
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

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

#617107 — Re: Tabellenformate

From	Hermann Riemann <nospam.ng@hermann-riemann.de>
Date	2024-03-06 10:58 +0100
Subject	Re: Tabellenformate
Message-ID	<l4qt19Fo49oU1@mid.individual.net>
In reply to	#617100

Am 06.03.24 um 10:39 schrieb Stefan Ram:
> "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> schrieb oder zitierte:
>> Das ist natürlich bei grösseren Datenmengen suboptimal.
>> Eine Sqlite-Datenbank wäre in vielen Fällen die bessere Lösung.
>> Die Einbindung in Python ist nahezu trivial.
> 
>    Für maschinelle Prozesse kann eine SQL-Datenbank mit normalisierten
>    Tabellen hilfreich sein. Wenn Tabellen jedoch in der Regel
>    manuell bearbeitet werden sollen, kann es übersichtlicher sein,
>    wenn sie als Text- oder Tabellenkalkulationsdatei vorliegen.

Wenn Tabellen oder andere Daten bearbeitet werden,
müssen die im RAM vorliegen und nicht auf Datenträger.
Die Darstellung kann unterschiedlich sein ( array von Strukturen)

Ein Problem ist noch wenn z.B. mehrere Personen
gleichzeitig den gleichen Datensatz bearbeiten.
Der zuletzt tippt, gewinnt?
Wenn die sich dann nicht einige werden ..

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

#617102

From	"F. W." <me@home.invalid>
Date	2024-03-06 10:35 +0100
Message-ID	<us9dd4$10eo0$1@solani.org>
In reply to	#617099

Am 06.03.24 um 10:22 schrieb Hermann Riemann:

>> Nein. Man kann damit 50 Parzellen verwalten und 50.000 Parzellen 
>> auch. So müssen Anwendungen geplant sein.

> Bei 50 Parzellen könnte Python reichen, bei 50000 nicht. Python ist 
> ca 30 mal langsamer als in Maschinensprache übersetzte Programme.

Python schied aus - es lässt sich nicht kompilieren.

> 
>> Bei den damaligen, schnellen PC waren nicht mal Datenbanken 
>> notwendig.
> 
> Waren es da nur 50 Parzellen?
> 

Das weiß ich nicht mehr (war 2010).

> Bisher habe ich keine Datenbanken verwendet. Meine Daten hinterlege 
> ich csv ähnlichen (oder html) Dateien.  hinterlegt. Leerzeichen als 
> Trenner wie /etc/hosts sind ein Spezialfall von csv

Wir haben damals Textdateien verwendet, deren Inhalt verschlüsselt
wurde. Das ging schon recht flott.

Es wurde auch nicht dauernd auf den Dateien herum geharkt wie bei meiner
Pizza-Fakturierung. Campingplatz-Besitzer haben üblicherweise mehr Ruhe
bei der Erfassung.

> 
>> LISP dürfte schon an neuen Anwendungsentwicklern scheitern.
> 

> Ich habe damals Lisp (1.5) ohne menschliche Hilfe ( und ohne Kurs )

Ja, das ist schön. Bei der Anwendungsplanung musst Du aber
berücksichtigen, ob andere Entwickler das Projekt weiterführen können.
Sonst bist Du kein guter Projektleiter.

FW

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

#617120

From	Hermann Riemann <nospam.ng@hermann-riemann.de>
Date	2024-03-06 12:10 +0100
Message-ID	<l4r18kFooneU1@mid.individual.net>
In reply to	#617102

Am 06.03.24 um 10:35 schrieb F. W.:

>> Ich habe damals Lisp (1.5) ohne menschliche Hilfe ( und ohne Kurs )

> Ja, das ist schön. Bei der Anwendungsplanung musst Du aber
> berücksichtigen, ob andere Entwickler das Projekt weiterführen können.
> Sonst bist Du kein guter Projektleiter.

Ich habe damals Informatiker nach Programmiersprache in ihrer
Ausbildung gefragt. Es war Algol68. Lisp war bestenfalls bekannt.

Das man mit Lisp automatisch Programme erstellen könnte,
ging weit über ihr Denkvermögen hinaus.

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

#617127

From	"F. W." <me@home.invalid>
Date	2024-03-06 15:28 +0100
Message-ID	<us9uhr$10t3c$8@solani.org>
In reply to	#617120

Am 06.03.2024 um 12:10 schrieb Hermann Riemann:
> Am 06.03.24 um 10:35 schrieb F. W.:
> 
>>> Ich habe damals Lisp (1.5) ohne menschliche Hilfe ( und ohne Kurs )
> 
>> Ja, das ist schön. Bei der Anwendungsplanung musst Du aber
>> berücksichtigen, ob andere Entwickler das Projekt weiterführen können.
>> Sonst bist Du kein guter Projektleiter.
> 
> Ich habe damals Informatiker nach Programmiersprache in ihrer
> Ausbildung gefragt. Es war Algol68. Lisp war bestenfalls bekannt.
> 
> Das man mit Lisp automatisch Programme erstellen könnte,
> ging weit über ihr Denkvermögen hinaus.

Sehr schön. Aber wenn Du heute ein Projekt in LISP programmieren lässt, 
wirst Du wohl keine Fachkräfte dafür finden.

FW

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

#617167 — Re: Metaprogrammierung

From	Hermann Riemann <nospam.ng@hermann-riemann.de>
Date	2024-03-07 13:12 +0100
Subject	Re: Metaprogrammierung
Message-ID	<l4tpa0F73ehU1@mid.individual.net>
In reply to	#617120

Am 07.03.24 um 12:06 schrieb Stefan Ram:
> Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb oder zitierte:
>> Das man mit Lisp automatisch Programme erstellen könnte,
>> ging weit über ihr Denkvermögen hinaus.
> 
>    Man kann auch ein C-Programm schreiben,
>    das automatisch C-Programme erstellt:
> 
>    main.c
> 
> #include <stdio.h>
> #include <stdlib.h>
> int main( void )
> { puts( "#include <stdio.h>" );
>    puts( "" );
>    puts( "int main( void )" );
>    printf( "{ printf( %d ); }\n", rand() ); }
> 
>    transcript
> 
> #include <stdio.h>
> 
> int main( void )
> { printf( 41 ); 

Das Interessante an lisp finde ich,
dass das nicht mit Quelltext geschieht,
sondern auf einen Syntaxbaum.

etwa

( ( quote if ) ( <= a b ) expression )

den man anhand vom Möglichkeiten per Programm
editieren ( einsetzen, löschen ändern ) kann
und auch mit eval testet bzw simuliert.

Das erspart den Umweg über Quelltext

Etwa zum herausfinden von Fehler wie Reihenfolge

if a/b >0 and b!=0
statt
if b!=0 and a/b>0

Das const, weak bei pointer, was Programme schwerer lesbar macht
könnte auch über Anwendungsanlayse gesetzt werden.

>    In C++ kann ein Programm durch Schablonen ("templates") Programmteile

Also macros in Assembler oder #define in C

>    in etwas strukturierterer Weise generieren lassen. Dennoch ist die
>    schablonenbasierte Metaprogrammierung für viele Programmierer recht
>    unübersichtlich. Nun kann man heute in C++ viele solcher Anwendungen
>    vereinfachen, indem man verlangen kann, daß bestimmte Programmteile
>    bereits bei der Übersetzung ausgeführt werden, was auf recht über-
>    sichtliche Weise möglich ist.
> 
>    C++ versteht Uhrzeiten normalerweise nicht in der Schreibweise
>    "7_Std + 3_min".
Kann man umsetzen in  mit Einheiten Typen Std min sec m g ..
von etwa wie weit bin ich in 7 Stunden und 3 Minuten
bei 30 kmh ( eventuell undeutlich gesprochen )
nach
  ( * ( + 7.Std 3.min ) ( 30 km/Std) ) )

Beim lesen und schreiben von Formaten
kann man dann Benutzer orientiert vorgehen also
Ergebnis nicht als Gleitkomma mit Exponent als Nanometer vorzeigen

Beim Basteln, um Lösungswege zu finden und auszusuchen,
sind Quelltexte außer debug zu unhandlich.

-- 
<http://www.hermann-riemann.de>

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

#617172 — Re: Metaprogrammierung

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2024-03-07 13:45 +0100
Subject	Re: Metaprogrammierung
Message-ID	<usccsn$11vj4$4@raubtier-asyl.eternal-september.org>
In reply to	#617167

Am 07.03.2024 um 13:24 schrieb Stefan Ram:

>    Der Unterschied zu Makros ist, daß man in C++ für Programmteile,
>    die schon während der Übersetzung ausgeführt werden sollen,
>    dieselbe Syntax verwenden kann wie für normale Klassen und
>    Funktionen und diese Klassen und Funktionen auch alle möglichen
>    Programmkonstrukte wie Schleifen enthalten können und trotzdem
>    - falls irgend möglich - schon während der Übersetzung des
>    Programms abgearbeitet werden. Falls dies nicht möglich ist, kann
>    man diesselben Funktionen dann auch zur Laufzeit ausführen. Damit
>    sind sie in der Praxis lesbarer und leistungsfähiger als Makros.

Naja, die Möglichkeiten zur Compilezeit-Ausführung sind beschränkt,
daher gab es lange nicht das was mit C++20 mit consteval-Funktionen
gemacht wurde, sondern Funktionen konnten nur constexpr sein, was
dann nur so viel bedeutete wie, dass der Compiler versuchen soll,
das zur Compilezeit aufzulösen. Der Hintergedanke dazu ist, dass
Entwickler das dem Compiler nahelegt damit der Compiler nicht immer
versucht, eine Funktion zur Compilezeit aufzulösen, was wohl ggf.
zu lange dauern könnte.

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

#617179 — Re: Metaprogrammierung

From	Hermann Riemann <nospam.ng@hermann-riemann.de>
Date	2024-03-07 15:37 +0100
Subject	Re: Metaprogrammierung
Message-ID	<l4u1okF8cmiU1@mid.individual.net>
In reply to	#617167

Am 07.03.24 um 13:24 schrieb Stefan Ram:
> Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb oder zitierte:
>> Also macros in Assembler oder #define in C
> 
>    Der Unterschied zu Makros ist, daß man in C++ für Programmteile,
>    die schon während der Übersetzung ausgeführt werden sollen,
>    dieselbe Syntax verwenden kann wie für normale Klassen und
>    Funktionen und diese Klassen und Funktionen auch alle möglichen
>    Programmkonstrukte wie Schleifen enthalten können und trotzdem
>    - falls irgend möglich - schon während der Übersetzung des
>    Programms abgearbeitet werden. Falls dies nicht möglich ist, kann
>    man diesselben Funktionen dann auch zur Laufzeit ausführen. Damit
>    sind sie in der Praxis lesbarer und leistungsfähiger als Makros.

War da nicht mal was, wo C++ wegen templates Unterprogramme mit
  vielen Datentypen Varianten erzeugte,
was Übersetzungszeit und Programmgröße in ungewohnte Höhen treib?

Die Übersetzung Deines Programms liefert

cc main.cpp 

main.cpp:15:18: error: ‘time’ does not name a type
  constexpr inline time operator +( time result, time const & other )
                   ^~~~
main.cpp:19:28: error: ‘time’ is not a type
  ( ::std::ostream & stream, time const & object )
                             ^~~~
main.cpp: In function ‘std::ostream& operator<<(std::ostream&, const int&)’:
main.cpp:20:17: error: request for member ‘print’ in ‘object’, which is 
of non-class type ‘const int’
  { return object.print( stream ); }
                  ^~~~~
main.cpp: At global scope:
main.cpp:22:11: error: ‘time’ does not name a type
  constexpr time operator "" _Std( ::std::uint64_t const v )
            ^~~~
main.cpp:25:11: error: ‘time’ does not name a type
  constexpr time operator "" _min( ::std::uint64_t const v )
            ^~~~
main.cpp: In function ‘int main()’:
main.cpp:28:28: error: unable to find numeric literal operator 
‘operator""_Std’
  int main(){ ::std::cout << 7_Std + 3_min << '\n'; }
                             ^~~~~
main.cpp:28:36: error: unable to find numeric literal operator 
‘operator""_min’
  int main(){ ::std::cout << 7_Std + 3_min << '\n'; }


Damit könnte man einen Präprozessor bauen der aus 7_Std
std_class(7) bastelt.
Wenn allerdings statt 7 die Variable a steht..

Das hantieren mit dem Daten Typ physikalische Einheit
dürfte nicht so einfach sein.

Der erste Parameter ist ein numerischer wert (z.B. float Variable)
der zweite ein expression z.B. km/std oder m/sec
( Lichtjahr/picosec)

Wenn man kg zu Liter addiert, ist ki gefragt.

-- 
<http://www.hermann-riemann.de>

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

#617171 — Re: Metaprogrammierung

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2024-03-07 13:41 +0100
Subject	Re: Metaprogrammierung
Message-ID	<usccmc$11vj4$3@raubtier-asyl.eternal-september.org>
In reply to	#617120

Am 07.03.2024 um 12:06 schrieb Stefan Ram:
> Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb oder zitierte:
>> Das man mit Lisp automatisch Programme erstellen könnte,
>> ging weit über ihr Denkvermögen hinaus.
> 
>    Man kann auch ein C-Programm schreiben,
>    das automatisch C-Programme erstellt:
> 
>    main.c
> 
> #include <stdio.h>
> #include <stdlib.h>
> int main( void )
> { puts( "#include <stdio.h>" );
>    puts( "" );
>    puts( "int main( void )" );
>    printf( "{ printf( %d ); }\n", rand() ); }
> 
>    transcript
> 
> #include <stdio.h>
> 
> int main( void )
> { printf( 41 ); }
> 
>    . (Das könnte man dann auch noch automatisch starten.)
> 
>    Etwas schwieriger ist es, so etwas praktisch so nutzbar zu machen,
>    daß man bei komplizierteren Programmen noch die Übersicht behält.
> 
>    In C++ kann ein Programm durch Schablonen ("templates") Programmteile
>    in etwas strukturierterer Weise generieren lassen. Dennoch ist die
>    schablonenbasierte Metaprogrammierung für viele Programmierer recht
>    unübersichtlich. Nun kann man heute in C++ viele solcher Anwendungen
>    vereinfachen, indem man verlangen kann, daß bestimmte Programmteile
>    bereits bei der Übersetzung ausgeführt werden, was auf recht über-
>    sichtliche Weise möglich ist.
> 
>    C++ versteht Uhrzeiten normalerweise nicht in der Schreibweise
>    "7_Std + 3_min". Das folgende C++-Programm erweitert die Programmier-
>    sprache aber so, daß es diese Schreibweise versteht. Dabei erfolgt
>    die gesamte Interpretation von "7_Std + 3_min" bereits /während der
>    Übersetzung/ des Programms. (Das entspricht der Generierung eines
>    anderen Programms, mit Ausführung dieser Operationen während der
>    Generierung, wie "rand()" oben.) Gleichzeit ist der Quelltext aber
>    übersichtlich, da normales C++ verwendet wird, nur mit "constexpr"
>    angereichert.
> 
>    main.cpp
> 
> #include <cstdint>
> #include <iostream>
> 
> struct time
> { double s;
>    constexpr time( time && x )noexcept:
>    s{ static_cast< double >( x.s )} { }
>    constexpr explicit time( ::std::uint64_t const s = 0 ):
>    s{ static_cast< double >( s ) } {}
>    constexpr time & operator +=( const time & o )
>    { s += o.s; return *this; }
>    ::std::ostream & print( ::std::ostream & stream )const
>    { return stream << s << " s"; }};
> 
> constexpr inline time operator +( time result, time const & other )
> { result += other; return result; }
> 
> inline ::std::ostream& operator <<
> ( ::std::ostream & stream, time const & object )
> { return object.print( stream ); }
> 
> constexpr time operator "" _Std( ::std::uint64_t const v )
> { return time( v*( 60 * 60 )); }
> 
> constexpr time operator "" _min( ::std::uint64_t const v )
> { return time( v * 60 ); }
> 
> int main(){ ::std::cout << 7_Std + 3_min << '\n'; }
> 
>    transcript
> 
> 25380 s

Mit deiner Formatierung fliegste aber aus 99 von 100 Teams

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

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

csiph-web

Weißes Haus warnt vor C++

Contents

#616895 — Weißes Haus warnt vor C++

#616924

#616931

#616932

#617000

#617010

#617033

#617036

#617058

#617091

#617099

#617100

#617107 — Re: Tabellenformate

#617102

#617120

#617127

#617167 — Re: Metaprogrammierung

#617172 — Re: Metaprogrammierung

#617179 — Re: Metaprogrammierung

#617171 — Re: Metaprogrammierung