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

Groups > ger.ct > #616895 > unrolled thread

Weißes Haus warnt vor C++

Back to article view | Back to ger.ct

Contents

  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 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#617178 — Re: Metaprogrammierung

Am 07.03.24 um 13:41 schrieb Bonita Montero:
>> #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

Es sein denn, er verwendet einen (Selbstbau?) "pretty printer"
der Klammern und Einrückung  der üblichen C Zeilenverschwendung anpasst.

Hermann
    der wegen der Klammer Extra Zählung von Klammern bei Programmmgröße
    anhand von Quellprogrammzeilen ..

p.s.
Die (scheinbare) Programmgröße wächst (nach meiner Erfahrung) auch,
wenn man abwechselnd auf mainframe und Unix editiert.
mainframe führt bei Zeilenlänge 0 ein Leerzeichen ein
und Unix fügt hinter der letzten Zeile, wenn die nicht mit \n endet,
ein \n (Leerzeile) hinzu.

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

#617181 — Re: Metaprogrammierung

Am 07.03.2024 um 15:22 schrieb Hermann Riemann:
> Am 07.03.24 um 13:41 schrieb Bonita Montero:
>>> #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
> 
> Es sein denn, er verwendet einen (Selbstbau?) "pretty printer"
> der Klammern und Einrückung  der üblichen C Zeilenverschwendung anpasst.

Ist das Wort pretty dann kein Zynismus ?

> 
> Hermann
>     der wegen der Klammer Extra Zählung von Klammern bei Programmmgröße
>     anhand von Quellprogrammzeilen ..
> 
> p.s.
> Die (scheinbare) Programmgröße wächst (nach meiner Erfahrung) auch,
> wenn man abwechselnd auf mainframe und Unix editiert.
> mainframe führt bei Zeilenlänge 0 ein Leerzeichen ein
> und Unix fügt hinter der letzten Zeile, wenn die nicht mit \n endet,
> ein \n (Leerzeile) hinzu.

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

#617185 — Re: Metaprogrammierung

Am 07.03.24 um 16:15 schrieb Bonita Montero:

>> Es sein denn, er verwendet einen (Selbstbau?) "pretty printer"
>> der Klammern und Einrückung  der üblichen C Zeilenverschwendung anpasst.

> Ist das Wort pretty dann kein Zynismus ?

Was gefällt ist individuell unterschiedlich.
Und kann von Gewohnheiten abhängen.

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

#617188 — Re: Metaprogrammierung

Am 07.03.2024 um 17:59 schrieb Hermann Riemann:
> Am 07.03.24 um 16:15 schrieb Bonita Montero:
> 
>>> Es sein denn, er verwendet einen (Selbstbau?) "pretty printer"
>>> der Klammern und Einrückung  der üblichen C Zeilenverschwendung anpasst.
> 
>> Ist das Wort pretty dann kein Zynismus ?
> 
> Was gefällt ist individuell unterschiedlich.
> Und kann von Gewohnheiten abhängen.

In dem Fall fallen die meisten Gesschmäker eher so aus wie man es im
K&R C-Buch liest. Ich programmiere ja wie man sieht auch anders, aber
ich glaub damit können sich diejenigen die K&R-Stil programmieren auch
anfreunden. Was Stefan macht macht sicher nichmal einer von hunndert
und ist meiner Meinung nach jenseits von Gut und Böse.

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

#617205 — Re: Metaprogrammierung

Am 07.03.24 um 19:50 schrieb Stefan Ram:
> Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb oder zitierte:
>> Es sein denn, er verwendet einen (Selbstbau?) "pretty printer"
>> der Klammern und Einrückung  der üblichen C Zeilenverschwendung anpasst.
> 
>    Eine automatische Hin- und Herwandlung der Formatierung innerhalb
>    einer Arbeitsgruppe könnte Probleme bereiten. Daher sollten am besten
>    alle in einer Arbeitsgruppe die gleiche Formatierung verwenden.

Es muss ja nicht innerhalb der Arbeitsgruppe sein.

Wenn ich für meinen Teil

if (a>0){ a-=1;}

in meinen Quelltext habe,
und dann mit einem eigenen Quelltext Aufbereiter für die Text Dateien
an andere das nach

