Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #118653 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2024-04-04 20:11 +0200 |
| Last post | 2024-04-07 18:25 +0300 |
| Articles | 20 on this page of 90 — 10 participants |
Back to article view | Back to comp.lang.c++
Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-04 20:11 +0200
Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-04 21:55 +0300
Re: Ain't that beautiful ? Sam <sam@email-scan.com> - 2024-04-04 20:00 -0400
Re: Ain't that beautiful ? scott@slp53.sl.home (Scott Lurndal) - 2024-04-05 00:21 +0000
Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-05 17:44 +0300
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-05 17:27 +0200
Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-05 18:37 +0300
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-05 18:04 +0200
Re: Ain't that beautiful ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-06 15:55 -0700
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 08:28 +0200
Re: Ain't that beautiful ? scott@slp53.sl.home (Scott Lurndal) - 2024-04-07 15:51 +0000
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 19:35 +0200
Re: Ain't that beautiful ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-04-07 12:21 -0700
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-05 05:05 +0200
Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-05 17:52 +0300
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-05 17:26 +0200
Re: Ain't that beautiful ? scott@slp53.sl.home (Scott Lurndal) - 2024-04-05 20:00 +0000
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-05 22:29 +0200
Re: Ain't that beautiful ? scott@slp53.sl.home (Scott Lurndal) - 2024-04-05 21:29 +0000
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-06 09:06 +0200
Re: Ain't that beautiful ? Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-06 17:29 +0300
Re: Ain't that beautiful ? scott@slp53.sl.home (Scott Lurndal) - 2024-04-06 14:56 +0000
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-06 18:34 +0200
Re: Ain't that beautiful ? wij <wyniijj5@gmail.com> - 2024-04-07 03:00 +0800
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 08:28 +0200
Re: Ain't that beautiful ? wij <wyniijj5@gmail.com> - 2024-04-08 07:47 +0800
Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-07 15:25 +0300
Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-07 16:00 +0300
Re: Ain't that beautiful ? David Brown <david.brown@hesbynett.no> - 2024-04-07 16:06 +0200
Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-07 18:37 +0300
Re: Ain't that beautiful ? scott@slp53.sl.home (Scott Lurndal) - 2024-04-07 15:58 +0000
Re: Ain't that beautiful ? David Brown <david.brown@hesbynett.no> - 2024-04-07 18:00 +0200
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 19:38 +0200
std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-07 18:38 +0300
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-07 18:06 +0200
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-07 19:35 +0300
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-08 11:29 +0200
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-08 13:34 +0300
Re: std::map advocacy wij <wyniijj5@gmail.com> - 2024-04-08 19:18 +0800
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-08 16:32 +0300
Re: std::map advocacy wij <wyniijj5@gmail.com> - 2024-04-09 08:40 +0800
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 12:48 +0300
Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-09 13:16 +0200
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-08 15:30 +0200
Re: std::map advocacy scott@slp53.sl.home (Scott Lurndal) - 2024-04-08 17:19 +0000
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 00:47 +0300
Re: std::map advocacy scott@slp53.sl.home (Scott Lurndal) - 2024-04-08 23:00 +0000
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 02:20 +0300
Re: std::map advocacy scott@slp53.sl.home (Scott Lurndal) - 2024-04-09 15:22 +0000
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-09 09:11 +0200
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 13:12 +0300
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-09 15:01 +0200
Re: std::map advocacy Richard Damon <richard@damon-family.org> - 2024-04-08 07:10 -0400
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-08 15:45 +0200
Re: std::map advocacy James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-04-08 19:42 -0400
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-09 09:45 +0200
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 13:27 +0300
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-09 15:13 +0200
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 18:12 +0300
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-09 18:22 +0200
Re: std::map advocacy James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-04-10 02:24 -0400
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-11 00:07 +0300
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-11 16:18 +0300
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-11 16:39 +0300
Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-11 16:21 +0200
Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-11 15:31 +0200
Re: std::map advocacy wij <wyniijj5@gmail.com> - 2024-04-11 22:40 +0800
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-11 16:55 +0200
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-11 16:13 +0300
Re: std::map advocacy Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-11 18:18 +0300
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-11 09:57 +0200
Re: std::map advocacy David Brown <david.brown@hesbynett.no> - 2024-04-11 13:47 +0200
Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-11 14:04 +0200
Re: std::map advocacy wij <wyniijj5@gmail.com> - 2024-04-11 19:25 +0800
Re: std::map advocacy scott@slp53.sl.home (Scott Lurndal) - 2024-04-07 16:09 +0000
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-07 19:48 +0300
Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 19:45 +0200
Re: std::map advocacy Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-08 16:37 +0300
Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 19:44 +0200
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-08 11:15 +0300
Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-08 14:09 +0200
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-08 16:26 +0300
Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-08 16:54 +0200
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-08 20:52 +0300
Re: std::map advocacy Michael S <already5chosen@yahoo.com> - 2024-04-09 00:17 +0300
Re: std::map advocacy Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-09 07:34 +0200
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 16:39 +0200
Re: Ain't that beautiful ? Michael S <already5chosen@yahoo.com> - 2024-04-07 18:41 +0300
Re: Ain't that beautiful ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-07 19:36 +0200
Re: Ain't that beautiful ? Paavo Helde <eesnimi@osa.pri.ee> - 2024-04-07 18:25 +0300
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-04-06 17:29 +0300 |
| Message-ID | <uurm8q$24ka4$1@dont-email.me> |
| In reply to | #118667 |
06.04.2024 00:29 Scott Lurndal kirjutas: > > Most of C++ is useless cruft with a significant run-time > performance hit. > > Classes are genuinely useful, as are namespaces. So are standard containers, like std::vector and std::map. No run-time performance hits compared to equivalent solutions in C. So are templates. No run-time performance hits. Template syntax, while horrible, is still more readable/maintainable than equivalent C macros. For me, also exceptions are genuinely useful. In C code with adequate error checking, half of the code deals with the error paths, and useful error messages are often still lacking. YMMV. I agree that iostreams are pretty useless and have significant run-time performance hits. But iostreams do not make up most of C++. Still, the best feature of C++ is RAII (zero run-time performance hit).
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-04-06 14:56 +0000 |
| Message-ID | <dodQN.493622$yEgf.114692@fx09.iad> |
| In reply to | #118669 |
Paavo Helde <eesnimi@osa.pri.ee> writes: >06.04.2024 00:29 Scott Lurndal kirjutas: >> >> Most of C++ is useless cruft with a significant run-time >> performance hit. >> >> Classes are genuinely useful, as are namespaces. > >So are standard containers, like std::vector and std::map. No run-time >performance hits compared to equivalent solutions in C. For the most part true of std::vector. Not necessarily for std::map. > >So are templates. No run-time performance hits. Template syntax, while >horrible, is still more readable/maintainable than equivalent C macros. Poorly used, templates increase the code footprint, sometimes considerably - often just to avoid a couple of conditionals in the code. > >For me, also exceptions are genuinely useful. In C code with adequate >error checking, half of the code deals with the error paths, and useful >error messages are often still lacking. YMMV. There is a definite run-time cost to using exceptions. And some C++ code (operating systems, hypervisors) don't have the run-time infrastructure to support exception handling and stack unwinding. > >I agree that iostreams are pretty useless and have significant run-time >performance hits. But iostreams do not make up most of C++. > >Still, the best feature of C++ is RAII (zero run-time performance hit). Useful, but can easily be abused (e.g. for locking).
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-04-06 18:34 +0200 |
| Message-ID | <uurtih$26abt$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118670 |
Am 06.04.2024 um 16:56 schrieb Scott Lurndal: > For the most part true of std::vector. Not necessarily for > std::map. Show me a better key-value data structure when you also need to iterate through the KVs in sorting order. > Poorly used, templates increase the code footprint, ... They're fast and the code-foooprint may not be tolerable only on very small systems. > There is a definite run-time cost to using exceptions. And some > C++ code (operating systems, hypervisors) don't have the > run-time infrastructure to support exception handling and stack > unwinding. Then don't throw exceptions through that foreign code. I'm often using lambdas without captures as callbacks to C-interfaces with Win32. With these callback's I can't use exceptions but that's not a problem. > Useful, but can easily be abused (e.g. for locking). Ok, "can be abused", then drop it ! ;-)
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-04-07 03:00 +0800 |
| Message-ID | <daec0e1e768af35c82b6528119b8fc7385c780b2.camel@gmail.com> |
| In reply to | #118671 |
On Sat, 2024-04-06 at 18:34 +0200, Bonita Montero wrote: > Am 06.04.2024 um 16:56 schrieb Scott Lurndal: > > > For the most part true of std::vector. Not necessarily for > > std::map. > I estimate ::hsearch(...) is about 20 times faster than std::map, that says it all, although the key is limited to c-string. > Show me a better key-value data structure when you > also need to iterate through the KVs in sorting order. > > > Poorly used, templates increase the code footprint, ... > > They're fast and the code-foooprint may not be tolerable only on very > small systems. > One of the worst part of C++ is memory consumption, compared with C. Let's say C program can solve problems of size X, C++ normally solves of size X/2. This is equivalent to time performance in larger size. > > There is a definite run-time cost to using exceptions. And some > > C++ code (operating systems, hypervisors) don't have the > > run-time infrastructure to support exception handling and stack > > unwinding. > > Then don't throw exceptions through that foreign code. I'm often using > lambdas without captures as callbacks to C-interfaces with Win32. With > these callback's I can't use exceptions but that's not a problem. > The problem of 'throw' is context-loss and time cost. For context-loss, you generally won't be able to have library-level reusable codes. 'Throw' is normally one thousand times slower than return, this part is, generally speaking, doomed. The problem of std::exception family is simply unnecessarily complex. > > Useful, but can easily be abused (e.g. for locking). > > Ok, "can be abused", then drop it ! ;-) > >
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-04-07 08:28 +0200 |
| Message-ID | <uutedl$2kq8k$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118672 |
Am 06.04.2024 um 21:00 schrieb wij: > On Sat, 2024-04-06 at 18:34 +0200, Bonita Montero wrote: >> Am 06.04.2024 um 16:56 schrieb Scott Lurndal: >> >>> For the most part true of std::vector. Not necessarily for >>> std::map. >> > I estimate ::hsearch(...) is about 20 times faster than std::map, that says it all, > although the key is limited to c-string. A tree is slow, but if you need to iterate with key order there's nothing faster. Hash-maps are O(1) are faster but you can't traverse the KVs in key-order. > >> Show me a better key-value data structure when you >> also need to iterate through the KVs in sorting order. >> >>> Poorly used, templates increase the code footprint, ... >> >> They're fast and the code-foooprint may not be tolerable only on very >> small systems. >> > > One of the worst part of C++ is memory consumption, compared with C. C++ is not known for its bad memory consumption. > Let's say C program can solve problems of size X, C++ normally solves of size X/2. > This is equivalent to time performance in larger size. > >>> There is a definite run-time cost to using exceptions. And some >>> C++ code (operating systems, hypervisors) don't have the >>> run-time infrastructure to support exception handling and stack >>> unwinding. >> >> Then don't throw exceptions through that foreign code. I'm often using >> lambdas without captures as callbacks to C-interfaces with Win32. With >> these callback's I can't use exceptions but that's not a problem. >> > > The problem of 'throw' is context-loss and time cost. For context-loss, you generally > won't be able to have library-level reusable codes. 'Throw' is normally one thousand > times slower than return, this part is, generally speaking, doomed. Exceptions are only thrown in exceptional cases like I/O-errors or a memory collapse. That happens very rarely and performance of thrown exceptions doens't count. > > The problem of std::exception family is simply unnecessarily complex. > >>> Useful, but can easily be abused (e.g. for locking). >> >> Ok, "can be abused", then drop it ! ;-) >> >> > >
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-04-08 07:47 +0800 |
| Message-ID | <10734958976ed3ce8ea3a9c8c4a7ece9be334efb.camel@gmail.com> |
| In reply to | #118674 |
On Sun, 2024-04-07 at 08:28 +0200, Bonita Montero wrote: > Am 06.04.2024 um 21:00 schrieb wij: > > On Sat, 2024-04-06 at 18:34 +0200, Bonita Montero wrote: > > > Am 06.04.2024 um 16:56 schrieb Scott Lurndal: > > > > > > > For the most part true of std::vector. Not necessarily for > > > > std::map. > > > > > I estimate ::hsearch(...) is about 20 times faster than std::map, that says it all, > > although the key is limited to c-string. > > > A tree is slow, but if you need to iterate with key order there's > nothing faster. Hash-maps are O(1) are faster but you can't traverse > the KVs in key-order. > > > > > > Show me a better key-value data structure when you > > > also need to iterate through the KVs in sorting order. > > > > > > > Poorly used, templates increase the code footprint, ... > > > > > > They're fast and the code-foooprint may not be tolerable only on very > > > small systems. > > > > > > > One of the worst part of C++ is memory consumption, compared with C. > > C++ is not known for its bad memory consumption. > > > Let's say C program can solve problems of size X, C++ normally solves of size X/2. > > This is equivalent to time performance in larger size. > > > > > > There is a definite run-time cost to using exceptions. And some > > > > C++ code (operating systems, hypervisors) don't have the > > > > run-time infrastructure to support exception handling and stack > > > > unwinding. > > > > > > Then don't throw exceptions through that foreign code. I'm often using > > > lambdas without captures as callbacks to C-interfaces with Win32. With > > > these callback's I can't use exceptions but that's not a problem. > > > > > > > The problem of 'throw' is context-loss and time cost. For context-loss, you generally > > won't be able to have library-level reusable codes. 'Throw' is normally one thousand > > times slower than return, this part is, generally speaking, doomed. > > Exceptions are only thrown in exceptional cases like I/O-errors or a > memory collapse. That happens very rarely and performance of thrown > exceptions doens't count. > Don't be that exclusive. Throwing error is not that bad. Throwing error is like setting global errno and executing 'soft' assertion failure. > > > > The problem of std::exception family is simply unnecessarily complex. > > > > > > Useful, but can easily be abused (e.g. for locking). > > > > > > Ok, "can be abused", then drop it ! ;-) > > > > > > > > > > >
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-04-07 15:25 +0300 |
| Message-ID | <20240407152541.00005236@yahoo.com> |
| In reply to | #118670 |
On Sat, 06 Apr 2024 14:56:09 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Paavo Helde <eesnimi@osa.pri.ee> writes: > >06.04.2024 00:29 Scott Lurndal kirjutas: > >> > >> Most of C++ is useless cruft with a significant run-time > >> performance hit. > >> > >> Classes are genuinely useful, as are namespaces. > > > >So are standard containers, like std::vector and std::map. No > >run-time performance hits compared to equivalent solutions in C. > > For the most part true of std::vector. Not necessarily for > std::map. > IMHO, std::map is a very good default choice when you start coding and don't know yet if key-value store is going to be big or small, predominantly read or with significant updating, performance critical or not and in need of ordering or there would never be such need. Of course, normally you figure the part about the need of ordering quite quickly, but sweeping std::map with std:unordered_map is not hard. The nice thing about std::map is that it's pretty much always within factor of 10 from the absolutely best custom data structure, both in memory consumption and in speed, so the choice std::map cam be wrong, but unlikely to be critically wrong.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-04-07 16:00 +0300 |
| Message-ID | <20240407160050.00004370@yahoo.com> |
| In reply to | #118669 |
On Sat, 6 Apr 2024 17:29:45 +0300
Paavo Helde <eesnimi@osa.pri.ee> wrote:
>
> run-time performance hits. But iostreams do not make up most of C++.
>
> Still, the best feature of C++ is RAII (zero run-time performance
> hit).
>
RAII has low run-time cost, although I doubt that it's really zero.
RAII has non-trivial code size cost, esp. when used a lot. See below.
But my main objection with RAII is that I feel like loosing track.
Simple test:
------ foo.cpp
void* allocate_bar(int x);
void free_bar(void* bar);
int foo_bar(void* bar);
int foo(int x)
{
void* bar = allocate_bar(x);
if (bar) {
int ret = foo_bar(bar);
free_bar(bar);
return ret;
}
return -1;
}
------ end of foo.cpp
------ raii-foo.cpp
void* allocate_bar(int x);
void free_bar(void* bar);
int foo_bar(void* bar);
class raii_bar {
public:
void* p;
raii_bar(int x) {
p = allocate_bar(x);
}
~raii_bar() {
if (p)
free_bar(p);
}
};
int foo(int x)
{
raii_bar bar(x);
if (bar.p)
return foo_bar(bar.p);
return -1;
}
------ end of raii-foo.cpp
$ gcc -c -Wall -O2 foo.cpp raii-foo.cpp
$ size *.o
text data bss dec hex filename
136 0 0 136 88 foo.o
172 0 0 172 ac raii-foo.o
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-04-07 16:06 +0200 |
| Message-ID | <uuu98b$2qou0$1@dont-email.me> |
| In reply to | #118677 |
On 07/04/2024 15:00, Michael S wrote: > On Sat, 6 Apr 2024 17:29:45 +0300 > Paavo Helde <eesnimi@osa.pri.ee> wrote: >> >> run-time performance hits. But iostreams do not make up most of C++. >> >> Still, the best feature of C++ is RAII (zero run-time performance >> hit). >> > > RAII has low run-time cost, although I doubt that it's really zero. > RAII has non-trivial code size cost, esp. when used a lot. See below. > But my main objection with RAII is that I feel like loosing track. > > $ gcc -c -Wall -O2 foo.cpp raii-foo.cpp > $ size *.o > text data bss dec hex filename > 136 0 0 136 88 foo.o > 172 0 0 172 ac raii-foo.o > You will almost certainly find that the overhead here is due to exception handling and/or RTTI. Add the flag "-fno-execptions -fno-rtti", and you'll see the same code generated using <https://godbolt.org>. For some kinds of code (such as the stuff Scott does, and the stuff I do), exceptions are an unacceptable overhead, cost and complication in a language. Many other features of C++ - including RAII, templates, classes, namespaces, strong enums, overloading, concepts, constexpr, inline variables, smart pointers, and countless other bits and pieces can be used to get better source code (clearer, simpler, more flexible, safer, etc.) without inefficiency overheads compared to similar solutions in C. Different people have different needs from C++, and use different features. If I were programming on a PC, I'd happily use std::map<> and the like. But I don't program on PC's, and I don't use std::map<>. If I needed something like that, I'd make my own class that fitted my requirements tightly - a factor of 10 inefficiency is often fine on big systems, but not on the devices I work with. But that's all fine - use whatever you find useful from the language.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-04-07 18:37 +0300 |
| Message-ID | <20240407183728.00000ac4@yahoo.com> |
| In reply to | #118678 |
On Sun, 7 Apr 2024 16:06:02 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 07/04/2024 15:00, Michael S wrote: > > On Sat, 6 Apr 2024 17:29:45 +0300 > > Paavo Helde <eesnimi@osa.pri.ee> wrote: > >> > >> run-time performance hits. But iostreams do not make up most of > >> C++. > >> > >> Still, the best feature of C++ is RAII (zero run-time performance > >> hit). > >> > > > > RAII has low run-time cost, although I doubt that it's really zero. > > RAII has non-trivial code size cost, esp. when used a lot. See > > below. But my main objection with RAII is that I feel like loosing > > track. > > > $ gcc -c -Wall -O2 foo.cpp raii-foo.cpp > > $ size *.o > > text data bss dec hex filename > > 136 0 0 136 88 foo.o > > 172 0 0 172 ac raii-foo.o > > > > You will almost certainly find that the overhead here is due to > exception handling and/or RTTI. Add the flag "-fno-execptions > -fno-rtti", and you'll see the same code generated using > <https://godbolt.org>. Of course, it is due to exception! But isn't exception safety the main point behind RAII? RTTI plays no role here. Is not RTTI supported only for classes with virtual functions? > > For some kinds of code (such as the stuff Scott does, and the stuff I > do), exceptions are an unacceptable overhead, cost and complication > in a language. Many other features of C++ - including RAII, > templates, classes, namespaces, strong enums, overloading, concepts, > constexpr, inline variables, smart pointers, and countless other bits > and pieces can be used to get better source code (clearer, simpler, > more flexible, safer, etc.) without inefficiency overheads compared > to similar solutions in C. > I am not a fan of smart pointers. The other thing you mentioned can help sometimes, but also can make a mess of your codebase. And I had seen the later more often than the former. In particular, classes with big number of members are used by lazy programmers to have what is in effect global variables without feeling guilty.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-04-07 15:58 +0000 |
| Message-ID | <fozQN.166157$46Te.114095@fx38.iad> |
| In reply to | #118681 |
Michael S <already5chosen@yahoo.com> writes: >On Sun, 7 Apr 2024 16:06:02 +0200 >David Brown <david.brown@hesbynett.no> wrote: > >> On 07/04/2024 15:00, Michael S wrote: >> > On Sat, 6 Apr 2024 17:29:45 +0300 >> > Paavo Helde <eesnimi@osa.pri.ee> wrote: >> >> >> > RAII has low run-time cost, although I doubt that it's really zero. >> > RAII has non-trivial code size cost, esp. when used a lot. See >> > below. But my main objection with RAII is that I feel like loosing >> > track. >> >> > $ gcc -c -Wall -O2 foo.cpp raii-foo.cpp >> > $ size *.o >> > text data bss dec hex filename >> > 136 0 0 136 88 foo.o >> > 172 0 0 172 ac raii-foo.o >> > >> >> You will almost certainly find that the overhead here is due to >> exception handling and/or RTTI. Add the flag "-fno-execptions >> -fno-rtti", and you'll see the same code generated using >> <https://godbolt.org>. > >Of course, it is due to exception! >But isn't exception safety the main point behind RAII? Not necessarily. We used RAII (perhaps before it was called such) in 1989, in cfront 2.1 (exceptions didn't appear until 3.0) as a way to bail (return) from a long function (a kernel implementation of fork) and automatically deallocate various system resources (assigned credentials, memory map/pt, new process attributes, process-id, session/process group associations, etc) that had been allocated before the fork failure was detected. > >RTTI plays no role here. >Is not RTTI supported only for classes with virtual functions? dynamic_cast requires RTTI. > >> >> For some kinds of code (such as the stuff Scott does, and the stuff I >> do), exceptions are an unacceptable overhead, cost and complication >> in a language. Many other features of C++ - including RAII, >> templates, classes, namespaces, strong enums, overloading, concepts, >> constexpr, inline variables, smart pointers, and countless other bits >> and pieces can be used to get better source code (clearer, simpler, >> more flexible, safer, etc.) without inefficiency overheads compared >> to similar solutions in C. >> > >I am not a fan of smart pointers. Concur.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-04-07 18:00 +0200 |
| Message-ID | <uuufuu$2s7td$1@dont-email.me> |
| In reply to | #118681 |
On 07/04/2024 17:37, Michael S wrote: > On Sun, 7 Apr 2024 16:06:02 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 07/04/2024 15:00, Michael S wrote: >>> On Sat, 6 Apr 2024 17:29:45 +0300 >>> Paavo Helde <eesnimi@osa.pri.ee> wrote: >>>> >>>> run-time performance hits. But iostreams do not make up most of >>>> C++. >>>> >>>> Still, the best feature of C++ is RAII (zero run-time performance >>>> hit). >>>> >>> >>> RAII has low run-time cost, although I doubt that it's really zero. >>> RAII has non-trivial code size cost, esp. when used a lot. See >>> below. But my main objection with RAII is that I feel like loosing >>> track. >> >>> $ gcc -c -Wall -O2 foo.cpp raii-foo.cpp >>> $ size *.o >>> text data bss dec hex filename >>> 136 0 0 136 88 foo.o >>> 172 0 0 172 ac raii-foo.o >>> >> >> You will almost certainly find that the overhead here is due to >> exception handling and/or RTTI. Add the flag "-fno-execptions >> -fno-rtti", and you'll see the same code generated using >> <https://godbolt.org>. > > Of course, it is due to exception! > But isn't exception safety the main point behind RAII? > Not at all! RAII is about encapsulating an acquire-release pair in a manner that makes it easy to get right, and hard to get wrong, while minimising the boiler-plate code needed at the time of use. It's convenience for use with exceptions is almost completely incidental - as demonstrated by its usefulness when exceptions are not used (many C++ users don't use exceptions, and for a lot of use-cases, particularly embedded uses or safety or reliability critical code, exceptions are totally banned), and also by languages that have exceptions but not RAII. RAII is neither sufficient nor necessary for exception safety, but it certainly makes exception safety easier. > RTTI plays no role here. True - but RTTI goes along with exceptions as being a part of C++ that adds overhead. If you don't use the information, it is generally just wasted code space, rather than run time inefficiency, but for resource limited systems, that's a relevant issue. > Is not RTTI supported only for classes with virtual functions? No, it gets used for dynamic casts, and for identifying the class of a thrown exception. (At least, I think that's true - wait for others to either correct me or confirm this before believing it!) > >> >> For some kinds of code (such as the stuff Scott does, and the stuff I >> do), exceptions are an unacceptable overhead, cost and complication >> in a language. Many other features of C++ - including RAII, >> templates, classes, namespaces, strong enums, overloading, concepts, >> constexpr, inline variables, smart pointers, and countless other bits >> and pieces can be used to get better source code (clearer, simpler, >> more flexible, safer, etc.) without inefficiency overheads compared >> to similar solutions in C. >> > > I am not a fan of smart pointers. Nobody likes /everything/ in C++ ! > The other thing you mentioned can help sometimes, but also can make > a mess of your codebase. And I had seen the later more often than the > former. With great power, comes great responsibility - that's why we fear it :-) Useful tools for writing better code can also be used to mess things up in new and imaginative ways. > In particular, classes with big number of members are used by lazy > programmers to have what is in effect global variables without feeling > guilty. >
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-04-07 19:38 +0200 |
| Message-ID | <uuuln6$2tk05$3@raubtier-asyl.eternal-september.org> |
| In reply to | #118681 |
Am 07.04.2024 um 17:37 schrieb Michael S: > RTTI plays no role here. > Is not RTTI supported only for classes with virtual functions? Destructors may be virutal but while unwinding the type of the destructed object is known so ther's no need to call the destructor virtually. > In particular, classes with big number of members are used by lazy > programmers to have what is in effect global variables without feeling > guilty. This may apply to static methods only.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-04-07 18:38 +0300 |
| Subject | std::map advocacy |
| Message-ID | <20240407183854.00000797@yahoo.com> |
| In reply to | #118678 |
On Sun, 7 Apr 2024 16:06:02 +0200 David Brown <david.brown@hesbynett.no> wrote: > > Different people have different needs from C++, and use different > features. If I were programming on a PC, I'd happily use std::map<> > and the like. But I don't program on PC's, and I don't use > std::map<>. If I needed something like that, I'd make my own class > that fitted my requirements tightly - a factor of 10 inefficiency is > often fine on big systems, but not on the devices I work with. > > But that's all fine - use whatever you find useful from the language. > > Factor of 5-10 (mentioned in my other post) is quite rare and mostly applies not to std::map vs custom implementation of RB or AVL tree, but to std::map vs some form of hash, esp. when the nature of the key is such that relatively simple hash function happens to have good collision avoidance properties and when the database is huge, so O(1) vs O(logN) starts to be significant. Also pay attention that in situations where you do a lot of insertions and deletions, and especially of deletions followed by insertions, std::map::extract() could be of great help in reducing a cost of memory allocation/delallocation to necessary minimum. It's relatively new addition to std::map (C++17) and I'd guess that many C++ programmers are not aware of its existence. In my recent experience (I was implementing median filter over window of few 1000s values), a use of extract() made clean and simple std::map-based solution (well, actually std::multiset in this particular case, but the same principles applies to std::set/multiset/amp/multymap) faster than relatively more complicated code based on boost:intrusive:map. In this case I happened to have enough time to rewrite it in C with my own implementation of AVL tree. My own code was only some 10 or 15% faster than std container's. And it took more than a day (may be more than two days? I don't remember) to write and to debug. And that's for me, who knows the algorithm (from TAoCP) for more than 40 years. For somebody else it could easily take a weak. In short, std::map and relatives is quite good piece of work. Highly recommended. Consider me fan. At the end in particular case of my unusually long median filter, it turned out that AVL or RB tree is not the best structure for the job. A couple of other structures (heap and tournament tree) work better. But they don't work much better, only by factor of ~2.5. However both heap and tournament tree are far less generically applicable data structures than AVL/RB tree. They just happened to be better in this quite special case.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-04-07 18:06 +0200 |
| Subject | Re: std::map advocacy |
| Message-ID | <uuuga5$2s7td$2@dont-email.me> |
| In reply to | #118682 |
On 07/04/2024 17:38, Michael S wrote: > On Sun, 7 Apr 2024 16:06:02 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> >> Different people have different needs from C++, and use different >> features. If I were programming on a PC, I'd happily use std::map<> >> and the like. But I don't program on PC's, and I don't use >> std::map<>. If I needed something like that, I'd make my own class >> that fitted my requirements tightly - a factor of 10 inefficiency is >> often fine on big systems, but not on the devices I work with. >> >> But that's all fine - use whatever you find useful from the language. >> >> > > Factor of 5-10 (mentioned in my other post) is quite rare and mostly > applies not to std::map vs custom implementation of RB or AVL tree, but > to std::map vs some form of hash, esp. when the nature of the key is > such that relatively simple hash function happens to have good > collision avoidance properties and when the database is huge, so O(1) > vs O(logN) starts to be significant. > Sure. But remember, for small embedded systems you don't have dynamic memory - or if you do, you use it in limited and tightly controlled manner. And in a real-time system, it is the worst-case time that matters, unlike PC's where you are generally looking for average or amortized times. So a data structure which allocates and deallocates memory unpredictably, can use complex tree structures with little control of their worst-case times - no thanks! (And again, that does not mean these containers are not great choices for all kinds of other uses.) > Also pay attention that in situations where you do a lot of insertions > and deletions, and especially of deletions followed by insertions, > std::map::extract() could be of great help in reducing a cost of memory > allocation/delallocation to necessary minimum. It's relatively new > addition to std::map (C++17) and I'd guess that many C++ programmers > are not aware of its existence. > > In my recent experience (I was implementing median filter over window > of few 1000s values), a use of extract() made clean and simple > std::map-based solution (well, actually std::multiset in this > particular case, but the same principles applies to > std::set/multiset/amp/multymap) faster than relatively more complicated > code based on boost:intrusive:map. > > In this case I happened to have enough time to rewrite it in C with > my own implementation of AVL tree. My own code was only some 10 or > 15% faster than std container's. And it took more than a day (may be > more than two days? I don't remember) to write and to debug. And that's > for me, who knows the algorithm (from TAoCP) for more than 40 years. > For somebody else it could easily take a weak. > In short, std::map and relatives is quite good piece of work. > Highly recommended. Consider me fan. > > At the end in particular case of my unusually long median filter, it > turned out that AVL or RB tree is not the best structure for the job. A > couple of other structures (heap and tournament tree) work better. But > they don't work much better, only by factor of ~2.5. However both heap > and tournament tree are far less generically applicable data structures > than AVL/RB tree. They just happened to be better in this quite > special case. > >
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-04-07 19:35 +0300 |
| Subject | Re: std::map advocacy |
| Message-ID | <20240407193505.00004d17@yahoo.com> |
| In reply to | #118687 |
On Sun, 7 Apr 2024 18:06:29 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 07/04/2024 17:38, Michael S wrote: > > On Sun, 7 Apr 2024 16:06:02 +0200 > > David Brown <david.brown@hesbynett.no> wrote: > > > >> > >> Different people have different needs from C++, and use different > >> features. If I were programming on a PC, I'd happily use > >> std::map<> and the like. But I don't program on PC's, and I don't > >> use std::map<>. If I needed something like that, I'd make my own > >> class that fitted my requirements tightly - a factor of 10 > >> inefficiency is often fine on big systems, but not on the devices > >> I work with. > >> > >> But that's all fine - use whatever you find useful from the > >> language. > >> > >> > > > > Factor of 5-10 (mentioned in my other post) is quite rare and mostly > > applies not to std::map vs custom implementation of RB or AVL tree, > > but to std::map vs some form of hash, esp. when the nature of the > > key is such that relatively simple hash function happens to have > > good collision avoidance properties and when the database is huge, > > so O(1) vs O(logN) starts to be significant. > > > > Sure. > > But remember, for small embedded systems you don't have dynamic > memory - or if you do, you use it in limited and tightly controlled > manner. And in a real-time system, it is the worst-case time that > matters, unlike PC's where you are generally looking for average or > amortized times. So a data structure which allocates and deallocates > memory unpredictably, can use complex tree structures with little > control of their worst-case times - no thanks! As said in post above, in C++17 when the max size of map is known during initialization, allocation and de-allocation can be solved by std::map:extract in the same manner you do it for simpler containers: you push the required number of nodes into std::map then immediately extract and store in the simple structure, typically managed like a stack, but probably not using std::stack. Then during main runtime, in very typical "embedded" manner, you pop nodes that you want to insert from stack and push extracted nodes back to stack. No malloc, no free. It was possibly to achieve similar effect before C++17 as well, but it required use of custom allocators which are, IMHO, too hard to use. > > (And again, that does not mean these containers are not great choices > for all kinds of other uses.) > Partially balanced binary trees, like those used by std::map and by its relatives, are among the most predictable data structures out here. Certainly they are far more predictable than generic hash that in the worst case degenerates into O(N). OTOH, in std::map of given size the difference in worst access time between perfectly balanced case and most unbalanced case is only 2x. And that applies not just for lookup, but for insertion and deletion as well.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-04-08 11:29 +0200 |
| Subject | Re: std::map advocacy |
| Message-ID | <uv0dd7$3diif$1@dont-email.me> |
| In reply to | #118689 |
On 07/04/2024 18:35, Michael S wrote: > Partially balanced binary trees, like those used by std::map and by its > relatives, are among the most predictable data structures out here. > Certainly they are far more predictable than generic hash that in the > worst case degenerates into O(N). > OTOH, in std::map of given size the difference in worst access time > between perfectly balanced case and most unbalanced case is only > 2x. And that applies not just for lookup, but for insertion and > deletion as well. > As far as I know, details of how containers such as std::map are implemented are left to the implementation - they are not guaranteed by the standards. Different types of systems have different needs. C++ supports a huge range of uses, and for some of them, many parts of the standard library are simply out of the question. The point was just that claims such as Bonita's that "it is impossible to use C++ without exception[s]", or that if you don't use the standard library you are "missing most of C++", are just ignorant nonsense. People can choose what they need based on a range of requirements and preferences, and that's exactly what we want from a general-purpose language.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-04-08 13:34 +0300 |
| Subject | Re: std::map advocacy |
| Message-ID | <20240408133457.000005a9@yahoo.com> |
| In reply to | #118699 |
On Mon, 8 Apr 2024 11:29:11 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 07/04/2024 18:35, Michael S wrote: > > > Partially balanced binary trees, like those used by std::map and by > > its relatives, are among the most predictable data structures out > > here. Certainly they are far more predictable than generic hash > > that in the worst case degenerates into O(N). > > OTOH, in std::map of given size the difference in worst access time > > between perfectly balanced case and most unbalanced case is only > > 2x. And that applies not just for lookup, but for insertion and > > deletion as well. > > > > As far as I know, details of how containers such as std::map are > implemented are left to the implementation - they are not guaranteed > by the standards. > > Different types of systems have different needs. C++ supports a huge > range of uses, and for some of them, many parts of the standard > library are simply out of the question. The point was just that > claims such as Bonita's that "it is impossible to use C++ without > exception[s]", or that if you don't use the standard library you are > "missing most of C++", are just ignorant nonsense. People can choose > what they need based on a range of requirements and preferences, and > that's exactly what we want from a general-purpose language. > My opinion about standard library is very close to that Bonita, even if possibly possibly for the opposite reasons. IMHO, if you can't make good use of either C++ Standard library or of the other key feature of the language - virtual functions, then it is wiser to avoid C++ altogether. BTW, I *don't* use C++ on small embedded targets. More so, I don't use it on moderately-sized embedded targets, say, 8-16 MB of RAM, 100-200 MHz CPU, but without protected memory and without full-featured OS. My reasons are more psychological/managerial than technical - to keep away developers with wrong mindsets and to prevent those that I can't keep away from turning wrongest parts of their mindsets to full volume.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-04-08 19:18 +0800 |
| Subject | Re: std::map advocacy |
| Message-ID | <1bed53172895b75b7233785a3657cc938b2756dd.camel@gmail.com> |
| In reply to | #118700 |
On Mon, 2024-04-08 at 13:34 +0300, Michael S wrote: > On Mon, 8 Apr 2024 11:29:11 +0200 > David Brown <david.brown@hesbynett.no> wrote: > > > On 07/04/2024 18:35, Michael S wrote: > > > > > Partially balanced binary trees, like those used by std::map and by > > > its relatives, are among the most predictable data structures out > > > here. Certainly they are far more predictable than generic hash > > > that in the worst case degenerates into O(N). > > > OTOH, in std::map of given size the difference in worst access time > > > between perfectly balanced case and most unbalanced case is only > > > 2x. And that applies not just for lookup, but for insertion and > > > deletion as well. > > > > > > > As far as I know, details of how containers such as std::map are > > implemented are left to the implementation - they are not guaranteed > > by the standards. > > > > Different types of systems have different needs. C++ supports a huge > > range of uses, and for some of them, many parts of the standard > > library are simply out of the question. The point was just that > > claims such as Bonita's that "it is impossible to use C++ without > > exception[s]", or that if you don't use the standard library you are > > "missing most of C++", are just ignorant nonsense. People can choose > > what they need based on a range of requirements and preferences, and > > that's exactly what we want from a general-purpose language. > > > > My opinion about standard library is very close to that Bonita, even if > possibly possibly for the opposite reasons. > IMHO, if you can't make good use of either C++ Standard library or of > the other key feature of the language - virtual functions, then it is > wiser to avoid C++ altogether. I would say that maybe you don't know how to use C++ effectively. Ex1: I use my own C++ library (based on Clib), burden (learning, remembering,...) is super low. all that user need to know are very reusable (c++ std-library has lots of things to learn that are only meaningful in that library). E.g. my 'filesystem' is based on file descriptor, I don't think what in the std c++ lib can beat mine (except it considers lots more usage environments). Ex2: Qt is the software I admired since learn C++. It does not use std c++ library. > BTW, I *don't* use C++ on small embedded targets. More so, I don't use > it on moderately-sized embedded targets, say, 8-16 MB of RAM, 100-200 > MHz CPU, but without protected memory and without full-featured OS. > My reasons are more psychological/managerial than technical - to keep > away developers with wrong mindsets and to prevent those that I can't > keep away from turning wrongest parts of their mindsets to full volume. > > > >
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-04-08 16:32 +0300 |
| Subject | Re: std::map advocacy |
| Message-ID | <20240408163240.00004137@yahoo.com> |
| In reply to | #118702 |
On Mon, 08 Apr 2024 19:18:06 +0800 wij <wyniijj5@gmail.com> wrote: > > I would say that maybe you don't know how to use C++ effectively. > It is possible. But more likely that relatively to you I have longer experience in C++ and better understanding of both advantages and disadvantages.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web