Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #8592 > unrolled thread
| Started by | Lynn McGuire <lmc@winsim.com> |
|---|---|
| First post | 2011-08-09 11:03 -0500 |
| Last post | 2011-08-22 10:56 -0700 |
| Articles | 20 on this page of 119 — 22 participants |
Back to article view | Back to comp.lang.c++
maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-09 11:03 -0500
Re: maximum cases in a switch ? LR <lruss@superlink.net> - 2011-08-09 12:27 -0400
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-09 12:23 -0500
Re: maximum cases in a switch ? Joe Greer <jgreer@doubletake.com> - 2011-08-10 12:45 +0000
Re: maximum cases in a switch ? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-10 09:09 -0400
Re: maximum cases in a switch ? Joe Greer <jgreer@doubletake.com> - 2011-08-11 12:49 +0000
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-11 10:48 -0500
Re: maximum cases in a switch ? Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2011-08-11 18:26 +0200
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-11 11:45 -0500
Re: maximum cases in a switch ? Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2011-08-11 20:06 +0200
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-11 14:47 -0500
Re: maximum cases in a switch ? Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2011-08-11 22:32 +0200
Re: maximum cases in a switch ? gwowen <gwowen@gmail.com> - 2011-08-12 06:00 -0700
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-12 10:49 -0500
Re: maximum cases in a switch ? Joe Greer <jgreer@doubletake.com> - 2011-08-12 13:46 +0000
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-12 10:58 -0500
Re: maximum cases in a switch ? Joe Greer <jgreer@doubletake.com> - 2011-08-12 20:22 +0000
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-12 15:57 -0500
Re: maximum cases in a switch ? Leo Equinox Gaspard <ekinox1995@gmail.com> - 2011-08-13 20:58 +0200
Re: maximum cases in a switch ? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-13 18:16 -0400
Re: maximum cases in a switch ? Leo Equinox Gaspard <ekinox1995@gmail.com> - 2011-08-16 07:55 +0200
Re: maximum cases in a switch ? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-16 09:04 -0400
Re: maximum cases in a switch ? Leo Equinox Gaspard <ekinox1995@gmail.com> - 2011-08-17 00:11 +0200
Re: maximum cases in a switch ? Ian Collins <ian-news@hotmail.com> - 2011-08-17 10:24 +1200
Re: maximum cases in a switch ? Leo Equinox Gaspard <ekinox1995@gmail.com> - 2011-08-17 01:33 +0200
Re: maximum cases in a switch ? Leo Equinox Gaspard <ekinox1995@gmail.com> - 2011-08-17 00:18 +0200
Re: maximum cases in a switch ? Ian Collins <ian-news@hotmail.com> - 2011-08-17 10:29 +1200
Re: maximum cases in a switch ? Leo Equinox Gaspard <ekinox1995@gmail.com> - 2011-08-17 01:37 +0200
Re: maximum cases in a switch ? Ian Collins <ian-news@hotmail.com> - 2011-08-17 12:02 +1200
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-09 16:38 +0000
Re: maximum cases in a switch ? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-09 15:42 -0400
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-09 15:39 -0500
Re: maximum cases in a switch ? Leo Equinox Gaspard <ekinox1995@gmail.com> - 2011-08-09 23:39 +0200
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-09 17:18 -0500
Re: maximum cases in a switch ? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-09 20:06 -0400
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-10 06:54 +0000
Re: maximum cases in a switch ? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-08-10 12:20 +0000
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-10 11:34 -0500
Re: maximum cases in a switch ? Paul Brettschneider <paul.brettschneider@yahoo.fr> - 2011-08-10 20:34 +0200
Re: maximum cases in a switch ? Paul Brettschneider <paul.brettschneider@yahoo.fr> - 2011-08-10 21:06 +0200
Re: maximum cases in a switch ? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-08-11 21:00 +0000
Re: maximum cases in a switch ? Marcel Müller <news.5.maazl@spamgourmet.com> - 2011-08-10 11:10 +0200
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-10 10:40 +0000
Re: maximum cases in a switch ? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-10 09:02 -0400
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-11 08:05 +0000
Re: maximum cases in a switch ? Marcel Müller <news.5.maazl@spamgourmet.com> - 2011-08-10 21:17 +0200
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-10 11:12 -0500
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-11 11:07 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-13 00:14 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-13 14:54 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-13 15:26 +0100
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-14 18:14 +0000
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-15 01:09 +0100
Re: maximum cases in a switch ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-15 02:15 -0700
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-15 12:18 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-15 13:22 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-15 13:38 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-15 14:06 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-15 16:05 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-15 16:20 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-15 20:24 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-15 22:09 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-15 22:19 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-16 03:10 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-16 13:08 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-16 14:01 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-16 14:10 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-16 03:07 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-16 13:05 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-16 13:57 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-16 14:07 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-16 19:29 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-16 19:35 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 00:01 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-17 00:11 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 01:23 +0100
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-15 13:32 +0000
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-15 15:20 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-15 15:33 +0100
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-16 07:34 +0000
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-16 13:49 +0100
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-16 15:02 +0000
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-16 16:07 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-16 19:50 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-16 19:57 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 00:12 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-16 19:34 +0100
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-17 12:55 +0000
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 14:32 +0100
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-17 20:11 +0000
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-18 11:00 +0100
Re: maximum cases in a switch ? Joshua Maurice <joshuamaurice@gmail.com> - 2011-08-15 15:35 -0700
Re: maximum cases in a switch ? Gareth Owen <gwowen@gmail.com> - 2011-08-17 06:34 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 12:23 +0100
Re: maximum cases in a switch ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-17 02:01 -0700
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 12:29 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-17 14:13 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 14:18 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-17 14:43 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 15:23 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-17 15:31 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 15:48 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-17 15:53 +0100
Re: maximum cases in a switch ? SG <s.gesemann@gmail.com> - 2011-08-17 07:54 -0700
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 20:40 +0100
Re: maximum cases in a switch ? Larry Evans <cppljevans@suddenlink.net> - 2011-08-17 10:54 -0500
Re: maximum cases in a switch ? Robert Wessel <robertwessel2@yahoo.com> - 2011-08-17 12:44 -0500
jump table vs. vector of function pointers(was Re: maximum cases in a switch ? Larry Evans <cppljevans@suddenlink.net> - 2011-08-17 15:18 -0500
Re: jump table vs. vector of function pointers(was Re: maximum cases in a switch ? Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2011-08-17 22:48 +0200
Re: jump table vs. vector of function pointers(was Re: maximum cases in a switch ? Larry Evans <cppljevans@suddenlink.net> - 2011-08-17 16:49 -0500
Re: maximum cases in a switch ? Thomas David Rivers <rivers@dignus.com> - 2011-08-17 13:50 -0400
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 22:04 +0100
Re: maximum cases in a switch ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-22 03:23 -0700
Re: maximum cases in a switch ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-12 05:51 -0700
Re: maximum cases in a switch ? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-13 08:45 -0400
Re: maximum cases in a switch ? James Kanze <james.kanze@gmail.com> - 2011-08-21 16:55 -0700
Re: maximum cases in a switch ? Robert Wessel <robertwessel2@yahoo.com> - 2011-08-21 23:22 -0500
Re: maximum cases in a switch ? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-22 08:14 -0400
Re: maximum cases in a switch ? James Kanze <james.kanze@gmail.com> - 2011-08-22 10:56 -0700
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Leo Equinox Gaspard <ekinox1995@gmail.com> |
|---|---|
| Date | 2011-08-16 07:55 +0200 |
| Message-ID | <j2d0mi$qtn$1@dont-email.me> |
| In reply to | #8798 |
Le 14/08/2011 00:16, Victor Bazarov a écrit :
> On 8/13/2011 2:58 PM, Leo Equinox Gaspard wrote:
>> [..]
>> Some examples of POD and non-POD types :
>>
>> struct POD { int i; }; // Only POD members
>> struct NonPOD { int * p; }; // Pointer isn't POD
>
> Really? No, REALLY?!! Any proof (quote from the Standard, a book or some
> such)?
>
>>
>> [..]
>>
>> Now, am I mistaking anywhere ?
>
> I don't know. I stopped reading after you called a pointer non-POD...
>
>> [..]
>
> V
If you read the beginning before the code, you would have seen
" <<< Errors in, see after >>> " in my message, meaning that I knew I
was wrong.
My message was composed of two parts, one written using my memory (and,
while I
was saying a pointer wasn't POD, I was pretty sure of that, but I was wrong,
because, while pointers /often/ causes classes not to be POD, it's indeed
the classic use of them that is in cause : delete ptr_ in the
destructor), which
had been corrupted by time without checking the definition (last time I
heard of
PODs was at least one year ago).
The second part (starting by BTW) was written with the standard (more
precisely
the last freely available version of the C++11 standard), and declared
that I was
wrong. As I don't like the idea of removing something I wrote (maybe is
it because
I tend to act like if writing a letter), I decided to add these two
messages :
" <<< Errors in, see after >>> " and "Am I wrong anywhere ? <<< Yes, see
below >>> "
So, maybe, even not reading the whole message, but at least the
beginning before the
end, would help you to understand the true message I posted.
Leo
[toc] | [prev] | [next] | [standalone]
| From | Victor Bazarov <v.bazarov@comcast.invalid> |
|---|---|
| Date | 2011-08-16 09:04 -0400 |
| Message-ID | <j2dpt2$1h0$1@dont-email.me> |
| In reply to | #8886 |
On 8/16/2011 1:55 AM, Leo Equinox Gaspard wrote:
> Le 14/08/2011 00:16, Victor Bazarov a écrit :
>> On 8/13/2011 2:58 PM, Leo Equinox Gaspard wrote:
>>> [..]
>>> Some examples of POD and non-POD types :
>>>
>>> struct POD { int i; }; // Only POD members
>>> struct NonPOD { int * p; }; // Pointer isn't POD
>>
>> Really? No, REALLY?!! Any proof (quote from the Standard, a book or some
>> such)?
>>
>>>
>>> [..]
>>>
>>> Now, am I mistaking anywhere ?
>>
>> I don't know. I stopped reading after you called a pointer non-POD...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>> [..]
>>
>> V
>
> If you read the beginning before the code, you would have seen
> " <<< Errors in, see after >>> " in my message, meaning that I knew I
> was wrong.
Yes, if I read. I didn't. And I shouldn't have to. If you knew that
you were wrong, delete the text before posting and type in the correct
part. Better yet, reconsider posting. I understand that you might have
felt that since you spent time typing it, it was somehow worth
publishing (to offset the expense of typing it up). It wasn't. While
you did waste time (yours) typing nonsense, you wasted even more of it
(mine and others') by not removing the nonsense from your message before
posting the whole thing.
> My message was composed of two parts, one written using my memory (and,
> while I
> was saying a pointer wasn't POD, I was pretty sure of that, but I was
> wrong,
> because, while pointers /often/ causes classes not to be POD,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You keep doing that, don't you? Where do you get this nonsense? And if
you can't recognize it as nonsense, perhaps you should get into habit of
verifying everything that you're about to publish? Yes, we understand
that human memory is not perfect, but, man, if you know that yours is
especially vulnerable, stop relying on it.
> it's indeed
> the classic use of them that is in cause : delete ptr_ in the
> destructor), which
> had been corrupted by time without checking the definition (last time I
> heard of
> PODs was at least one year ago).
>
> The second part (starting by BTW) was written [..]
>
> So, maybe, even not reading the whole message, but at least the
> beginning before the
> end, would help you to understand the true message I posted.
No, sorry. It would not. Pure noise. Total waste of time.
V
--
I do not respond to top-posted replies, please don't ask
[toc] | [prev] | [next] | [standalone]
| From | Leo Equinox Gaspard <ekinox1995@gmail.com> |
|---|---|
| Date | 2011-08-17 00:11 +0200 |
| Message-ID | <j2eprp$7jo$1@dont-email.me> |
| In reply to | #8920 |
Le 16/08/2011 15:04, Victor Bazarov a écrit : > On 8/16/2011 1:55 AM, Leo Equinox Gaspard wrote: >> Le 14/08/2011 00:16, Victor Bazarov a écrit : [...] >> >> If you read the beginning before the code, you would have seen >> " <<< Errors in, see after >>> " in my message, meaning that I knew I >> was wrong. > > Yes, if I read. I didn't. And I shouldn't have to. You shouldn't have read the beginning before the end ? I hope you don't read books from the end to the beginning, otherwise you would hardly ever understand its content. > If you knew that you > were wrong, delete the text before posting and type in the correct part. > Better yet, reconsider posting. I understand that you might have felt > that since you spent time typing it, it was somehow worth publishing (to > offset the expense of typing it up). It wasn't. It was. I think it could be useful for others to know the error I did, for them not to do the same. >While you did waste time > (yours) typing nonsense, you wasted even more of it (mine and others') > by not removing the nonsense from your message before posting the whole > thing. I think the only waste of time here is this discussion we are having, as if you had only limited time you could just have jumped the whole "nonsense" to go directly to the interesting part. >> My message was composed of two parts, one written using my memory (and, >> while I >> was saying a pointer wasn't POD, I was pretty sure of that, but I was >> wrong, >> because, while pointers /often/ causes classes not to be POD, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > You keep doing that, don't you? Where do you get this nonsense? And if > you can't recognize it as nonsense, perhaps you should get into habit of > verifying everything that you're about to publish? Yes, we understand > that human memory is not perfect, but, man, if you know that yours is > especially vulnerable, stop relying on it. Maybe reading the end of the sentence before answering, it would help you not to write nonsense. Why don't you just read the end of the parenthesis ? "delete ptr_ in the destructor". And you couldn't say that a class having "delete ptr_" in the destructor isn't POD, as I state in my message, due to sections 9.10 and 9.6, stating that a POD is a trivial class, that a trivial class is trivially copyable, and that a trivially copyable class need a trivial destructor, which is not the case of a class containing "delete ptr_" in its destructor. >> it's indeed >> the classic use of them that is in cause : delete ptr_ in the >> destructor), which >> had been corrupted by time without checking the definition (last time I >> heard of >> PODs was at least one year ago). >> >> The second part (starting by BTW) was written [..] >> >> So, maybe, even not reading the whole message, but at least the >> beginning before the >> end, would help you to understand the true message I posted. > > No, sorry. It would not. Pure noise. Total waste of time. Leo
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-08-17 10:24 +1200 |
| Message-ID | <9b091fFgq5U8@mid.individual.net> |
| In reply to | #8955 |
On 08/17/11 10:11 AM, Leo Equinox Gaspard wrote: > Le 16/08/2011 15:04, Victor Bazarov a écrit : >> On 8/16/2011 1:55 AM, Leo Equinox Gaspard wrote: > >>> My message was composed of two parts, one written using my memory (and, >>> while I >>> was saying a pointer wasn't POD, I was pretty sure of that, but I was >>> wrong, >>> because, while pointers /often/ causes classes not to be POD, >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> You keep doing that, don't you? Where do you get this nonsense? And if >> you can't recognize it as nonsense, perhaps you should get into habit of >> verifying everything that you're about to publish? Yes, we understand >> that human memory is not perfect, but, man, if you know that yours is >> especially vulnerable, stop relying on it. > > Maybe reading the end of the sentence before answering, it would help you > not to write nonsense. Why don't you just read the end of the parenthesis ? > "delete ptr_ in the destructor". And you couldn't say that a class having > "delete ptr_" in the destructor isn't POD, as I state in my message, due to > sections 9.10 and 9.6, stating that a POD is a trivial class, that a trivial > class is trivially copyable, and that a trivially copyable class need a > trivial destructor, which is not the case of a class containing "delete > ptr_" in its destructor. A class isn't a POD if it has a destructor, trivial or not (9 pp4). -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Leo Equinox Gaspard <ekinox1995@gmail.com> |
|---|---|
| Date | 2011-08-17 01:33 +0200 |
| Message-ID | <j2eume$959$1@dont-email.me> |
| In reply to | #8957 |
Le 17/08/2011 00:24, Ian Collins a écrit : > On 08/17/11 10:11 AM, Leo Equinox Gaspard wrote: [...] > > A class isn't a POD if it has a destructor, trivial or not (9 pp4). > Excuse me, but ... On the version I am using, 9pp4 is about nonzero size for complete objects and member subobjects. Or maybe am I misunderstanding the "pp" part ? Leo
[toc] | [prev] | [next] | [standalone]
| From | Leo Equinox Gaspard <ekinox1995@gmail.com> |
|---|---|
| Date | 2011-08-17 00:18 +0200 |
| Message-ID | <j2eq99$7jo$2@dont-email.me> |
| In reply to | #8750 |
Le 12/08/2011 22:22, Joe Greer a écrit : > Lynn McGuire<lmc@winsim.com> wrote in news:j23ilq$3ro$1@dont-email.me: > > >> What is POD ? The data descriptors live the lifetime of >> the app and are built at compile time to save runtime. >> "Performance is a Feature" applies to all software: >> http://www.codinghorror.com/blog/2011/06/performance-is-a-feature.h >> tml >> >> I gained 100X in speed when I converted my app from >> smalltalk to C++ and do not intend to give it back over >> some language semantics. Besides that, the data descriptors >> are contained in almost 100 classes (this particular class >> is the biggest at 525) and changing this code would be >> un-needful. >> >> Please note that I got my original question answered and >> I really appreciate that. It means that my current data >> storage descriptor design is extensible and that meets my >> needs for now. >> >> Thanks, >> Lynn >> > > POD = Plain Old Data i.e. a struct or class with no special behavior in > the case. > > Only you know what your app needs to do. I am just exploring > possibilities that you can either use or reject as suits your needs. > > joe I already answered, but it looks like there had been a misunderstanding, so, in order to be nice, I will re-post with removing the useless parts. AFAIK a POD may have special behavior. I just checked the latest free paper about C++0x, and I saw this. (9.10) A POD struct is a class that is both a trivial class and a standard-layout class, and has no non-static data members of type non-POD struct, non-POD union (or arrays of such types). Similarly, a POD union is a union that is both a trivial class and a standard layout class, and has no non-static data members of type non-POD struct, non-POD union (or arrays of such types). A POD class is a class that is either a POD struct or a POD union. So, as we are speaking of POD classes, we need : - trivial - standard-layout - no non-static data members that are non-POD Now, trivial classes. (9.6) A trivial class is a class that has a trivial default constructor (12.1) and is trivially copyable. [Note: In particular, a trivially copyable class does not have virtual functions or virtual base classes. - end note] So, we need : - trivial default constructor - trivially copyable - no virtual functions - no virtual base classes - standard-layout - no non-static data members that are non-POD Now, trivially copyable. (9.6) A trivially copyable class is a class that: - has no non-trivial copy constructors (12.8), - has no non-trivial move constructors (12.8), - has no non-trivial copy assignment operators (13.5.3, 12.8), - has no non-trivial move assignment operators (13.5.3, 12.8), - has a trivial destructor (12.4). So, we need : - trivial default, copy and move constructors - trivial copy and move assignment operators - trivial destructor - no virtual functions, base classes - standard-layout - no non-static data members that are non-POD Now, standard-layout. (9.7) A standard-layout class is a class that: - has no non-static data members of type non-standard-layout class (or arrays of such types) or reference, - has no virtual functions (10.3) and no virtual base classes (10.1), - has the same access control (Clause 11) for all non-static data members, - has no non-standard-layout base classes, - either has no non-static data members in the most derived class and at most one base class with non-static data members, or has no base class with non-static data members, and - has no base classes of the same type as the first non-static data member. So, we need : - trivial default, copy and move constructors - trivial copy and move assignment operators - trivial destructor - no virtual functions, base classes - no non-static data members that are not standard-layout - no virtual functions, base classes - only one access control for all non-static data members - no non-standard-layout base classes - only one class in the hierarchy that has non-static data members - no base classes of the same type as the first non-static data member - no non-static data members that are non-POD Restrictions 3 and 5 are the same. Restriction 4 is a subset of restriction 10. So, we need : - trivial default, copy and move constructors - trivial copy and move assignment operators - trivial destructor - no virtual functions, base classes - only one access control for all non-static data members - no non-standard-layout base classes - only one class in the hierarchy that has non-static data members - no base classes of the same type as the first non-static data member - no non-static data members that are non-POD So, we can do anything we want with static members and member functions. Am I mistaking anywhere ? Cheers & hth, Leo
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-08-17 10:29 +1200 |
| Message-ID | <9b09agFgq5U9@mid.individual.net> |
| In reply to | #8956 |
On 08/17/11 10:18 AM, Leo Equinox Gaspard wrote: > > I already answered, but it looks like there had been a misunderstanding, so, > in order to be nice, I will re-post with removing the useless parts. > > AFAIK a POD may have special behavior. > > I just checked the latest free paper about C++0x, and I saw this. Check 9 pp4 in the 2003 standard and the third example in 9 pp10 in the new one. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Leo Equinox Gaspard <ekinox1995@gmail.com> |
|---|---|
| Date | 2011-08-17 01:37 +0200 |
| Message-ID | <j2euu2$aci$1@dont-email.me> |
| In reply to | #8958 |
Le 17/08/2011 00:29, Ian Collins a écrit : > On 08/17/11 10:18 AM, Leo Equinox Gaspard wrote: >> >> I already answered, but it looks like there had been a >> misunderstanding, so, >> in order to be nice, I will re-post with removing the useless parts. >> >> AFAIK a POD may have special behavior. >> >> I just checked the latest free paper about C++0x, and I saw this. > > Check 9 pp4 in the 2003 standard and the third example in 9 pp10 in the > new one. > Oh, I answered your first message without understanding that you were speaking of the 2003 standard. However, I think third example of 9pp10 implies the destructor's body, not shown here, is doing something. And I apologize for my message saying 9.6 in place of 9pp6. The standard's text is never mentioning the absence of destructors, but only the triviality of destructors. Leo
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-08-17 12:02 +1200 |
| Message-ID | <9b0eoeFlvbU1@mid.individual.net> |
| In reply to | #8963 |
On 08/17/11 11:37 AM, Leo Equinox Gaspard wrote: > Le 17/08/2011 00:29, Ian Collins a écrit : >> On 08/17/11 10:18 AM, Leo Equinox Gaspard wrote: >>> >>> I already answered, but it looks like there had been a >>> misunderstanding, so, >>> in order to be nice, I will re-post with removing the useless parts. >>> >>> AFAIK a POD may have special behavior. >>> >>> I just checked the latest free paper about C++0x, and I saw this. >> >> Check 9 pp4 in the 2003 standard and the third example in 9 pp10 in the >> new one. >> > > Oh, I answered your first message without understanding that you were > speaking of the 2003 standard. > However, I think third example of 9pp10 implies the destructor's body, > not shown here, is doing something. > > And I apologize for my message saying 9.6 in place of 9pp6. > > The standard's text is never mentioning the absence of destructors, but > only the triviality of destructors. > The wording has changed in the new standard, introducing trivial destructors. The 2003 version is clearer: "A POD-struct is an aggregate class that has no non-static data members of type non-POD-struct, non-POD-union (or array of such types) or reference, and has no user-defined copy assignment operator and no user-defined destructor." -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2011-08-09 16:38 +0000 |
| Message-ID | <4e416293$0$4385$7b1e8fa0@news.nbl.fi> |
| In reply to | #8592 |
Lynn McGuire <lmc@winsim.com> wrote: > Is there a maximum number of cases in a switch ? > I have a class with a method that now has 525 > cases in a switch and will probably double this > over the next couple of years. I can't find any stated upper limit in the standard. There probably isn't (except for the maximum value of the numerical type being used, of course). Individual compilers might impose a limit based on the memory usage that parsing a switch statement requires, but my guess is that this limit is probably very large.
[toc] | [prev] | [next] | [standalone]
| From | Victor Bazarov <v.bazarov@comcast.invalid> |
|---|---|
| Date | 2011-08-09 15:42 -0400 |
| Message-ID | <j1s2ja$iks$1@dont-email.me> |
| In reply to | #8592 |
On 8/9/2011 12:03 PM, Lynn McGuire wrote: > Is there a maximum number of cases in a switch ? > I have a class with a method that now has 525 > cases in a switch and will probably double this > over the next couple of years. You have your answer, I'm not going to repeat it. Remember that it's not normative, though. I have a different question. How easy do you think it is going to be to maintain the code with more than 1000 cases in a single switch statement? How easy is it to debug? Wouldn't it make sense, perhaps, to categorize your values and call different functions based on, say, ranges first and do further branching later in those functions, maybe? OK, OK, not /a/ question, but three. And a slightly different approach would be to implement handling of those ranges in an external module (dynamically loaded library, or "shared object" as they are known in another unixverse) which will register the range (or ranges) of values which it serves with its function[s], pointers to which you should keep while the module is loaded... Just thought I'd suggest that, maybe you find it useful. V -- I do not respond to top-posted replies, please don't ask
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lmc@winsim.com> |
|---|---|
| Date | 2011-08-09 15:39 -0500 |
| Message-ID | <j1s601$cj9$1@dont-email.me> |
| In reply to | #8602 |
On 8/9/2011 2:42 PM, Victor Bazarov wrote:
> On 8/9/2011 12:03 PM, Lynn McGuire wrote:
>> Is there a maximum number of cases in a switch ?
>> I have a class with a method that now has 525
>> cases in a switch and will probably double this
>> over the next couple of years.
>
> You have your answer, I'm not going to repeat it. Remember that it's not normative, though.
>
> I have a different question. How easy do you think it is going to be to maintain the code with more than 1000 cases in a single
> switch statement? How easy is it to debug? Wouldn't it make sense, perhaps, to categorize your values and call different functions
> based on, say, ranges first and do further branching later in those functions, maybe? OK, OK, not /a/ question, but three.
>
> And a slightly different approach would be to implement handling of those ranges in an external module (dynamically loaded library,
> or "shared object" as they are known in another unixverse) which will register the range (or ranges) of values which it serves with
> its function[s], pointers to which you should keep while the module is loaded... Just thought I'd suggest that, maybe you find it
> useful.
>
> V
Incredibly easy. Here is some of the method:
DataDescriptor aDD_GEN_CALVAPPRE (GEN_CALVAPPRE, "CALVAPPRE",
"Calculate Vapor Pressure for all streams", true, false, false,
SYM_Enumerated, nil, nil, nil, nil, nil, SYM_BOOLEAN,
SYM_DGenInit, 420, nil, nil);
DataDescriptor * GenGroup::descriptor (int aSymbol, int version)
{
switch (aSymbol)
{
case GEN_CALVAPPRE:
return & aDD_GEN_CALVAPPRE;
case GEN_CALSONVEL:
return & aDD_GEN_CALSONVEL;
case GEN_ONLYWRITESTREAMBOXONFIRSTSHEET:
return & aDD_GEN_ONLYWRITESTREAMBOXONFIRSTSHEET;
...
}
// default return
return NULL;
}
This is a 470,000 line C++ Win32 user interface for a highly
successful calculation engine. This code is bulletproof and
very extensible. This particular code was actually converted
from Smalltalk to C++ about 10 years ago.
Lynn
[toc] | [prev] | [next] | [standalone]
| From | Leo Equinox Gaspard <ekinox1995@gmail.com> |
|---|---|
| Date | 2011-08-09 23:39 +0200 |
| Message-ID | <j1s9d5$5g3$1@dont-email.me> |
| In reply to | #8603 |
> Incredibly easy. Here is some of the method:
>
> DataDescriptor aDD_GEN_CALVAPPRE (GEN_CALVAPPRE, "CALVAPPRE",
> "Calculate Vapor Pressure for all streams", true, false, false,
> SYM_Enumerated, nil, nil, nil, nil, nil, SYM_BOOLEAN,
> SYM_DGenInit, 420, nil, nil);
>
> DataDescriptor * GenGroup::descriptor (int aSymbol, int version)
> {
> switch (aSymbol)
> {
> case GEN_CALVAPPRE:
> return & aDD_GEN_CALVAPPRE;
> case GEN_CALSONVEL:
> return & aDD_GEN_CALSONVEL;
> case GEN_ONLYWRITESTREAMBOXONFIRSTSHEET:
> return & aDD_GEN_ONLYWRITESTREAMBOXONFIRSTSHEET;
> ...
> }
>
> // default return
> return NULL;
> }
>
> This is a 470,000 line C++ Win32 user interface for a highly
> successful calculation engine. This code is bulletproof and
> very extensible. This particular code was actually converted
> from Smalltalk to C++ about 10 years ago.
>
> Lynn
Oh my God.
You are laughing, isn't it ?
There is nothing about anything named calvappre on the internet.
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lmc@winsim.com> |
|---|---|
| Date | 2011-08-09 17:18 -0500 |
| Message-ID | <j1sbop$lne$1@dont-email.me> |
| In reply to | #8604 |
On 8/9/2011 4:39 PM, Leo Equinox Gaspard wrote:
>> Incredibly easy. Here is some of the method:
>>
>> DataDescriptor aDD_GEN_CALVAPPRE (GEN_CALVAPPRE, "CALVAPPRE",
>> "Calculate Vapor Pressure for all streams", true, false, false,
>> SYM_Enumerated, nil, nil, nil, nil, nil, SYM_BOOLEAN,
>> SYM_DGenInit, 420, nil, nil);
>>
>> DataDescriptor * GenGroup::descriptor (int aSymbol, int version)
>> {
>> switch (aSymbol)
>> {
>> case GEN_CALVAPPRE:
>> return & aDD_GEN_CALVAPPRE;
>> case GEN_CALSONVEL:
>> return & aDD_GEN_CALSONVEL;
>> case GEN_ONLYWRITESTREAMBOXONFIRSTSHEET:
>> return & aDD_GEN_ONLYWRITESTREAMBOXONFIRSTSHEET;
>> ...
>> }
>>
>> // default return
>> return NULL;
>> }
>>
>> This is a 470,000 line C++ Win32 user interface for a highly
>> successful calculation engine. This code is bulletproof and
>> very extensible. This particular code was actually converted
>> from Smalltalk to C++ about 10 years ago.
>>
>> Lynn
>
> Oh my God.
>
> You are laughing, isn't it ?
>
> There is nothing about anything named calvappre on the internet.
Try googling "cal vap pre". That is shorthand
in our internal engineering software language
for a specific calculation.
Lynn
[toc] | [prev] | [next] | [standalone]
| From | Victor Bazarov <v.bazarov@comcast.invalid> |
|---|---|
| Date | 2011-08-09 20:06 -0400 |
| Message-ID | <j1si27$ao$1@dont-email.me> |
| In reply to | #8603 |
On 8/9/2011 4:39 PM, Lynn McGuire wrote:
> On 8/9/2011 2:42 PM, Victor Bazarov wrote:
>> On 8/9/2011 12:03 PM, Lynn McGuire wrote:
>>> Is there a maximum number of cases in a switch ?
>>> I have a class with a method that now has 525
>>> cases in a switch and will probably double this
>>> over the next couple of years.
>>
>> You have your answer, I'm not going to repeat it. Remember that it's
>> not normative, though.
>>
>> I have a different question. How easy do you think it is going to be
>> to maintain the code with more than 1000 cases in a single
>> switch statement? How easy is it to debug? Wouldn't it make sense,
>> perhaps, to categorize your values and call different functions
>> based on, say, ranges first and do further branching later in those
>> functions, maybe? OK, OK, not /a/ question, but three.
>>
>> And a slightly different approach would be to implement handling of
>> those ranges in an external module (dynamically loaded library,
>> or "shared object" as they are known in another unixverse) which will
>> register the range (or ranges) of values which it serves with
>> its function[s], pointers to which you should keep while the module is
>> loaded... Just thought I'd suggest that, maybe you find it
>> useful.
>>
>> V
>
> Incredibly easy. Here is some of the method:
>
> DataDescriptor aDD_GEN_CALVAPPRE (GEN_CALVAPPRE, "CALVAPPRE",
> "Calculate Vapor Pressure for all streams", true, false, false,
> SYM_Enumerated, nil, nil, nil, nil, nil, SYM_BOOLEAN,
> SYM_DGenInit, 420, nil, nil);
>
> DataDescriptor * GenGroup::descriptor (int aSymbol, int version)
> {
> switch (aSymbol)
> {
> case GEN_CALVAPPRE:
> return & aDD_GEN_CALVAPPRE;
> case GEN_CALSONVEL:
> return & aDD_GEN_CALSONVEL;
> case GEN_ONLYWRITESTREAMBOXONFIRSTSHEET:
> return & aDD_GEN_ONLYWRITESTREAMBOXONFIRSTSHEET;
Ugh! You can do it with a macro
#define returnDDfor(A) case A: return & aDD_ ## A
and
returnDDfor(GEN_CALVAPPRE);
returnDDfor(GEN_CALSONVEL);
At least you need to type it only once...
I wonder, have you tried looking at the generated code? Does the
compiler have a jump table or does it create a bunch of 'if-then goto'
parts? The latter gets expensive for the case labels at the bottom of
the switch statement.
> ...
> }
>
> // default return
> return NULL;
> }
>
> This is a 470,000 line C++ Win32 user interface for a highly
> successful calculation engine. This code is bulletproof and
> very extensible. This particular code was actually converted
> from Smalltalk to C++ about 10 years ago.
>
> Lynn
V
--
I do not respond to top-posted replies, please don't ask
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2011-08-10 06:54 +0000 |
| Message-ID | <4e422b1d$0$3097$7b1e8fa0@news.nbl.fi> |
| In reply to | #8606 |
Victor Bazarov <v.bazarov@comcast.invalid> wrote: > I wonder, have you tried looking at the generated code? Does the > compiler have a jump table or does it create a bunch of 'if-then goto' > parts? The latter gets expensive for the case labels at the bottom of > the switch statement. One can generally assume that modern compilers are decently good at optimizing large switch blocks. (If a specific compiler isn't, chances are that it isn't good at optimizing anything else either.)
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2011-08-10 12:20 +0000 |
| Message-ID | <slrnj44tsp.gtj.grahn+nntp@frailea.sa.invalid> |
| In reply to | #8608 |
On Wed, 2011-08-10, Juha Nieminen wrote: > Victor Bazarov <v.bazarov@comcast.invalid> wrote: >> I wonder, have you tried looking at the generated code? Does the >> compiler have a jump table or does it create a bunch of 'if-then goto' >> parts? The latter gets expensive for the case labels at the bottom of >> the switch statement. > > One can generally assume that modern compilers are decently good at > optimizing large switch blocks. (If a specific compiler isn't, chances > are that it isn't good at optimizing anything else either.) With such an unusually large switch, I'd rather not assume anything. The price for being wrong could be high, like Victor said. I'd be interested to hear what the compiler generates in this case. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lmc@winsim.com> |
|---|---|
| Date | 2011-08-10 11:34 -0500 |
| Message-ID | <j1uc14$dvj$1@dont-email.me> |
| In reply to | #8619 |
On 8/10/2011 7:20 AM, Jorgen Grahn wrote:
> On Wed, 2011-08-10, Juha Nieminen wrote:
>> Victor Bazarov<v.bazarov@comcast.invalid> wrote:
>>> I wonder, have you tried looking at the generated code? Does the
>>> compiler have a jump table or does it create a bunch of 'if-then goto'
>>> parts? The latter gets expensive for the case labels at the bottom of
>>> the switch statement.
>>
>> One can generally assume that modern compilers are decently good at
>> optimizing large switch blocks. (If a specific compiler isn't, chances
>> are that it isn't good at optimizing anything else either.)
>
> With such an unusually large switch, I'd rather not assume anything.
> The price for being wrong could be high, like Victor said.
>
> I'd be interested to hear what the compiler generates in this case.
>
> /Jorgen
DataDescriptor * GenGroup::descriptor (int aSymbol, int version)
{
0075D5B0 push ebp
0075D5B1 mov ebp,esp
0075D5B3 sub esp,8
0075D5B6 mov dword ptr [ebp-4],ecx
switch (aSymbol)
0075D5B9 mov eax,dword ptr [aSymbol]
0075D5BC mov dword ptr [ebp-8],eax
0075D5BF cmp dword ptr [ebp-8],20Ch
0075D5C6 ja $LN1+7 (75EA22h)
0075D5CC mov ecx,dword ptr [ebp-8]
0075D5CF jmp dword ptr (75EA2Ch)[ecx*4]
{
case GEN_CALVAPPRE:
return & aDD_GEN_CALVAPPRE;
0075D5D6 mov eax,offset aDD_GEN_CALVAPPRE (0DA0080h)
0075D5DB jmp $LN1+9 (75EA24h)
case GEN_CALSONVEL:
return & aDD_GEN_CALSONVEL;
0075D5E0 mov eax,offset aDD_GEN_CALSONVEL (0D88908h)
0075D5E5 jmp $LN1+9 (75EA24h)
case GEN_ONLYWRITESTREAMBOXONFIRSTSHEET:
return & aDD_GEN_ONLYWRITESTREAMBOXONFIRSTSHEET;
0075D5EA mov eax,offset aDD_GEN_ONLYWRITESTREAMBOXONFIRSTSHEET (0D9C648h)
0075D5EF jmp $LN1+9 (75EA24h)
...
Lynn
[toc] | [prev] | [next] | [standalone]
| From | Paul Brettschneider <paul.brettschneider@yahoo.fr> |
|---|---|
| Date | 2011-08-10 20:34 +0200 |
| Message-ID | <d6793$4e42cf1c$506c0d9c$22664@news.chello.at> |
| In reply to | #8637 |
Lynn McGuire wrote:
> On 8/10/2011 7:20 AM, Jorgen Grahn wrote:
>> On Wed, 2011-08-10, Juha Nieminen wrote:
>>> Victor Bazarov<v.bazarov@comcast.invalid> wrote:
>>>> I wonder, have you tried looking at the generated code? Does the
>>>> compiler have a jump table or does it create a bunch of 'if-then goto'
>>>> parts? The latter gets expensive for the case labels at the bottom of
>>>> the switch statement.
>>>
>>> One can generally assume that modern compilers are decently good at
>>> optimizing large switch blocks. (If a specific compiler isn't, chances
>>> are that it isn't good at optimizing anything else either.)
>>
>> With such an unusually large switch, I'd rather not assume anything.
>> The price for being wrong could be high, like Victor said.
>>
>> I'd be interested to hear what the compiler generates in this case.
>>
>> /Jorgen
>
> DataDescriptor * GenGroup::descriptor (int aSymbol, int version)
> {
> 0075D5B0 push ebp
> 0075D5B1 mov ebp,esp
> 0075D5B3 sub esp,8
> 0075D5B6 mov dword ptr [ebp-4],ecx
> switch (aSymbol)
> 0075D5B9 mov eax,dword ptr [aSymbol]
> 0075D5BC mov dword ptr [ebp-8],eax
> 0075D5BF cmp dword ptr [ebp-8],20Ch
> 0075D5C6 ja $LN1+7 (75EA22h)
> 0075D5CC mov ecx,dword ptr [ebp-8]
> 0075D5CF jmp dword ptr (75EA2Ch)[ecx*4]
> {
> case GEN_CALVAPPRE:
> return & aDD_GEN_CALVAPPRE;
> 0075D5D6 mov eax,offset aDD_GEN_CALVAPPRE (0DA0080h)
> 0075D5DB jmp $LN1+9 (75EA24h)
> case GEN_CALSONVEL:
> return & aDD_GEN_CALSONVEL;
> 0075D5E0 mov eax,offset aDD_GEN_CALSONVEL (0D88908h)
> 0075D5E5 jmp $LN1+9 (75EA24h)
> case GEN_ONLYWRITESTREAMBOXONFIRSTSHEET:
> return & aDD_GEN_ONLYWRITESTREAMBOXONFIRSTSHEET;
> 0075D5EA mov eax,offset aDD_GEN_ONLYWRITESTREAMBOXONFIRSTSHEET
> (0D9C648h)
> 0075D5EF jmp $LN1+9 (75EA24h)
Silly compiler. It should store the return value directly in the table and
avoid the unnecessary jump. ;)
[toc] | [prev] | [next] | [standalone]
| From | Paul Brettschneider <paul.brettschneider@yahoo.fr> |
|---|---|
| Date | 2011-08-10 21:06 +0200 |
| Message-ID | <331db$4e42d6b3$506c0d9c$385@news.chello.at> |
| In reply to | #8642 |
Paul Brettschneider wrote:
> Lynn McGuire wrote:
>
>> On 8/10/2011 7:20 AM, Jorgen Grahn wrote:
>>> On Wed, 2011-08-10, Juha Nieminen wrote:
>>>> Victor Bazarov<v.bazarov@comcast.invalid> wrote:
>>>>> I wonder, have you tried looking at the generated code? Does the
>>>>> compiler have a jump table or does it create a bunch of 'if-then goto'
>>>>> parts? The latter gets expensive for the case labels at the bottom of
>>>>> the switch statement.
>>>>
>>>> One can generally assume that modern compilers are decently good at
>>>> optimizing large switch blocks. (If a specific compiler isn't, chances
>>>> are that it isn't good at optimizing anything else either.)
>>>
>>> With such an unusually large switch, I'd rather not assume anything.
>>> The price for being wrong could be high, like Victor said.
>>>
>>> I'd be interested to hear what the compiler generates in this case.
>>>
>>> /Jorgen
>>
>> DataDescriptor * GenGroup::descriptor (int aSymbol, int version)
>> {
>> 0075D5B0 push ebp
>> 0075D5B1 mov ebp,esp
>> 0075D5B3 sub esp,8
>> 0075D5B6 mov dword ptr [ebp-4],ecx
>> switch (aSymbol)
>> 0075D5B9 mov eax,dword ptr [aSymbol]
>> 0075D5BC mov dword ptr [ebp-8],eax
>> 0075D5BF cmp dword ptr [ebp-8],20Ch
>> 0075D5C6 ja $LN1+7 (75EA22h)
>> 0075D5CC mov ecx,dword ptr [ebp-8]
>> 0075D5CF jmp dword ptr (75EA2Ch)[ecx*4]
>> {
>> case GEN_CALVAPPRE:
>> return & aDD_GEN_CALVAPPRE;
>> 0075D5D6 mov eax,offset aDD_GEN_CALVAPPRE (0DA0080h)
>> 0075D5DB jmp $LN1+9 (75EA24h)
>> case GEN_CALSONVEL:
>> return & aDD_GEN_CALSONVEL;
>> 0075D5E0 mov eax,offset aDD_GEN_CALSONVEL (0D88908h)
>> 0075D5E5 jmp $LN1+9 (75EA24h)
>> case GEN_ONLYWRITESTREAMBOXONFIRSTSHEET:
>> return & aDD_GEN_ONLYWRITESTREAMBOXONFIRSTSHEET;
>> 0075D5EA mov eax,offset aDD_GEN_ONLYWRITESTREAMBOXONFIRSTSHEET
>> (0D9C648h)
>> 0075D5EF jmp $LN1+9 (75EA24h)
>
> Silly compiler. It should store the return value directly in the table and
> avoid the unnecessary jump. ;)
Actually g++ does just that, unless you have a special case/default label
which for example throws an exception. Weird.
Test code:
#include <iostream>
int main()
{
std::cout << "#include <stdexcept>\n"
<< "class X { int i; };\n";
for(int i = 0; i < 100; ++i) {
std::cout << "X x" << i << ";\n";
}
std::cout << "X &blah(int x)\n"
<< "{\n"
<< "\tswitch(x) {\n";
for(int i = 0; i < 100; ++i) {
std::cout << "\tcase " << i << ":"
<< " return x" << i << ";\n";
}
// Comment in default-label for code pessimisation
std::cout << "\t//default: throw std::runtime_error(\"Oh no!\");\n"
<< "\t}\n"
<< "\treturn x0;\n"
<< "}\n";
}
resulting "jump" table:
CSWTCH.1:
.long x0
.long x1
.long x2
.long x3
.long x4
.long x5
...
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web