if (a>0)
     {
     a-=1;
}

umsetze, so kann ich besser arbeiten,
und erfülle Format Vorschriften.

Hermann
    der früher lange meist einen selbst geschriebenen listing Aufbereiter
    verwendet hat, den nach und nach auch andere verwendeten.

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

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

#617208 — Re: Metaprogrammierung

Am 08.03.24 um 12:46 schrieb Stefan Ram:
> Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb oder zitierte:
>> Wenn ich für meinen Teil
>> if (a>0){ a-=1;}
>> in meinen Quelltext habe,
>> und dann mit einem eigenen Quelltext Aufbereiter für die Text Dateien
>> an andere das nach
>>      {
>>      a-=1;
>> }
>> umsetze, so kann ich besser arbeiten,
>> und erfülle Format Vorschriften.
> 
>    So mache ich das auch. Die Formatierung ist für mich etwas
>    Veränderliches. Um Überblick zu haben, formatiere ich oft wie
> 
> { x }
> 
>    , aber falls ich dieses Programmstück bearbeiten will, "entpacke"
>    ich es manchmal in eine Formatierung wie
> 
> {
>    x
>    }
> 
>    . Ich vergrößere es sozusagen wie unter einer Lupe! Falls ich
>    dann damit fertig bin, verpacke ich es wieder wie in
> 
> { x }
> 
>    .
> 


Ich erwäge den offiziellen Stil

if (a>0)
    {
    a-=1;
}

erst mal zu

if (a>0)                                {
    a-=1;                                }

intern umzusetzen,
damit es Python ähnlich wird.


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

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

#617210 — Re: Metaprogrammierung

Am 08.03.24 um 13:04 schrieb Stefan Ram:
> Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb oder zitierte:
>> Ich erwäge den offiziellen Stil
> 
>    Soweit ich weiß, gibt es für die C- und C++-Programmierung keinen
>    "offiziellen Stil".
> 
suche nach style guide

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

#617221 — Re: Metaprogrammierung

Am 08.03.2024 um 13:04 schrieb Stefan Ram:
> Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb oder zitierte:
>> Ich erwäge den offiziellen Stil
> 
>    Soweit ich weiß, gibt es für die C- und C++-Programmierung keinen
>    "offiziellen Stil".

https://de.wikipedia.org/wiki/Einr%C3%BCckungsstil

Ich bevorzuge GNU.

Gruß Andreas

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

#617226 — Re: Metaprogrammierung

