Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pl.comp.programming > #30172 > unrolled thread
| Started by | godek.maciek@gmail.com |
|---|---|
| First post | 2017-08-12 14:07 -0700 |
| Last post | 2017-09-03 08:40 -0700 |
| Articles | 20 on this page of 206 — 15 participants |
Back to article view | Back to pl.comp.programming
Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-12 14:07 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-12 23:55 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-12 15:43 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-13 07:04 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-12 20:17 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-12 22:44 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-13 02:23 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-13 15:01 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-13 07:16 -0700
Re: Co jest nie tak z C++ (było: Rust) w systemie siła 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-08-13 16:52 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-13 18:15 +0200
Re: Co jest nie tak z C++ (było: Rust) w systemie siła 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-08-13 18:44 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-13 20:32 +0200
Re: Co jest nie tak z C++ (było: Rust) w systemie siła 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-08-13 21:23 +0200
Re: Co jest nie tak z C++ (było: Rust) Wojciech Muła <wojtek.mula@gmail.com> - 2017-08-16 09:47 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-16 20:28 +0200
Re: Co jest nie tak z C++ (było: Rust) Mateusz Bogusz <mabakay@o2.pl> - 2017-08-16 20:35 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-16 22:21 +0200
Re: Co jest nie tak z C++ (było: Rust) Mateusz Bogusz <mabakay@o2.pl> - 2017-08-18 18:46 +0200
Re: Co jest nie tak z C++ (było: Rust) szykcech@gmail.com - 2017-08-21 13:15 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-21 14:49 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-22 01:03 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-22 00:42 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-22 01:21 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-22 04:13 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-22 05:24 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-22 05:54 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-22 06:12 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-23 02:01 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-23 02:29 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-23 03:14 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-23 04:42 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-24 01:25 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 02:38 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-24 03:20 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 04:02 -0700
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-24 06:42 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-24 08:32 -0700
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-24 09:10 -0700
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-24 12:24 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:37 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-25 01:13 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 12:32 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-24 14:48 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 15:23 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-25 07:04 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-25 07:27 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-25 07:40 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 20:04 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-25 11:57 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 22:52 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-26 03:57 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-26 10:32 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-27 10:18 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 23:04 +0200
Re: Co jest nie tak z C++ (było: Rust) Wojciech Muła <wojtek.mula@gmail.com> - 2017-08-25 13:22 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 23:09 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 07:08 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-24 16:12 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-25 02:35 -0700
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-25 06:45 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 18:01 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 18:26 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-26 03:12 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-26 14:42 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-26 06:07 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-26 15:13 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-26 06:40 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-26 16:03 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-26 08:44 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-26 19:30 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-26 00:18 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-26 11:59 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-26 04:20 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-26 15:01 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-26 13:29 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-27 08:07 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-27 01:53 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-27 12:21 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-27 04:47 -0700
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-27 04:56 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-27 04:53 -0700
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-27 05:56 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-28 07:29 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-28 08:29 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-28 08:49 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 00:49 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-29 23:00 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 06:35 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 18:35 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 18:38 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 10:46 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-30 06:32 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 18:46 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 00:46 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 10:45 +0200
Re: Co jest nie tak z C++ (było: Rust) Szyk Cech <szyk100@o2.pl> - 2017-08-30 10:46 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 18:40 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 07:09 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 16:30 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 07:42 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 16:53 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 17:02 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 08:12 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 19:17 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 20:48 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 19:12 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 19:09 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 20:46 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 12:20 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 21:59 +0200
Re: Co jest nie tak z C++ (było: Rust) Wojciech Muła <wojtek.mula@gmail.com> - 2017-08-30 13:15 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 13:18 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 13:16 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 22:45 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 14:09 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-31 09:50 +0200
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-31 01:52 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-31 01:56 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-31 07:05 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-31 09:28 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-31 19:35 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-31 11:09 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-31 10:54 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-31 19:19 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-31 19:37 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-29 07:03 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-27 13:20 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-28 09:39 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-29 06:26 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-29 08:32 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-29 18:46 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-29 11:26 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:29 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:05 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:08 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 06:46 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:14 +0200
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-25 01:20 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-01 15:18 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-01 23:28 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-02 01:45 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-02 08:27 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-02 12:27 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-03 01:58 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-03 03:24 -0800
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2018-01-03 14:17 +0100
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-04 01:52 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-04 03:08 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-05 02:51 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-05 05:09 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-07 13:30 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-07 14:00 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-08 05:20 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-08 11:25 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-09 04:35 -0800
Re: Co jest nie tak z C++ (było: Rust) Roman Tyczka <noemail@because.no> - 2018-01-03 20:13 +0100
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-04 01:36 -0800
Re: Co jest nie tak z C++ (było: Rust) Roman Tyczka <noemail@because.no> - 2018-01-05 22:57 +0100
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-07 13:19 -0800
Re: Co jest nie tak z C++ (było: Rust) Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2018-01-02 14:32 +0100
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:04 +0200
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-25 00:45 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 12:54 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 17:55 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-23 15:22 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-23 17:31 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 22:33 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-23 14:33 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-24 00:14 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-23 23:45 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:06 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 12:39 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-23 15:24 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-23 08:05 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-23 17:35 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-23 15:13 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-23 08:18 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-23 17:38 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 22:35 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 01:06 -0700
[OT, SPAM] Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:07 +0200
Re: [OT, SPAM] Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 22:51 -0700
Re: [OT, SPAM] Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 17:41 +0200
Re: [OT, SPAM] Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-25 08:52 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 13:05 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 18:00 +0200
Re: Co jest nie tak z C++ (było: Rust) Piotr Chamera <piotr_chamera@poczta.onet.pl> - 2017-08-23 18:15 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 22:17 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 22:11 +0200
Re: Co jest nie tak z C++ (było: Rust) Mateusz Bogusz <mabakay@o2.pl> - 2017-08-24 20:11 +0200
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-25 00:42 -0700
Re: Co jest nie tak z C++ (było: Rust) Mateusz Bogusz <mabakay@o2.pl> - 2017-08-25 22:53 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 13:12 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-22 04:49 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-22 05:16 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 22:02 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 12:35 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 17:49 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 18:54 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 20:20 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 21:00 +0200
Re: Co jest nie tak z C++ (było: Rust) Wojciech Muła <wojtek.mula@gmail.com> - 2017-08-21 23:43 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 20:52 +0200
Re: Co jest nie tak z C++ (było: Rust) Wojciech Muła <wojtek.mula@gmail.com> - 2017-09-03 01:15 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-09-03 08:40 -0700
Page 1 of 11 [1] 2 3 … 11 Next page →
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2017-08-12 14:07 -0700 |
| Subject | Co jest nie tak z C++ (było: Rust) |
| Message-ID | <f3ef79f1-7f5e-4e06-a46d-e7ccc1d33b2a@googlegroups.com> |
W dniu sobota, 12 sierpnia 2017 15:59:27 UTC+2 użytkownik szyk...@gmail.com napisał: > Dobra! To może ugryźmy ten temat na poważnie. > Bo skoro znasz (dobrze?!?) języków programowania kilkanaście, > to może jesteś geniuszem i może mógłbyś oświecić ciemne masy > klepaczy co jest nie tak z C++. Co prawda pytanie nie było adresowane stricte do mnie, ale -- jak to mówią w internetach, "nie znam się, to się wypowiem" -- tym bardziej, że temat był już wałkowany w różnych okolicznościach pewnie miliard razy. I z pewnością, żeby odpowiedzieć na to pytanie, najpierw należałoby ustalić nasze oczekiwania względem danego języka, żeby można było zastosować jakieś kryteria, a nie prowadzić dyskusji na poziomie "język X jest zły, bo nie ma ficzera Z", albo "język X jest zły, bo nie jest językiem Y". Moim zdaniem, dużą wadą C++ jest to, że nie daje programiście środków do tego, żeby mógł go używać stosownie do swoich upodobań -- oczywiście w niektórych kontekstach można by to było uznać za zaletę, jednak "w ogólności" wydaje się to raczej wadą. Przykładowo, gdybym chciał, żeby wszystkie zmienne w C++ były domyślnie zadeklarowane jako "const", i tylko te, które zasadniczo chcę zmieniać, były zadeklarowane (np. jako "var"), C++ (z tego co wiem) nie daje mi możliwości uzyskania takiego zachowania. Podobnie, interfejsy dostarczane przez STL są bardzo dziwne. Jest sobie chociażby taki kontener "stack". Jak można się spodziewać, stack<T> ma funkcję push(T element), która kładzie element na stosie, oraz pop(), która zdejmuje element ze stosu. Problem w tym, że funkcja pop() nie zwraca zdejmowanego elementu. Uzasadnienie autorów biblioteki jest takie, że w ten sposób można uzyskać większą wydajność, i że STL jest projektowany w taki sposób, żeby "nie płacić za to, czego się nie używa" -- jednak brak ergonomii biblioteki jest w istocie pewną ceną -- tym więszką, gdy programiści przyzwyczają się, że zepsute interfejsy to norma. Jeśli ktoś ma ochotę posłuchać sobie tego rodzaju narzekań, to jest ten gość, Scott Meyers, który najpierw pisał dużo książek o C++, a później zaczął jeździć po konferencjach, narzekając na dziwność interfejsów C++ (sławiąc taką mantrę, żeby projektować interfejsy w taki sposób, żeby łatwo było ich używać poprawnie, i żeby trudno było ich używać niepoprawnie), i teraz zdaje się zajmuje się rozwijaniem języka D. Można sobie go w wolnej chwili obejrzeć np. tutaj https://www.youtube.com/watch?v=RT46MpK39rQ Poza tym długie czasy kompilacji i niezrozumiałe komunikaty diagnosyczne również są pewną ceną, którą programiści C++ muszą płacić. W każdym razie jeżeli używasz C++ i jesteś z tego zadowolony, to ja nie zamierzam Cię przekonywać, że nie jesteś. Jednak dla mnie duży stopień komplikacji tego języka (np. skomplikowana składnia i różne założenia utrudniające formułowanie wniosków dotyczących programów napisanych w C++) są na tyle poważnym problemem, że jeśli nie muszę, raczej staram się z niego nie korzystać.
[toc] | [next] | [standalone]
| From | slawek <fake@fakeemail.com> |
|---|---|
| Date | 2017-08-12 23:55 +0200 |
| Message-ID | <almarsoft.2798108691430527185@news.v.pl> |
| In reply to | #30172 |
On Sat, 12 Aug 2017 14:07:19 -0700 (PDT), godek.maciek@gmail.com wrote: > wadą. Przykładowo, gdybym chciał, żeby wszystkie zmienn= > e w C++ > były domyślnie zadeklarowane jako "const", i tylko te, które > zasadniczo chcę zmieniać, były zadeklarowane (np. jako "var"= > ), > C++ (z tego co wiem) nie daje mi możliwości uzyskania takiego > zachowania. Pomijam sensowność. Ale to akurat łatwo zrobić. Wystarczy twórczo zastosować #define, np.: #define int const int
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2017-08-12 15:43 -0700 |
| Message-ID | <acd9fa5e-2a66-4a0e-9620-3b7909405521@googlegroups.com> |
| In reply to | #30173 |
W dniu sobota, 12 sierpnia 2017 23:55:16 UTC+2 użytkownik slawek napisał: > > wadą. Przykładowo, gdybym chciał, żeby wszystkie zmienn= > > e w C++ > > były domyślnie zadeklarowane jako "const", i tylko te, które > > zasadniczo chcę zmieniać, były zadeklarowane (np. jako "var"= > > ), > > C++ (z tego co wiem) nie daje mi możliwości uzyskania takiego > > zachowania. > > > > Pomijam sensowność. Ale to akurat łatwo zrobić. Wystarczy twórczo > zastosować #define, np.: > > #define int const int a w jaki sposób słowo kluczowe "var" miałoby przy tym rozwiązaniu unieważniać consta?
[toc] | [prev] | [next] | [standalone]
| From | slawek <fake@fakeemail.com> |
|---|---|
| Date | 2017-08-13 07:04 +0200 |
| Message-ID | <almarsoft.4748444200060822798@news.v.pl> |
| In reply to | #30174 |
On Sat, 12 Aug 2017 15:43:45 -0700 (PDT), godek.maciek@gmail.com wrote: > a w jaki sposób słowo kluczowe "var" miałoby przy tym rozwi= > ązaniu > unieważniać consta? Np. makro var_int, ew. var(int). Albo zdefiniować typedef int Int
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2017-08-12 20:17 -0700 |
| Message-ID | <1f01fa30-404a-48f4-95a7-14e5795c3ba9@googlegroups.com> |
| In reply to | #30172 |
On Saturday, August 12, 2017 at 11:07:20 PM UTC+2, godek....@gmail.com wrote: > W dniu sobota, 12 sierpnia 2017 15:59:27 UTC+2 użytkownik szyk...@gmail.com napisał: > I z pewnością, żeby odpowiedzieć na to pytanie, najpierw > należałoby ustalić nasze oczekiwania względem danego języka, > żeby można było zastosować jakieś kryteria, a nie prowadzić > dyskusji na poziomie "język X jest zły, bo nie ma ficzera Z", > albo "język X jest zły, bo nie jest językiem Y". Kryterium porównawcze to dobra rzecz. > Moim zdaniem, dużą wadą C++ jest to, że nie daje programiście > środków do tego, żeby mógł go używać stosownie do swoich > upodobań -- oczywiście w niektórych kontekstach można by to > było uznać za zaletę, jednak "w ogólności" wydaje się to raczej > wadą. Tutaj pozwolę sobie trochę się nie zgodzić. W C++ generalnie jest dużo środków i można w nich przebierać. No chyba chodzi o biblioteki, w przypadku bibliotek trzeba brać albo taką jaka jest, albo se napisać swoją. Właśnie kolekcje do uporządkowanych zbiorów mi nie odpowiadają ani w QT, ani w STD, więc napisałem swoją. Ale to jest wada każdego języka. Chociaż taka Java od razu była nastawiona na prostotę i standaryzację ogromnej biblioteki... > Przykładowo, gdybym chciał, żeby wszystkie zmienne w C++ > były domyślnie zadeklarowane jako "const", i tylko te, które > zasadniczo chcę zmieniać, były zadeklarowane (np. jako "var"), > C++ (z tego co wiem) nie daje mi możliwości uzyskania takiego > zachowania. Ale takiego efektu w żadnym języku nie można uzyskać, o ile zrozumiałem co masz na myśli. Jeśli zostanie przewidziane przed pisaniem kodu, to można sprytne define zrobić, jeśli nie, to w żadnym języku tak się nie da. > Podobnie, interfejsy dostarczane przez STL są bardzo dziwne. > Jest sobie chociażby taki kontener "stack". Jak można się spodziewać, > stack<T> ma funkcję push(T element), która kładzie element na stosie, > oraz pop(), która zdejmuje element ze stosu. Idzie z tym żyć. Ja na tę sprawę mam inny pogląd. W innych językach, jest mniej możliwości. Naturalne dla innych języków jest to, że biblioteka zazwyczaj jest taka jaka powinna być w danym języku. A w C++ jest bardzo dużo środków wyrazu. Zazwyczaj z biblioteką taką jak STL czy QT można żyć. Problem w tym, że czasami chce potrzeba biblioteki "skrojonej na miarę" do danego programu. Przy czym skrojona na miarę oznacza albo wygodę programowania, albo bezpieczeństwo, albo przejrzysty kod, albo ekstremalną wydajność. W innych językach nie tylu środków wyrazu, więc inne języki nie dają okazji do dzielenia włosa na czworo. W Javie nigdy w życiu nawet bym nie pomyślał o pisaniu swojego kontenera, bo po co? W C++ zazwyczaj używam swoich drzew, tablic hashujących, itd, ponieważ (w moim przypadku najczęściej) to skraca czas obliczeń. > Problem w tym, że funkcja pop() nie zwraca zdejmowanego elementu. > Uzasadnienie autorów biblioteki jest takie, że w ten sposób można > uzyskać większą wydajność, i że STL jest projektowany w taki sposób, > żeby "nie płacić za to, czego się nie używa" -- jednak brak > ergonomii biblioteki jest w istocie pewną ceną -- tym więszką, gdy > programiści przyzwyczają się, że zepsute interfejsy to norma. Zazwyczaj jest bardzo wysoka cena za bardzo małe zwiększenie wydajności. Stos ma metodę top która zwraca. Można wywołać top a potem pop. I pewnie w konkretnym przypadku będzie efekt przeciwny do zamierzonego, pewnie wydajność będzie gorsza dla dwóch wywołań niż dla jednego z odpowiednim typem zwracanym. A jakby dziedziczyć po stosie i sobie napisać taką metodę pop? W QT chyba nazywa się taka metoda take. > Jeśli ktoś ma ochotę posłuchać sobie tego rodzaju narzekań, to jest > ten gość, Scott Meyers, który najpierw pisał dużo książek o C++, > a później zaczął jeździć po konferencjach, narzekając na dziwność > interfejsów C++ (sławiąc taką mantrę, żeby projektować interfejsy > w taki sposób, żeby łatwo było ich używać poprawnie, i żeby trudno > było ich używać niepoprawnie), i teraz zdaje się zajmuje się > rozwijaniem języka D. Można sobie go w wolnej chwili obejrzeć > np. tutaj Nie, mam dosyć swojego narzekania ;-) > Poza tym długie czasy kompilacji i niezrozumiałe komunikaty diagnosyczne > również są pewną ceną, którą programiści C++ muszą płacić. Kompilacje można zrównoleglać w make. Komunikaty diagnostyczne... nie wiem.. zazwyczaj wiem co kompilator do mnie mówi, czasami tylko muszę chwilę się zastanowić. > W każdym razie jeżeli używasz C++ i jesteś z tego zadowolony, > to ja nie zamierzam Cię przekonywać, że nie jesteś. Jednak dla mnie > duży stopień komplikacji tego języka (np. skomplikowana > składnia i różne założenia utrudniające formułowanie wniosków > dotyczących programów napisanych w C++) są na tyle poważnym problemem, > że jeśli nie muszę, raczej staram się z niego nie korzystać. Dla mnie to co nazywasz komplikacją, jest bogactwem możliwości. Ale jeśli nie muszę, to też wolę np. Jave, PHP. Pozdrawiam
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2017-08-12 22:44 -0700 |
| Message-ID | <713caa26-136b-4c30-9207-176244f4f5fd@googlegroups.com> |
| In reply to | #30175 |
W dniu niedziela, 13 sierpnia 2017 05:17:23 UTC+2 użytkownik M.M. napisał: > On Saturday, August 12, 2017 at 11:07:20 PM UTC+2, godek....@gmail.com wrote: > > W dniu sobota, 12 sierpnia 2017 15:59:27 UTC+2 użytkownik szyk...@gmail.com napisał: > > > I z pewnością, żeby odpowiedzieć na to pytanie, najpierw > > należałoby ustalić nasze oczekiwania względem danego języka, > > żeby można było zastosować jakieś kryteria, a nie prowadzić > > dyskusji na poziomie "język X jest zły, bo nie ma ficzera Z", > > albo "język X jest zły, bo nie jest językiem Y". > Kryterium porównawcze to dobra rzecz. Mógłbyś doprecyzować, co masz na myśli, używając frazy "kryterium porównawcze"? (ja ją rozumiem w taki sposób, że to jest "kryterium, względem którego porównujemy", ale to ma sens dopiero wtedy, kiedy porównujemy, a nie kiedy próbujemy ustalić, jakie coś ma wady) > > Moim zdaniem, dużą wadą C++ jest to, że nie daje programiście > > środków do tego, żeby mógł go używać stosownie do swoich > > upodobań -- oczywiście w niektórych kontekstach można by to > > było uznać za zaletę, jednak "w ogólności" wydaje się to raczej > > wadą. > Tutaj pozwolę sobie trochę się nie zgodzić. W C++ generalnie > jest dużo środków i można w nich przebierać. No chyba chodzi o > biblioteki, w przypadku bibliotek trzeba brać albo taką jaka > jest, albo se napisać swoją. Nie chodzi o biblioteki. Chodzi o to, że jako programista nie możesz sobie napisać pętli for(iterator : kolekcja), tylko musisz poczekać, aż przyjdzie Komitet i Ci to zrobi. Tzn. ostatnio odkryłem, że jakieś 10 lat temu się bawiłem w takie rzeczy, i sobie sam zrobiłem (dla gcc) #define for_every(ITERATOR, COLLECTION) \ for(typeof(COLLECTION.begin()) ITERATOR = COLLECTION.begin(); \ ITERATOR != COLLECTION.end(); ++ITERATOR) ale niewykluczone, że od takich rzeczy głupieją narzędzia w rodzaju IDE. > Właśnie kolekcje do uporządkowanych > zbiorów mi nie odpowiadają ani w QT, ani w STD, więc napisałem > swoją. Ale to jest wada każdego języka. Chociaż taka Java od > razu była nastawiona na prostotę i standaryzację ogromnej > biblioteki... Dla mnie wygląda tak, jakby C++ był ofiarą swojego procesu standaryzacyjnego, który jest kumulatywny -- ficzery do języka są tylko dodawane, i kompatybilność wsteczna jest świętością. (Z Javą zresztą jest podobnie). Proces standaryzacyjny np. w Haskellu nie miał problemów z tym, żeby eksperymentować i zrywać z różnymi decyzjami projektowymi, które były uważane za błędne. Użytkownicy może trochę na tym ucierpieli, co z pewnością odbiło się na popularności tego systemu, ale wpływ na sam projekt języka miało dobry. > > Przykładowo, gdybym chciał, żeby wszystkie zmienne w C++ > > były domyślnie zadeklarowane jako "const", i tylko te, które > > zasadniczo chcę zmieniać, były zadeklarowane (np. jako "var"), > > C++ (z tego co wiem) nie daje mi możliwości uzyskania takiego > > zachowania. > Ale takiego efektu w żadnym języku nie można uzyskać, o ile > zrozumiałem co masz na myśli. Jeśli zostanie przewidziane > przed pisaniem kodu, to można sprytne define zrobić, jeśli nie, > to w żadnym języku tak się nie da. W Scali masz zasadniczo coś podobnego -- deklarujesz, czy określona zmienna jest "var", czy "val", tzn. czy jest mutowalna czy niemutowalna. W Scheme mógłbym bez problemu przesłonić operator przypisania, żeby sprawdzał, czy dana zmienna posiada deklarację pozwalającą na jej zmianę. > > Podobnie, interfejsy dostarczane przez STL są bardzo dziwne. > > Jest sobie chociażby taki kontener "stack". Jak można się spodziewać, > > stack<T> ma funkcję push(T element), która kładzie element na stosie, > > oraz pop(), która zdejmuje element ze stosu. > Idzie z tym żyć. Ja na tę sprawę mam inny pogląd. W innych językach, > jest mniej możliwości. Naturalne dla innych języków jest to, że > biblioteka zazwyczaj jest taka jaka powinna być w danym języku. A w > C++ jest bardzo dużo środków wyrazu. Zazwyczaj z biblioteką taką jak > STL czy QT można żyć. Problem w tym, że czasami chce potrzeba > biblioteki "skrojonej na miarę" do danego programu. Przy czym > skrojona na miarę oznacza albo wygodę programowania, albo > bezpieczeństwo, albo przejrzysty kod, albo ekstremalną wydajność. > W innych językach nie tylu środków wyrazu, więc inne języki > nie dają okazji do dzielenia włosa na czworo. W Javie nigdy w > życiu nawet bym nie pomyślał o pisaniu swojego kontenera, bo > po co? W C++ zazwyczaj używam swoich drzew, tablic hashujących, itd, > ponieważ (w moim przypadku najczęściej) to skraca czas obliczeń. > > Problem w tym, że funkcja pop() nie zwraca zdejmowanego elementu. > > Uzasadnienie autorów biblioteki jest takie, że w ten sposób można > > uzyskać większą wydajność, i że STL jest projektowany w taki sposób, > > żeby "nie płacić za to, czego się nie używa" -- jednak brak > > ergonomii biblioteki jest w istocie pewną ceną -- tym więszką, gdy > > programiści przyzwyczają się, że zepsute interfejsy to norma. > Zazwyczaj jest bardzo wysoka cena za bardzo małe zwiększenie wydajności. > Stos ma metodę top która zwraca. Można wywołać top a potem pop. I > pewnie w konkretnym przypadku będzie efekt przeciwny do zamierzonego, > pewnie wydajność będzie gorsza dla dwóch wywołań niż dla jednego z > odpowiednim typem zwracanym. A jakby dziedziczyć po stosie i sobie > napisać taką metodę pop? W QT chyba nazywa się taka metoda take. możliwości są różne. projektanci C++ mogliby zrobić "dispatch on return value" (Haskell ma coś takiego), i wówczas stack mógłby dostarczać dwóch implementacji "pop" -- jednej z typem void, a drugi z typem T. > > Jeśli ktoś ma ochotę posłuchać sobie tego rodzaju narzekań, to jest > > ten gość, Scott Meyers, który najpierw pisał dużo książek o C++, > > a później zaczął jeździć po konferencjach, narzekając na dziwność > > interfejsów C++ (sławiąc taką mantrę, żeby projektować interfejsy > > w taki sposób, żeby łatwo było ich używać poprawnie, i żeby trudno > > było ich używać niepoprawnie), i teraz zdaje się zajmuje się > > rozwijaniem języka D. Można sobie go w wolnej chwili obejrzeć > > np. tutaj > Nie, mam dosyć swojego narzekania ;-) > > > Poza tym długie czasy kompilacji i niezrozumiałe komunikaty diagnosyczne > > również są pewną ceną, którą programiści C++ muszą płacić. > Kompilacje można zrównoleglać w make. Komunikaty diagnostyczne... > nie wiem.. zazwyczaj wiem co kompilator do mnie mówi, czasami > tylko muszę chwilę się zastanowić. to musisz spróbować boosta ;] > > W każdym razie jeżeli używasz C++ i jesteś z tego zadowolony, > > to ja nie zamierzam Cię przekonywać, że nie jesteś. Jednak dla mnie > > duży stopień komplikacji tego języka (np. skomplikowana > > składnia i różne założenia utrudniające formułowanie wniosków > > dotyczących programów napisanych w C++) są na tyle poważnym problemem, > > że jeśli nie muszę, raczej staram się z niego nie korzystać. > Dla mnie to co nazywasz komplikacją, jest bogactwem możliwości. > Ale jeśli nie muszę, to też wolę np. Jave, PHP. Raczej miałem na myśli n. to, o czym wspominał Meyers w prezentacji. Że poziom skomplikowania C++ doprowadził do tego, że dające się używać narzędzia do refaktoryzacji kodu dla C++ pojawiły się w środowiskach IDE o dekadę później, niż dla innych języków. Co do owego "bogactwa możliwości" to C++ w istocie daje dużą kontrolę nad tym, co będzie robił komputer w trakcie wykonywania programu. Osobiście nie sądzę, żeby taka kontrola była potrzebna. Raczej wolałbym mieć narzędzie, które samo dobierze optymalne struktury danych do mojego programu, żebym mógł korzystać tylko z jednego prostego interfejsu do kolekcji (interfejsy w STLu wołają o pomstę do nieba). Sądzę, że takie podejście na dłuższą metę miałoby lepszy wpływ na wydajność programów, niż to, co oferuje C++.
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2017-08-13 02:23 -0700 |
| Message-ID | <b843f9a4-b8a8-4e9a-95e0-40319e419234@googlegroups.com> |
| In reply to | #30180 |
On Sunday, August 13, 2017 at 7:44:52 AM UTC+2, godek....@gmail.com wrote: > Mógłbyś doprecyzować, co masz na myśli, używając frazy > "kryterium porównawcze"? (ja ją rozumiem w taki sposób, > że to jest "kryterium, względem którego porównujemy", > ale to ma sens dopiero wtedy, kiedy porównujemy, a nie > kiedy próbujemy ustalić, jakie coś ma wady) Jeśli nie uściślimy sposobu w jaki chcemy porównywać języki, to rozmowa nabierze luźnego charakteru. Czasami z luźniej rozmowy też wynikają dobre rzeczy, można się wymienić doświadczeniami. Ale też można się pokłócić, bo jeden pisze strkite o języku, a drugi o dostępnych narzędziach. A kryterium, to np. cechy języka które ułatwiają/umożliwiają generowanie wydajnego kodu maszynowego. Albo cechy języka ułatwiające tworzenie przejrzystego kodu, bardziej podatnego na rozwój - co zapewne dobrze wiesz. > > > Moim zdaniem, dużą wadą C++ jest to, że nie daje programiście > > > środków do tego, żeby mógł go używać stosownie do swoich > > > upodobań -- oczywiście w niektórych kontekstach można by to > > > było uznać za zaletę, jednak "w ogólności" wydaje się to raczej > > > wadą. > > Tutaj pozwolę sobie trochę się nie zgodzić. W C++ generalnie > > jest dużo środków i można w nich przebierać. No chyba chodzi o > > biblioteki, w przypadku bibliotek trzeba brać albo taką jaka > > jest, albo se napisać swoją. > > Nie chodzi o biblioteki. Chodzi o to, że jako programista > nie możesz sobie napisać pętli for(iterator : kolekcja), > tylko musisz poczekać, aż przyjdzie Komitet i Ci to zrobi. Hmmm Ale w jakim sensie nie możesz? Czy chodzi o to, aby język C++ był taki, aby można było przediefiniowywać nie tylko operatory, ale i instrukcje? Czy o to, że jak w jednej firmie chcą mieć innego ifa, to nie mogą zmienić kompilatora? Jeśli chodzi o to pierwsze, to mówią, że język C++ ma już za dużo ficzerów ;-) Jeśli chodzi o to drugie, to dużym nakładem pracy można to zrobić, ale potem stary kod może nie być kompatybilny z nowymi lepszymi cechami języka lub bibliotekami. Więc może obecny stan rzeczy jest dobry? > Tzn. ostatnio odkryłem, że jakieś 10 lat temu się bawiłem w takie > rzeczy, i sobie sam zrobiłem (dla gcc) > > #define for_every(ITERATOR, COLLECTION) \ > for(typeof(COLLECTION.begin()) ITERATOR = COLLECTION.begin(); \ > ITERATOR != COLLECTION.end(); ++ITERATOR) > > ale niewykluczone, że od takich rzeczy głupieją narzędzia w rodzaju IDE. Hmmm widocznie mamy inne upodobania co do wyglądu kodu. O Javie często słyszałem, i zgadzam się z tym, że kod w Javie jest rozwlekły, ale jest bardzo ładny, czytelny, przejrzysty. W C++ zazwyczaj nie zależy mi na uniknięciu wypisywania kilku znaków więcej. Niemnie jednak przyznaję rację, że pięciokrotnie kwalifikowany dostęp do składowej powoduje, że pętla for nie mieści się na szerokość monitora w rozdzielczości 1900 :/ No ale zrobili w C++11 typ auto, co po pierwsze powoduje że składnia jest bardziej zwarta, a po drugie, ta sama pętla działa na wektorze, na zbiorze, na hash-mapie, i nie chce mi się wymieniać dalej. Ma to swoje zalety, kod jest bardziej podatny na zmiany. Z drugiej strony, moja ostatnia implementacja drzewek czerwono czarnych nie zawiera wypasionych iteratorów, ta sama pętla nie zadziała na std::vector, ale jest o wiele szybsza niż std::set. Może takie jest motto języka C++: jak bierzesz ten język, to aplikację dostosujesz lepiej do sprzętu, będzie działała szybciej, ale licz się z tym, że nakład pracy (licząc: wykonanie, poprawki, eksperymenty z wydajnością) będzie znacznie większy niż gdybyś wziął Javę? Co do głupienia środowiska, to zgadzam się, że to jest ważne. WIele razy nie używałem jakiegoś ficzera języka tylko dlatego, że środowisko go nie wspierało, nie wspominając o głupieniu. > > Właśnie kolekcje do uporządkowanych > > zbiorów mi nie odpowiadają ani w QT, ani w STD, więc napisałem > > swoją. Ale to jest wada każdego języka. Chociaż taka Java od > > razu była nastawiona na prostotę i standaryzację ogromnej > > biblioteki... > > Dla mnie wygląda tak, jakby C++ był ofiarą swojego procesu > standaryzacyjnego, który jest kumulatywny -- ficzery do języka > są tylko dodawane, i kompatybilność wsteczna jest świętością. > (Z Javą zresztą jest podobnie). > Proces standaryzacyjny np. w Haskellu nie miał problemów z tym, > żeby eksperymentować i zrywać z różnymi decyzjami projektowymi, > które były uważane za błędne. Użytkownicy może trochę na tym > ucierpieli, co z pewnością odbiło się na popularności tego systemu, > ale wpływ na sam projekt języka miało dobry. Nie znam Haskella. W Javie nadal "pisze się gładko". Jakby C++ był bardziej podobny do Javy, jakby C++ to była taka Java bez zarządzania pamięcią, to... nie wiem co by było. Najgorsza estetyczna masakra składniowa w C++ to szablony. (Początkujący mówią też, że w C++ tę masakrę powoduje jeszcze nadmiar operatorów, ale obyci z językiem mówią, że operatorów nie ma ani za dużo, ani za mało, bo weźmy takiego perla.) Ale na szablony podobno nie ma sposobu aby uczynić składnię bardziej przejrzystą. Za to kod genetyczny często jest trochę bardziej wydajny, no i kompilator sprawdzi typy lepiej, niż w przypadku wskaźnika na void. > > > Przykładowo, gdybym chciał, żeby wszystkie zmienne w C++ > > > były domyślnie zadeklarowane jako "const", i tylko te, które > > > zasadniczo chcę zmieniać, były zadeklarowane (np. jako "var"), > > > C++ (z tego co wiem) nie daje mi możliwości uzyskania takiego > > > zachowania. > > Ale takiego efektu w żadnym języku nie można uzyskać, o ile > > zrozumiałem co masz na myśli. Jeśli zostanie przewidziane > > przed pisaniem kodu, to można sprytne define zrobić, jeśli nie, > > to w żadnym języku tak się nie da. > > W Scali masz zasadniczo coś podobnego -- deklarujesz, czy określona > zmienna jest "var", czy "val", tzn. czy jest mutowalna czy niemutowalna. > W Scheme mógłbym bez problemu przesłonić operator przypisania, żeby > sprawdzał, czy dana zmienna posiada deklarację pozwalającą na jej zmianę. > > > > Podobnie, interfejsy dostarczane przez STL są bardzo dziwne. > > > Jest sobie chociażby taki kontener "stack". Jak można się spodziewać, > > > stack<T> ma funkcję push(T element), która kładzie element na stosie, > > > oraz pop(), która zdejmuje element ze stosu. > > Idzie z tym żyć. Ja na tę sprawę mam inny pogląd. W innych językach, > > jest mniej możliwości. Naturalne dla innych języków jest to, że > > biblioteka zazwyczaj jest taka jaka powinna być w danym języku. A w > > C++ jest bardzo dużo środków wyrazu. Zazwyczaj z biblioteką taką jak > > STL czy QT można żyć. Problem w tym, że czasami chce potrzeba > > biblioteki "skrojonej na miarę" do danego programu. Przy czym > > skrojona na miarę oznacza albo wygodę programowania, albo > > bezpieczeństwo, albo przejrzysty kod, albo ekstremalną wydajność. > > W innych językach nie tylu środków wyrazu, więc inne języki > > nie dają okazji do dzielenia włosa na czworo. W Javie nigdy w > > życiu nawet bym nie pomyślał o pisaniu swojego kontenera, bo > > po co? W C++ zazwyczaj używam swoich drzew, tablic hashujących, itd, > > ponieważ (w moim przypadku najczęściej) to skraca czas obliczeń. > > > > > Problem w tym, że funkcja pop() nie zwraca zdejmowanego elementu. > > > Uzasadnienie autorów biblioteki jest takie, że w ten sposób można > > > uzyskać większą wydajność, i że STL jest projektowany w taki sposób, > > > żeby "nie płacić za to, czego się nie używa" -- jednak brak > > > ergonomii biblioteki jest w istocie pewną ceną -- tym więszką, gdy > > > programiści przyzwyczają się, że zepsute interfejsy to norma. > > Zazwyczaj jest bardzo wysoka cena za bardzo małe zwiększenie wydajności. > > Stos ma metodę top która zwraca. Można wywołać top a potem pop. I > > pewnie w konkretnym przypadku będzie efekt przeciwny do zamierzonego, > > pewnie wydajność będzie gorsza dla dwóch wywołań niż dla jednego z > > odpowiednim typem zwracanym. A jakby dziedziczyć po stosie i sobie > > napisać taką metodę pop? W QT chyba nazywa się taka metoda take. > > możliwości są różne. projektanci C++ mogliby zrobić "dispatch on return > value" (Haskell ma coś takiego), i wówczas stack mógłby dostarczać dwóch > implementacji "pop" -- jednej z typem void, a drugi z typem T. > > > > Jeśli ktoś ma ochotę posłuchać sobie tego rodzaju narzekań, to jest > > > ten gość, Scott Meyers, który najpierw pisał dużo książek o C++, > > > a później zaczął jeździć po konferencjach, narzekając na dziwność > > > interfejsów C++ (sławiąc taką mantrę, żeby projektować interfejsy > > > w taki sposób, żeby łatwo było ich używać poprawnie, i żeby trudno > > > było ich używać niepoprawnie), i teraz zdaje się zajmuje się > > > rozwijaniem języka D. Można sobie go w wolnej chwili obejrzeć > > > np. tutaj > > Nie, mam dosyć swojego narzekania ;-) > > > > > Poza tym długie czasy kompilacji i niezrozumiałe komunikaty diagnosyczne > > > również są pewną ceną, którą programiści C++ muszą płacić. > > Kompilacje można zrównoleglać w make. Komunikaty diagnostyczne... > > nie wiem.. zazwyczaj wiem co kompilator do mnie mówi, czasami > > tylko muszę chwilę się zastanowić. > > to musisz spróbować boosta ;] Próbowałem skompilować QT na intel Atom. Nie udalo się. Ale na klastrze i na dysku SSD pewnie można skompilować całe QT w 5-10 minut. > > > W każdym razie jeżeli używasz C++ i jesteś z tego zadowolony, > > > to ja nie zamierzam Cię przekonywać, że nie jesteś. Jednak dla mnie > > > duży stopień komplikacji tego języka (np. skomplikowana > > > składnia i różne założenia utrudniające formułowanie wniosków > > > dotyczących programów napisanych w C++) są na tyle poważnym problemem, > > > że jeśli nie muszę, raczej staram się z niego nie korzystać. > > Dla mnie to co nazywasz komplikacją, jest bogactwem możliwości. > > Ale jeśli nie muszę, to też wolę np. Jave, PHP. > > Raczej miałem na myśli n. to, o czym wspominał Meyers w prezentacji. > Że poziom skomplikowania C++ doprowadził do tego, że dające się > używać narzędzia do refaktoryzacji kodu dla C++ pojawiły się > w środowiskach IDE o dekadę później, niż dla innych języków. > > Co do owego "bogactwa możliwości" to C++ w istocie daje dużą kontrolę > nad tym, co będzie robił komputer w trakcie wykonywania programu. > Osobiście nie sądzę, żeby taka kontrola była potrzebna. Raczej > wolałbym mieć narzędzie, które samo dobierze optymalne struktury > danych do mojego programu, żebym mógł korzystać tylko z jednego > prostego interfejsu do kolekcji (interfejsy w STLu wołają o pomstę > do nieba). Sądzę, że takie podejście na dłuższą metę miałoby lepszy > wpływ na wydajność programów, niż to, co oferuje C++. Właśnie nie jestem pewien. Kompilatory już dawno generują lepszy kod niż programiści asemblerowi, no chyba że jakiś programista da sobie bardzo dużo czasu na mały kawałek kodu, lub znajdzie jakąś naprawdę słabą stronę kompilatora. Pomimo tego że kompilatory są takie dobre, nadal widzę że programowanie z "podpowiedziami dla kompilatora" daje kod nawet 2-3 razy bardziej wydajny. Cały czas widzę, że pętelka na wskaźnikach lepiej działa niż na iteratorach z kolekcji. Nie wiem dlaczego kompilator po prostu nie "rzutuje" iteratorów na wskaźniki, może to w ogóle nie jest możliwe, może w ten sposób czasami generowałby błędny kod wynikowy? Czasami nawet widzę, że for( int i=0 ; i<size ; i++) operacje( tablica[i] ); jest gorszy od kodu: for( int *i = tablica ; i != tablica+size ; i++ ) operacje( *i ); Dlaczego kompilator jednego na drugie nie zamieni sam, to nie wiem. Może to co proponujesz jest w ogóle niemożliwe, a konkretnie, może niemożliwe jest generowanie wydajnego kodu na podstawie jednego prostego interfejsu? Pozdrawiam
[toc] | [prev] | [next] | [standalone]
| From | slawek <fake@fakeemail.com> |
|---|---|
| Date | 2017-08-13 15:01 +0200 |
| Message-ID | <almarsoft.5667906008028876396@news.v.pl> |
| In reply to | #30181 |
On Sun, 13 Aug 2017 02:23:29 -0700 (PDT), "M.M." <mmarszik@gmail.com> wrote > Kompilatory już dawno generują lepszy kod > niż programiści asemblerowi To kolejna miejska legenda. Dobry programista zawsze będzie lepszy niż kompilator. Ale zawsze będzie znacznie wolniej pracować. Czyli nie opłaca się zatrudniać programisty do tego co może być zrobione automatycznie. Asembler dobrych CPU ma cudeńka (rejestry wektorowe, rozszerzenia instrukcji) normalnie nie używane przez kompilator.
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2017-08-13 07:16 -0700 |
| Message-ID | <8cda43a4-361a-4cde-9475-38809cca11e9@googlegroups.com> |
| In reply to | #30186 |
On Sunday, August 13, 2017 at 3:01:57 PM UTC+2, slawek wrote: > On Sun, 13 Aug 2017 02:23:29 -0700 (PDT), "M.M." <mmarszik@gmail.com> > wrote > > > Kompilatory już dawno generują lepszy kod > > niż programiści asemblerowi > > To kolejna miejska legenda. Dobry programista zawsze będzie lepszy > niż kompilator. Ale zawsze będzie znacznie wolniej pracować. Czyli > nie opłaca się zatrudniać programisty do tego co może być zrobione > automatycznie. > > Asembler dobrych CPU ma cudeńka (rejestry wektorowe, rozszerzenia > instrukcji) normalnie nie używane przez kompilator. Tak, to jest mit, ale ja go nie rozpowszechniam bez dodatkowej klauzuli ;-) Pozdrawiam
[toc] | [prev] | [next] | [standalone]
| From | w systemie siła 'POPIS/EU <NOSPAMtestowanije@go2.pl> |
|---|---|
| Date | 2017-08-13 16:52 +0200 |
| Message-ID | <ompp3d$2pe$2@node1.news.atman.pl> |
| In reply to | #30186 |
>> Kompilatory już dawno generują lepszy kod >> niż programiści asemblerowi dobrze wiesz, że nie o to chodzi - dobrze wiesz, że w środowisku (jakieś ufoludki spowodowały, że) pojawiła się (tak tak, za czasów C++) opinia, że assemblerowcy to jacyś bezmózdzy debile, nie to co liderzy JAVA dla przykładu...
[toc] | [prev] | [next] | [standalone]
| From | slawek <fake@fakeemail.com> |
|---|---|
| Date | 2017-08-13 18:15 +0200 |
| Message-ID | <almarsoft.2603328001027357396@news.v.pl> |
| In reply to | #30190 |
On Sun, 13 Aug 2017 16:52:25 +0200, w systemie siła 'POPIS/EU<NOSPAMtestowanije@go2.pl> wrote: > za czasów C++ Za czasów MSC 5.1 już była. Prawdopodobnie wcześniej. Dobry makroasembler plus np. Win API daje wygodę programowania porównywalną z C. Ale kosztem przywiązania do konkretnego procesora. Co w dzisiejszych czasach jest raczej głupie... jeżeli nie jest absolutnie konieczne. Zaletą C jest że to prawie asembler. Czyli można pisać bardzo nisko. Wadą C++ (która na ładne parę lat zniechęciła mnie do C++) jest obiecywanie cudów na kiju i jednocześnie kompilatory nie potrafiące zrobić dzielenia, źle obsługujące goto, niezgodne ze standardem w obie strony, wojenka MS z POSIX, bałagan z wide char i spieranie się o .h jakby nie było ważniejszych rzeczy.
[toc] | [prev] | [next] | [standalone]
| From | w systemie siła 'POPIS/EU <NOSPAMtestowanije@go2.pl> |
|---|---|
| Date | 2017-08-13 18:44 +0200 |
| Message-ID | <ompvm0$a9v$1@node2.news.atman.pl> |
| In reply to | #30191 |
cwanie wybrnąłeś z sytuacji! bo już miałem napisać - że był to czas pojawienia się w szkołach tzw. "pań informatyczek"...
[toc] | [prev] | [next] | [standalone]
| From | slawek <fake@fakeemail.com> |
|---|---|
| Date | 2017-08-13 20:32 +0200 |
| Message-ID | <almarsoft.2129348136683445224@news.v.pl> |
| In reply to | #30193 |
On Sun, 13 Aug 2017 18:44:48 +0200, w systemie siła 'POPIS/EU<NOSPAMtestowanije@go2.pl> wrote: > "pań informatyczek"... Znam osobiście przynajmniej jedną informatyczkę, która jest naprawdę dobra w tym co robi.
[toc] | [prev] | [next] | [standalone]
| From | w systemie siła 'POPIS/EU <NOSPAMtestowanije@go2.pl> |
|---|---|
| Date | 2017-08-13 21:23 +0200 |
| Message-ID | <omq8vd$ili$4@node1.news.atman.pl> |
| In reply to | #30196 |
może i tak, ale nie można o tym wszystkim rozmawiać bez uwzględniania $...
[toc] | [prev] | [next] | [standalone]
| From | Wojciech Muła <wojtek.mula@gmail.com> |
|---|---|
| Date | 2017-08-16 09:47 -0700 |
| Message-ID | <2966e53f-6bf3-4ebf-ba44-c321b08c2e30@googlegroups.com> |
| In reply to | #30186 |
On Sunday, August 13, 2017 at 3:01:57 PM UTC+2, slawek wrote: > Asembler dobrych CPU ma cudeńka (rejestry wektorowe, rozszerzenia > instrukcji) normalnie nie używane przez kompilator. Właśnie, że normalnie używane przez kompilatory. Jest taki etap kompilacji "peep-hole optimization" - to w nim zastępuje się wzorce rozkazów innymi, szybszymi. To tylko kwestia bazy danych kompilator, co potrafi zmienić, a co nie. Co do rejestrów wektorowych, to googlaj za autovectorization. Parę lat temu ICC był w tym świetny, ale GCC i Clang już dawno dogoniły; nawet kompilator MSVC już wie, jak wektoryzować kod (znalazłem im buga z tym związanego, BTW). w.
[toc] | [prev] | [next] | [standalone]
| From | slawek <fake@fakeemail.com> |
|---|---|
| Date | 2017-08-16 20:28 +0200 |
| Message-ID | <almarsoft.4587980336867159797@news.v.pl> |
| In reply to | #30297 |
On Wed, 16 Aug 2017 09:47:15 -0700 (PDT), Wojciech Muła<wojtek.mula@gmail.com> wrote: > jak wektoryzować kod > (znalazłem im buga z tym związanego, BTW). I to zniechęca do kompilacji, a przynajmniej do kompilacji czymś skomplikowanym (C++). Co z tego że napiszesz coś ślicznie... że zwektoryzowane... jak kompilator będzie miał akurat "buga". Dlatego prymitywny Fortran jest tak lubiany. Bo jak coś było nie tak, to jakieś 60 lat było na poprawienie.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Bogusz <mabakay@o2.pl> |
|---|---|
| Date | 2017-08-16 20:35 +0200 |
| Message-ID | <on23a3$85s$1@node1.news.atman.pl> |
| In reply to | #30299 |
> Dlatego prymitywny Fortran jest tak lubiany. Bo jak coś było nie tak, to > jakieś 60 lat było na poprawienie. Dlatego 25 letnie samochody są tak lubiane. Bo jak coś było nie tak, to poprzedni właściciele mieli 25 lat na poprawienie ;-) - Pozdrawiam, Mateusz Bogusz
[toc] | [prev] | [next] | [standalone]
| From | slawek <fake@fakeemail.com> |
|---|---|
| Date | 2017-08-16 22:21 +0200 |
| Message-ID | <almarsoft.8418459625494275330@news.v.pl> |
| In reply to | #30300 |
On Wed, 16 Aug 2017 20:35:45 +0200, Mateusz Bogusz <mabakay@o2.pl> wrote: > Dlatego 25 letnie samochody są tak lubiane. Po pierwsze, gdybyś miał sprawny samochód sprzed 1914, to byłby on więcej dziś wart niż nówka sztuka jakiegoś byle czego. Po drugie, twierdzenie Pitagorasa jest starsze niż Fortran. A ciągle się go używa. Po trzecie, twój 15 letni samochód za rok będzie bardziej zużyty niż rok temu. Będzie gorzej jeździć i częściej się psuł. Natomiast kompilator którego używasz prawdopodobnie będzie nieco lepszy: być może naprawione błędy, być może lepsza optymalizacja, poprawiona zgodność ze standardem. Od tysiącleci młodych, gniewnych, rewolucjonistów podnieca że Wszechświat powstał wraz z ich narodzinami. Uważają to co było wcześniej za nic niewarte, a nawet szkodliwe. Fortran jest w twoim odczuciu szkodliwy, bo się spóźniłeś na czas gdy powstawał, gdy był modny. A przecież trzeba być postępowym, mieć najnowszego ajfona i programować w Rust. Cool. Luzik.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Bogusz <mabakay@o2.pl> |
|---|---|
| Date | 2017-08-18 18:46 +0200 |
| Message-ID | <on75ke$g4u$1@node2.news.atman.pl> |
| In reply to | #30306 |
> Po pierwsze, gdybyś miał sprawny samochód sprzed 1914, to byłby on > więcej dziś wart niż nówka sztuka jakiegoś byle czego. Dla kogoś pewnie i tak, to wtedy by kupił. > Po drugie, twierdzenie Pitagorasa jest starsze niż Fortran. A ciągle się > go używa. No właśnie. Używa wtedy kiedy potrzebne, a nie pieje że rozwiązuje wszystkie problemy. > Po trzecie, twój 15 letni samochód za rok będzie bardziej zużyty niż rok > temu. Będzie gorzej jeździć i częściej się psuł. Natomiast kompilator > którego używasz prawdopodobnie będzie nieco lepszy: być może naprawione > błędy, być może lepsza optymalizacja, poprawiona zgodność ze standardem. Z jeden strony piszesz, że kod ładnie "zwektoryzujesz", a z drugiej że dobre tylko kompilatory sprzed 30 lat. To jak Ty chcesz te nowoczesne instrukcje wykorzystać w Fortranie? -- Pozdrawiam, Mateusz Bogusz
[toc] | [prev] | [next] | [standalone]
| From | szykcech@gmail.com |
|---|---|
| Date | 2017-08-21 13:15 -0700 |
| Message-ID | <54fb9ebb-c35e-4ef8-877f-b5110e22bc70@googlegroups.com> |
| In reply to | #30365 |
Ja odnoszę wrażenie, że obecnie programiści nie za bardzo wiedzą jaki język jest na prawdę najlepszy i myślą, że w zasadzie to najbardziej zależy od zastosowania. Bo w większości wypadków nie ważne jest jak jest szybki - liczy się jak szybko da się coś zakodować. Ja natomiast mam inne zdanie na ten temat. Moim zdaniem (porównując najpopularniejsze języki: Asembler, C, C++, D, Java, PHP, Python, JavaScript - tyle poznałem i mi to wystarczy) okazuje się, że C++ jest najlepszy. Oto powody: 1. Bez udziwnień obsługuje standardowe API obecnych systemów operacyjnych (czyli C). D ma niby wsparcie dla funkcji C ale trzeba je zdeklarować w języku D. 2. Zapewnia wszystko to co język obiektowy powinien mieć - a nawet więcej niż wiele innych języków, bo ma wielodziedziczenie i szablony. I to wszystko ma bez udziwnień - są to cechy naturalne tego języka. Tak więc nie jest uczciwe porównywanie tego języka do Asemblera. Tu bym porównał raczej Asemblera do łopaty, a C++ do koparki, a języki skryptowe do mini koparek. 3. Kompiluje się do kodu maszynowego i przez to działa w sposób naturalny - jak to przewiduje producent procesora. Jego pliki wykonywalne są najmniejsze z możliwych, są prawie tak szybkie jak programy asemblerowe i działają samodzielnie (wymagając jedynie bibliotek dll - jeśli tak zostały skompilowane - a często wymaga tego licencja biblioteki). Nie wymaga żadnego interpretera, ani żadnych "maszyn wirtualnych" które nic nie dają prawdziwemu programiście (bo gdy do C++ przechodzi się z Asemblera to ręczne zarządzanie pamięcią jest czymś naturalnym i intuicyjnym - ja w ten sposób się uczyłem, bo to wydawało mi się najsensowniejsze i nadal tak mi się wydaje). Poza tym obecnie w C++ zarządzanie pamięcią często ogranicza się do podania "rodzica" jako parametr konstruktora i on usuwa ten nowy obiekt (Qt tak jest zrobione), lub używa się "sprytnych wskaźników" które usuną obiekt kiedy trzeba (to implementuje biblioteka standardowa). 4. Umożliwia dobrą separację interfejsu (deklaracji) i implementacji. Są pliki *.h które dobrze opisują zawartość plików *.cpp. To trzeba docenić, bo tego nie ma w innych (wymienionych) językach z wyjątkiem C. 5. Jest przenośny. Umiejętnie pisane programy (w Qt ;] ) są bez problemowo przenośne. A kod nieprzenośny daje się izolować (można wyłączać całe pliki *.cpp i kompilować warunkowo). Ta przenośność teoretycznie nie jest obarczona jakimś spadkiem wydajności czy innymi ukrytymi kosztami. Teoretycznie programy C++ są przenośne na każdą platformę na którą jest odpowiednio aktualny kompilator C++. Jednak ważniejszym ograniczeniem jest wsparcie danej platformy przez dostawców bibliotek. 6. C++ żyje własnym życiem bez dominacji jednej firmy która by narzucała innym jaki ten język ma być. Nie kompatybilne zmiany się nie przyjmują, bo ludzie chcą mieć wybór - np.: pod Windows kompilator VC++, a pod Linuxem g++...
[toc] | [prev] | [next] | [standalone]
Page 1 of 11 [1] 2 3 … 11 Next page →
Back to top | Article view | pl.comp.programming
csiph-web