Am 08.03.2024 um 15:25 schrieb Stefan Ram:
> Andreas Fecht <forum@aftec.de> schrieb oder zitierte:
>> Am 08.03.2024 um 13:04 schrieb Stefan Ram:
>>> Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb oder zitierte:
>>>> Ich erwäge den offiziellen Stil
>>> Soweit ich weiß, gibt es für die C- und C++-Programmierung keinen
>>> "offiziellen Stil".
>> https://de.wikipedia.org/wiki/Einr%C3%BCckungsstil
>> Ich bevorzuge GNU.
> 
>    Der von mir bevorzugte Stil ähnelt noch am meisten dem, der
>    auf der Wikipedia-Seite mit dem URI-Fragment "Indent_style"
>    unter "pico" beschrieben ist:
> 
> stuff(n):
> { x: 3 * n;
>    y: doStuff(x);
>    y + x }
> 
>    . Aber man findet auch Ähnlichkeiten zu einem Beispiel in
>    Kernighans B-Lehrtext von 1972:
> 
>        if(---)
>          { -----
>            ----- }
>         else if(---)
>          { -----
>            ----- }
>         else if(----)
>          { -----
>            ----- }
> 
>    Ich hatte meinem Stil einmal für eine englischsprachige Newsgroup
>    erklärt:
> 
> Indentation within Braces
> 
>    An indentation of just one space often is too small to be seen
>    clearly, because the natural width and form of characters
>    often varies by an amount that is not very much smaller than a
>    space. Therefore, the indentation should amount to at least
>    two positions. In order not to waste horizontal spaces, an
>    indentation of exactly two positions is chosen. This means,
>    that the left position of the next level is two larger than
>    the position of the directly enclosing level.
> 
>    Indentation by two positions within a block
> 
> { ++x;
>    ++x; }
> ^ ^
> 0 2
> 
>    Bad: A small indentation by one position is not always visible
>    clearly
> 
> {++x;
>   ++x; }
> 
>    Good: The indentation by two positions is visible clearly
> 
> { ++x;
>    ++x; }
> 
>    Bad: A large indentation by more than two positions wastes
>    horizontal space with no additional benefit
> 
> {    ++x;
>       ++x; }
> 
> Spaces within braces
> 
>    In mathematics, there are often no spaces at the inner side of
>    parentheses or braces in expressions, but spaces are used
>    indeed at the inner side of braces in set notation, when the
>    braces contain a description (not when they contain a list).
> 
>    Spaces in set notation
> 
> { x | x > 2 }
> 
>    This style is adopted here: One space is written at the inner
>    side of braces.
> 
>    Spaces at the inner side of parentheses within a block
> 
> { ++x; }
> 
>    This style is consistent with the indentation by two
>    positions, because only using this style, corresponding parts
>    of two lines have the same position.
> 
>    Bad: No space after the first brace, the two statements are
>    misaligned
> 
> {++x;
>    ++x; }
> 
>    Good: One space after the first brace, the two statements are
>    properly aligned
> 
> { ++x;
>    ++x; }
> 
>    Bad: Two spaces after the first brace, the two statements are
>    misaligned
> 
> {  ++x;
>    ++x; }
> 
>    There are some exceptions to this rule: No spaces are used
>    within empty braces "{}" and between two or more closing
>    braces of the same direction "}}", except, when the first one
>    of them is part of an empty pair "{} }" (an empty pair of
>    braces is treated like a single non-braces character).
> 
>    Unified rules for all Brackets
> 
>    For simplicity and uniformity, the rules from above apply to
>    all kinds of brackets, including parentheses, braces (curly
>    brackets), square brackets, and angle brackets.
> 
>    Spaces within parentheses and square brackets
> 
> { y = f( x )+ g() + a[ 2 ]; }
> 
>    Binary operators are sorrounded by a space, but the space is
>    omitted, when there already is a space on the other side of a
>    sequence of brackets directly beside the operator: By this rule,
>    " )+" is written instead of " ) +".
> 
>    Representation of the Syntactical Structure
> 
>    A method or function definition consists of a head and a body.
>    The following representation shows this structure:
> 
>    Good formatting according to the structure
> 
> void alpha() // head
> { beta(); }  // body
> 
>    The following formatting is misleading, because the line break
>    does not match the structural break:
> 
>    Bad line break within the body
> 
> void alpha() { // head and the beginning of the body
>    beta(); }    // the rest of the body
> 
>    This formatting also would make no sense for blocks within
>    blocks. So it is often not used for such blocks. Therefore
>    even the adopters of this style can not use it uniformly.
> 
>    Opening Braces Look Like "bullets"
> 
>    There is a well known style to publish lists in typography
>    using bullets sticking out on the left, looking like this:
> 
>    Common list representation with bullets in typography
> 
> o This is the first point
>    of this list, it is written
>    here just as an example.
> 
> o Here is another entry
> 
> o This is another example given
>    just as an example to show
>    an example
> 
>    The braces of the beginnings of blocks stand out on the left
>    just the same, when the formatting being described here is
>    used, so they look quite naturally as beginning-of-a-block
>    markers, when one is used to the typographical list notation:
> 
>    Left braces look like bullets to mark blocks
> 
> { printf(); printf();
>    printf(); printf(); printf();
>    printf(); printf(); }
> 
> { printf(); printf(); }
> 
> { printf(); printf(); printf();
>    printf(); printf();
>    printf(); }
> 
>    Neutrality
> 
>    Someone wrote this C code:
> 
> while( fgets( eingabe, sizeof eingabe, stdin ))
>    if( sscanf( eingabe, "%d", &wert )!= 1 )
>      fprintf( stderr, "Please enter a number!\n" );
>    else
>      summe += wert;
> 
>    It amazes me that I can add braces by my style conventions
>    (not changing the meaning of the code)
>    without the need to change the position of any character of
>    the given code or need to change the overall number of lines:
> 
>    The code from above plus braces
> 
> while( fgets( eingabe, sizeof eingabe, stdin ))
> { if( sscanf( eingabe, "%d", &wert )!= 1 )
>    { fprintf( stderr, "Please enter a number!\n" ); }
>    else
>    { summe += wert; }}
> 
>    Insofar, my bracing style might be considered non-obtrusive.
> 
>    Lines per Contents
> 
>    Lines containing only a single brace waste vertical space, so
>    less contents fits on the same screen space. Therefore, I usually
>    avoid them, but sometimes I do use them, when this helps to
>    increase readability. I also might temporarily use them when editing
>    a section of code. Of course, they would help programmers paid or
>    being judged by the lines-of-code productivity.
> 
>    The Formatting of The If Statement
> 
>    I want my code to express the structur of the if statement.
> 
>    What is the structure of an if statement?
> 
>    According to ISO/IEC 9899:1999 (E)
> 
> selection-statement:
> if ( expression )
> statement
> 
>    So, there is a head clause
> 
> if ( expression )
> 
>    and a body statement
> 
> statement
> 
>    Thus,
> 
> if( expression )     /* head clause */
> { exam(); ple(); }   /* body statement */
> 
>    The separation between head and body in the deep structure
>    beautifully aligns with the separation between the first
>    and the second line in the visible surface structure. Thus,
>    the surface structure exposes the deep structure in a
>    not-misleading way. (Which to me is the generalized meaning
>    of »structured programming«: expressing as much of the deep
>    structure as possible already in the surface structure,
>    which makes the code more readable.)
> 
>    Moreover, why would anyone sane in his mind compose a line
>    of the head of a structure /and the first character of its
>    body/ with the rest of the body following in another line?
> 
> if( expression ) {   /* head clause AND first character
>                          of the body statement */
>    exam(); ple();     /* rest of body, except for */
> }                    /* a line wasted on a brace */
> 
>    As a comparision, in writing, we have headings and text body:
> 
>        The Creation
> 
>        In the beginning God created the heaven and the earth.
> 
>    Now, why would someone write the heading /and the first word of
>    its body/ on a line, as in the following example?
> 
>        The Creation In
> 
>        the beginning God created the heaven and the earth.
> 
>    I write:
> 
> if
> ( sscanf( input_buffer, "%d %d %d", &length, &width, &height )== 3 &&
>    sscanf( other_buffer, "%d %d %d", &color,  &price, &weight )== 3 &&
>    needs_processing( color ))
> { compute_volume( length, width, height );
>    compute_something_else( price, weight ); }
> 
> ^
> '---- What I like about this is:
> 
>        This is an if statement with two variable constituents:
>        an expression and a statement.
> 
>        This is the macrostructure.
> 
>        The major questions one encounters when reading are:
> 
>            - What a kind of entity is this at all?
> 
>        And then, having learned that it is an if statement:
> 
>            - Where is its expression?
> 
>            - Where is its statement?
> 
>        And it are exactly the answers to these three questions
>        that are each marked with a character in the leftmost column!
> 
>        So the type of the entity and its two constituents
>        clearly stand out graphically (visually). Albeit in a
>        manner not too obtrusive and not wasting lines.
> 
>         Now we can compare this with (IIRC, this is code someone else wrote):
> 
> if (sscanf(input_buffer, "%d %d %d", &length, &width, &height) == 3 &&
>      sscanf(other_buffer, "%d %d %d", &color, &price, &weight) == 3 &&
>      needs_processing(color)) {
>      compute_volume(length, width, height);
>      compute_something_else(price, weight);
> }
> 
>         Here the start and end of the statement are marked in the
>         leftmost column. This is also not bad, but the important
>         separation between the expression and the statement of the
>         if is »hidden« in the »center« of this character structure.

Mit dem Stil arbeitet man allein.

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

#617108 — Re: Langsamkeit von Python

Am 06.03.24 um 10:34 schrieb Stefan Ram:

>    Das heißt: Wenn man sich mit einigen Techniken vertraut macht,
>    dann kann man bestimmte Dinge so schreiben, daß die Langsamkeit
>    von Python umgangen wird.

Mein letztes großes Python Programm
generiert aus Eingabe Dateien provider und homepage
abhängige Ausgabe Dateien für alle meine homepages.
Es braucht dafür 2-3 Sekunden.
Der Hauptteil könnte dabei IO auf Festplatten sein.
Als ich als nfs server einen PC statt einer Synology verwendet hatte,
musste ich lange warten.

Ein anderes Python Programm werde ich durch C Programm ersetzten.
Es hat die binomische Formel (a+b)² = a²+2ab+b² "entdeckt".
Es hat allerdings sehr lange gerechnet.
Mit vorwärts und rückwärts verkettete "Listen"
der Knoten "Gewicht" für Bewertung enthielten.

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

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

#617119 — Re: Langsamkeit von Python

Am 06.03.24 um 11:31 schrieb Stefan Ram:
> Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb oder zitierte:
>> Ein anderes Python Programm werde ich durch C Programm ersetzten.
>> Es hat die binomische Formel (a+b)² = a²+2ab+b² "entdeckt".
> 
>    Für symbolische Mathematik mit Python gibt es übrigens auch
>    die Bücherei "SymPy".
> 
>    Wenn ein Programm "(a+b)² = a²+2ab+b²" entdecken soll, kommt
>    es natürlich darauf an, welche anderen Regeln man dem Programm
>    als Grundlage mitteilt. In Frage kommen beispielsweise
>    x² = x·x (Definition von "²"),
>    a·b = b·a (Kommutativgesetz) und
>    ( x + y )·a = x·a + y·a (Distributivgesetz).
> 

Nicht nur.

Dann wäre a²+ab+ba+b² dem a²+2ab+b² gleichwertig.
Da wird mit Gewicht z.B. die Anzahl der Operationen bewertet.

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

#617112

Am 06.03.2024 um 10:22 schrieb Hermann Riemann:

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

Erstens ist Python sicher noch ein paar Nullen hintendran
langsamer und zweitens sind 50.000 Datensätze bei linearer
Suche auch mit Python nicht das große Ding.

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

#617111

Am 06.03.2024 um 06:57 schrieb F. W.:

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

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

Sowas geht aber mit ner SQL-fähigen Datenbank viel angenehmer.

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

#617128

Am 06.03.2024 um 11:33 schrieb Bonita Montero:

> Am 06.03.2024 um 06:57 schrieb F. W.:
> 
>>> Wenn es zeitkritisch wäre, wäre vielleicht eine andere Sprache
>>> ( Rust, R )? empfehlenswert.
> 
>> Bei den damaligen, schnellen PC waren nicht mal Datenbanken 
>> notwendig.
> 
> Sowas geht aber mit ner SQL-fähigen Datenbank viel angenehmer.
> 

Das kommt darauf an, was Du unter "angenehm" verstehst. Ich habe gern
_ein_ Buch, _eine_ Website offen und _eine_ Referenz beim Programmieren.

Ich programmiere nämlich gern in _einer_ Sprache.

Wenigstens für mich wäre also der Verzicht auf SQL sehr angenehm. Und
ich erinnere mich daran, dass die Progs das auch fanden.

FW

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

#617138

Am 06.03.2024 um 15:30 schrieb F. W.:

> Wenigstens für mich wäre also der Verzicht auf SQL sehr angenehm.
> Und ich erinnere mich daran, dass die Progs das auch fanden.

Das ist einfach Quatsch bzw. wenn Du dir den Komfort den dir
SQL bietet händisch nachbilden wolltest, und sei es auch für
einfachste SQL-Statements, dann programmierst Du dir nen Wolf.

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

#617162

Am 06.03.24 um 16:18 schrieb Bonita Montero:

> Am 06.03.2024 um 15:30 schrieb F. W.:
> 
>> Wenigstens für mich wäre also der Verzicht auf SQL sehr angenehm. 
>> Und ich erinnere mich daran, dass die Progs das auch fanden.
> 
> Das ist einfach Quatsch bzw. wenn Du dir den Komfort den dir SQL 
> bietet händisch nachbilden wolltest, und sei es auch für einfachste 
> SQL-Statements, dann programmierst Du dir nen Wolf.
> 

Da stimme ich Dir zu. Aber das ist/war in kaufmännischen Anwendungen
eben nicht notwendig. Eine Sortierung, eine Suche oder einen Filter
programmiert man auch ohne SQL ziemlich flott.

FW

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

#617169

Am 07.03.2024 um 07:00 schrieb F. W.:
> Am 06.03.24 um 16:18 schrieb Bonita Montero:
> 
>> Am 06.03.2024 um 15:30 schrieb F. W.:
>>
>>> Wenigstens für mich wäre also der Verzicht auf SQL sehr angenehm. Und 
>>> ich erinnere mich daran, dass die Progs das auch fanden.
>>
>> Das ist einfach Quatsch bzw. wenn Du dir den Komfort den dir SQL 
>> bietet händisch nachbilden wolltest, und sei es auch für einfachste 
>> SQL-Statements, dann programmierst Du dir nen Wolf.
>>
> 
> Da stimme ich Dir zu. Aber das ist/war in kaufmännischen Anwendungen
> eben nicht notwendig. Eine Sortierung, eine Suche oder einen Filter
> programmiert man auch ohne SQL ziemlich flott.
> 
> FW

Es geht um die Persistenz, und die programmierst Du dir eben
nicht so mal eben.

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

#617173

Am 07.03.2024 um 13:39 schrieb Bonita Montero:
> Am 07.03.2024 um 07:00 schrieb F. W.:
>> Am 06.03.24 um 16:18 schrieb Bonita Montero:
>>
>>> Am 06.03.2024 um 15:30 schrieb F. W.:
>>>
>>>> Wenigstens für mich wäre also der Verzicht auf SQL sehr angenehm. 
>>>> Und ich erinnere mich daran, dass die Progs das auch fanden.
>>>
>>> Das ist einfach Quatsch bzw. wenn Du dir den Komfort den dir SQL 
>>> bietet händisch nachbilden wolltest, und sei es auch für einfachste 
>>> SQL-Statements, dann programmierst Du dir nen Wolf.
>>>
>>
>> Da stimme ich Dir zu. Aber das ist/war in kaufmännischen Anwendungen
>> eben nicht notwendig. Eine Sortierung, eine Suche oder einen Filter
>> programmiert man auch ohne SQL ziemlich flott.
>>
>> FW
> 
> Es geht um die Persistenz, und die programmierst Du dir eben
> nicht so mal eben.
> 

Persistenz bedeutet vieles in der Informatik. Welche Persistenz meinst 
Du hier?

FW

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

#617175

Am 07.03.2024 um 14:00 schrieb F. W.:
> Am 07.03.2024 um 13:39 schrieb Bonita Montero:
>> Am 07.03.2024 um 07:00 schrieb F. W.:
>>> Am 06.03.24 um 16:18 schrieb Bonita Montero:
>>>
>>>> Am 06.03.2024 um 15:30 schrieb F. W.:
>>>>
>>>>> Wenigstens für mich wäre also der Verzicht auf SQL sehr angenehm. 
>>>>> Und ich erinnere mich daran, dass die Progs das auch fanden.
>>>>
>>>> Das ist einfach Quatsch bzw. wenn Du dir den Komfort den dir SQL 
>>>> bietet händisch nachbilden wolltest, und sei es auch für einfachste 
>>>> SQL-Statements, dann programmierst Du dir nen Wolf.
>>>>
>>>
>>> Da stimme ich Dir zu. Aber das ist/war in kaufmännischen Anwendungen
>>> eben nicht notwendig. Eine Sortierung, eine Suche oder einen Filter
>>> programmiert man auch ohne SQL ziemlich flott.
>>>
>>> FW
>>
>> Es geht um die Persistenz, und die programmierst Du dir eben
>> nicht so mal eben.
>>
> 
> Persistenz bedeutet vieles in der Informatik. Welche Persistenz meinst 
> Du hier?
> 
> FW
> 

Ne, Persistenz bedeutet dauerhafte Datenspeicherung.
Das kann man mit einer SQL-Datenbank machen, geht
aber auch händisch mit viel Aufwand.

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

#617200

Am 07.03.24 um 14:19 schrieb Bonita Montero:

> Ne, Persistenz bedeutet dauerhafte Datenspeicherung. Das kann man
> mit einer SQL-Datenbank machen, geht aber auch händisch mit viel 
> Aufwand.

Wieso? Eine einfache Textdatei ist auch dauerhaft gespeichert. Oder was
meinst Du?

FW

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

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

Back to top | Article view | ger.ct

csiph-web