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

Groups > comp.lang.c > #72672 > unrolled thread

Error handling in a parser (return value or setjmp)

Back to article view | Back to comp.lang.c

Contents

  Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 04:33 +0200
    Re: Error handling in a parser (return value or setjmp) Ian Collins <ian-news@hotmail.com> - 2015-10-13 15:54 +1300
      Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 05:07 +0200
    Re: Error handling in a parser (return value or setjmp) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-13 14:07 +0100
      Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 16:17 +0200
      Re: Error handling in a parser (return value or setjmp) supercat@casperkitty.com - 2015-10-13 08:26 -0700
        Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 18:14 +0200
          Re: Error handling in a parser (return value or setjmp) Ian Collins <ian-news@hotmail.com> - 2015-10-14 07:46 +1300
            Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 22:06 +0200
              Re: Error handling in a parser (return value or setjmp) Ian Collins <ian-news@hotmail.com> - 2015-10-14 10:32 +1300
                Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 23:47 +0200
                  Re: Error handling in a parser (return value or setjmp) Ian Collins <ian-news@hotmail.com> - 2015-10-14 11:02 +1300
                  Re: Error handling in a parser (return value or setjmp) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-14 18:32 +0000
                    Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-15 12:28 +0200
                      Re: Error handling in a parser (return value or setjmp) Ian Collins <ian-news@hotmail.com> - 2015-10-16 07:47 +1300
              Re: Error handling in a parser (return value or setjmp) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-13 21:39 +0000
                Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 23:49 +0200
                  Re: Error handling in a parser (return value or setjmp) supercat@casperkitty.com - 2015-10-13 15:03 -0700
                    Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-14 01:16 +0200
                      Re: Error handling in a parser (return value or setjmp) Geoff <geoff@invalid.invalid> - 2015-10-13 16:46 -0700
                        Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-14 02:13 +0200
                          Re: Error handling in a parser (return value or setjmp) Geoff <geoff@invalid.invalid> - 2015-10-13 19:10 -0700
                            Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-14 04:27 +0200
                              Re: Error handling in a parser (return value or setjmp) Ian Collins <ian-news@hotmail.com> - 2015-10-14 16:05 +1300
                                Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-14 05:18 +0200
                                  Re: Error handling in a parser (return value or setjmp) Ian Collins <ian-news@hotmail.com> - 2015-10-14 16:31 +1300
                                    Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-14 05:44 +0200
                              Re: Error handling in a parser (return value or setjmp) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-15 12:06 +0000
                                Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-15 16:08 +0200
                      Re: Error handling in a parser (return value or setjmp) supercat@casperkitty.com - 2015-10-14 00:36 -0700
                        Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-15 12:32 +0200
                  Re: Error handling in a parser (return value or setjmp) Ian Collins <ian-news@hotmail.com> - 2015-10-14 11:06 +1300
                  Re: Error handling in a parser (return value or setjmp) David Brown <david.brown@hesbynett.no> - 2015-10-14 00:10 +0200
                  Re: Error handling in a parser (return value or setjmp) James Kuyper <jameskuyper@verizon.net> - 2015-10-13 19:08 -0400
                Re: Error handling in a parser (return value or setjmp) raltbos@xs4all.nl (Richard Bos) - 2015-10-14 11:37 +0000
                  Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-15 12:34 +0200
                    Re: Error handling in a parser (return value or setjmp) Ian Collins <ian-news@hotmail.com> - 2015-10-16 07:56 +1300
                      Re: Error handling in a parser (return value or setjmp) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-16 05:45 +0200
              Re: Error handling in a parser (return value or setjmp) James Kuyper <jameskuyper@verizon.net> - 2015-10-13 18:53 -0400

Page 2 of 2 — ← Prev page 1 [2]

#72762

On 14.10.2015 01:46, Geoff wrote:
> On Wed, 14 Oct 2015 01:16:49 +0200, "Morten W. Petersen"
> <morphex@gmail.com> wrote:
>
>>
>> My understanding is that a multi-threaded program has access to the same
>> memory, so each thread has to have its state stored in the same global
>> variable.  And that's done using the thread id?
>>
>
> All of this is completely irrelevant until you have a version of your
> existing code that doesn't seg-fault at the outset.

Mhm.  Well last time I ran it, it worked OK and it works OK now too.

But are you saying that you can tell me what order I should do things
in and how I should work?

-Morten

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

#72774

On Wed, 14 Oct 2015 02:13:14 +0200, "Morten W. Petersen"
<morphex@gmail.com> wrote:

>On 14.10.2015 01:46, Geoff wrote:
>> On Wed, 14 Oct 2015 01:16:49 +0200, "Morten W. Petersen"
>> <morphex@gmail.com> wrote:
>>
>>>
>>> My understanding is that a multi-threaded program has access to the same
>>> memory, so each thread has to have its state stored in the same global
>>> variable.  And that's done using the thread id?
>>>
>>
>> All of this is completely irrelevant until you have a version of your
>> existing code that doesn't seg-fault at the outset.
>
>Mhm.  Well last time I ran it, it worked OK and it works OK now too.
>
>But are you saying that you can tell me what order I should do things
>in and how I should work?
>

Learn to walk before you try to jump the high hurdles. If you can't
find the source of a seg-fault in a single-thread how do you expect to
handle multi-threading? 

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

#72777

On 14.10.2015 04:10, Geoff wrote:
> On Wed, 14 Oct 2015 02:13:14 +0200, "Morten W. Petersen"
> <morphex@gmail.com> wrote:
>
>> On 14.10.2015 01:46, Geoff wrote:
>>> On Wed, 14 Oct 2015 01:16:49 +0200, "Morten W. Petersen"
>>> <morphex@gmail.com> wrote:
>>>
>>>>
>>>> My understanding is that a multi-threaded program has access to the same
>>>> memory, so each thread has to have its state stored in the same global
>>>> variable.  And that's done using the thread id?
>>>>
>>>
>>> All of this is completely irrelevant until you have a version of your
>>> existing code that doesn't seg-fault at the outset.
>>
>> Mhm.  Well last time I ran it, it worked OK and it works OK now too.
>>
>> But are you saying that you can tell me what order I should do things
>> in and how I should work?
>>
>
> Learn to walk before you try to jump the high hurdles. If you can't
> find the source of a seg-fault in a single-thread how do you expect to
> handle multi-threading?

It's about planning ahead and making less work for myself.  There are
different styles to working, mine works for me.

For example the discussion about exception handling and error codes
are useful, because I can now define FAIL as a macro which can do the
right thing later.  But more importantly, I design the code around it
so that if it is a return or a longjmp, it doesn't matter.

As for threading, it is also something that has to be taken into
account, and I'm already designing the main parser loop so that
threading can be plugged in there.  I know now that using pthreads
and a specific exception library looks like a good idea, and that's
nice to know, before I decide on ways to deal with errors and
choose something I'll end up typing a lot of characters to change.

I guess coming from Python I'm taking a more high-level approach
than what might be the norm.

-Morten

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

#72788

Morten W. Petersen wrote:

> It's about planning ahead and making less work for myself.  There are
> different styles to working, mine works for me.

http://martinfowler.com/bliki/Yagni.html

> As for threading, it is also something that has to be taken into
> account, and I'm already designing the main parser loop so that
> threading can be plugged in there.  I know now that using pthreads
> and a specific exception library looks like a good idea, and that's
> nice to know, before I decide on ways to deal with errors and
> choose something I'll end up typing a lot of characters to change.

All of the research backed by my own testing shows that threading 
doesn't really have a place in XML parsing.  The housekeeping overheads 
dominate.

-- 
Ian Collins

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

#72792

On 14.10.2015 05:05, Ian Collins wrote:
> Morten W. Petersen wrote:
>
>> It's about planning ahead and making less work for myself.  There are
>> different styles to working, mine works for me.
>
> http://martinfowler.com/bliki/Yagni.html
>
>> As for threading, it is also something that has to be taken into
>> account, and I'm already designing the main parser loop so that
>> threading can be plugged in there.  I know now that using pthreads
>> and a specific exception library looks like a good idea, and that's
>> nice to know, before I decide on ways to deal with errors and
>> choose something I'll end up typing a lot of characters to change.
>
> All of the research backed by my own testing shows that threading
> doesn't really have a place in XML parsing.  The housekeeping overheads
> dominate.

OK.  What are the housekeeping overheads?

Right now there might not be much use for the threading in my library
either.

But maybe I move the Unicode validation into the main parsing loop,
maybe make some changes here and there.

The sets of characters that make up the "main" markup are very
limited and can be checked for, then the rest offloaded to a
function that might be threaded.  What I need is really a super
simple threading library that can be handed a function and finish
it, and maybe I need a counter for active threads.  That's it.

Yes, if I was working for a customer, I wouldn't even be doing
this in C because I don't know C that well yet.  But I'm the
"customer" here, and the customer says it is OK to explore and
optimize for speed rather than buy some extra CPU cycles for
example.

-Morten

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

#72794

Morten W. Petersen wrote:
> On 14.10.2015 05:05, Ian Collins wrote:
>> Morten W. Petersen wrote:
>>
>>> It's about planning ahead and making less work for myself.  There are
>>> different styles to working, mine works for me.
>>
>> http://martinfowler.com/bliki/Yagni.html
>>
>>> As for threading, it is also something that has to be taken into
>>> account, and I'm already designing the main parser loop so that
>>> threading can be plugged in there.  I know now that using pthreads
>>> and a specific exception library looks like a good idea, and that's
>>> nice to know, before I decide on ways to deal with errors and
>>> choose something I'll end up typing a lot of characters to change.
>>
>> All of the research backed by my own testing shows that threading
>> doesn't really have a place in XML parsing.  The housekeeping overheads
>> dominate.
>
> OK.  What are the housekeeping overheads?

Many, but mainly context switching and synchronising the output of the 
threads.  Are you building a DOM?  If so you would have tn make access 
to it thread safe which will incur a cost.

> Right now there might not be much use for the threading in my library
> either.
>
> But maybe I move the Unicode validation into the main parsing loop,
> maybe make some changes here and there.
>
> The sets of characters that make up the "main" markup are very
> limited and can be checked for, then the rest offloaded to a
> function that might be threaded.  What I need is really a super
> simple threading library that can be handed a function and finish
> it, and maybe I need a counter for active threads.  That's it.

Even with a simple thread pool, you still have devise a synchronising 
mechanism to had over work and receive processed data.  You also have to 
accept the overhead of context switching.  Simple and threading don't 
normally appear in the same sentence!

-- 
Ian Collins

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

#72796

On 14.10.2015 05:31, Ian Collins wrote:
> Morten W. Petersen wrote:
>> On 14.10.2015 05:05, Ian Collins wrote:
>>> Morten W. Petersen wrote:
>>>
>>>> It's about planning ahead and making less work for myself.  There are
>>>> different styles to working, mine works for me.
>>>
>>> http://martinfowler.com/bliki/Yagni.html
>>>
>>>> As for threading, it is also something that has to be taken into
>>>> account, and I'm already designing the main parser loop so that
>>>> threading can be plugged in there.  I know now that using pthreads
>>>> and a specific exception library looks like a good idea, and that's
>>>> nice to know, before I decide on ways to deal with errors and
>>>> choose something I'll end up typing a lot of characters to change.
>>>
>>> All of the research backed by my own testing shows that threading
>>> doesn't really have a place in XML parsing.  The housekeeping overheads
>>> dominate.
>>
>> OK.  What are the housekeeping overheads?
>
> Many, but mainly context switching and synchronising the output of the
> threads.  Are you building a DOM?  If so you would have tn make access
> to it thread safe which will incur a cost.

There will be some way to access the internal data yes, what way that
will be I'm not sure of.  If it's going to be plugged into Firefox
for example, it will have to have some DOM support.

>> Right now there might not be much use for the threading in my library
>> either.
>>
>> But maybe I move the Unicode validation into the main parsing loop,
>> maybe make some changes here and there.
>>
>> The sets of characters that make up the "main" markup are very
>> limited and can be checked for, then the rest offloaded to a
>> function that might be threaded.  What I need is really a super
>> simple threading library that can be handed a function and finish
>> it, and maybe I need a counter for active threads.  That's it.
>
> Even with a simple thread pool, you still have devise a synchronising
> mechanism to had over work and receive processed data.  You also have to
> accept the overhead of context switching.  Simple and threading don't
> normally appear in the same sentence!

OK.  Well, lets say there is a main parser loop that iterates over the
data.  This is one thread.  It is very simple and hands over tasks to
the worker thread as soon as it can.

Then you have a third, validation thread, that checks that end tags
match, because the worker thread can't be guaranteed to finish before
the main parser loop finds the end tag.

It's not easy, but it is doable.  And it's acceptable, because the
point is to parse as fast as possible, and indicate an error, while
other tools can be used to get more meaningful feedback to fix the XML
if it is broken.

As for having a synchronized state, after the main parser loop finishes,
the program will wait for the worker and validation threads to finish.

An XML document that has been parsed and is in sync, can then be made
available to for example a DOM tool.

-Morten

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

#72941

On Wed, 2015-10-14, Morten W. Petersen wrote:
> On 14.10.2015 04:10, Geoff wrote:
>> On Wed, 14 Oct 2015 02:13:14 +0200, "Morten W. Petersen"
...

>>> But are you saying that you can tell me what order I should do things
>>> in and how I should work?
>>
>> Learn to walk before you try to jump the high hurdles. If you can't
>> find the source of a seg-fault in a single-thread how do you expect to
>> handle multi-threading?
>
> It's about planning ahead and making less work for myself.  There are
> different styles to working, mine works for me.
>
> For example the discussion about exception handling and error codes
> are useful, because I can now define FAIL as a macro which can do the
> right thing later.  But more importantly, I design the code around it
> so that if it is a return or a longjmp, it doesn't matter.

Hm, error handling strategy doesn't seem like something that can
safely be abstracted away. That's what makes it so tricky, and the
reason many languages include exceptions (which make it easier, but
still tricky).

> As for threading, it is also something that has to be taken into
> account, and I'm already designing the main parser loop so that
> threading can be plugged in there.

I never understood what role threading would have?  If it's for
performance -- parsing XML faster -- you can be almost certain
that for all users (a) it's fast enough already on one CPU and (b)
if it's not, it's I/O bound so using more CPUs won't help.

If you just want to respect a user's choice to use threading in her
code, the right solution is just to avoid things that would break
threading.

It would probably be enough that you could promise that different
parser objects can be used from different thread contexts, but warn
people not to access one object from multiple threads unless they add
some locking.

> I know now that using pthreads and a specific exception library
> looks like a good idea,

I think several of us stated that both sound like really bad ideas.

> and that's nice to know, before I decide on ways to deal with
> errors and choose something I'll end up typing a lot of characters
> to change.
>
> I guess coming from Python I'm taking a more high-level approach
> than what might be the norm.

I have used C++ and Python quite a lot, and I think it has affected my
C code.  Mostly in how I try to make my code stay close to the problem
domain and not be swamped in details -- I want to separate the
essential solution to the problem from the not so interesting details.

So yes, I think that high-level thinking is a good thing in general,
but for some things the high-level view does not help.  Especially not
with C.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#72952

On 15.10.2015 14:06, Jorgen Grahn wrote:
> On Wed, 2015-10-14, Morten W. Petersen wrote:
[...]
>> As for threading, it is also something that has to be taken into
>> account, and I'm already designing the main parser loop so that
>> threading can be plugged in there.
>
> I never understood what role threading would have?  If it's for
> performance -- parsing XML faster -- you can be almost certain
> that for all users (a) it's fast enough already on one CPU and (b)
> if it's not, it's I/O bound so using more CPUs won't help.

I did a little test now, and found I could get about 200 MB/s reads
on my SSD disk.  Let's say the file is on something like a RAM-based
filesystem that writes (syncs) to a physical disk as well, then we're
talking a lot more than 200 MB/s.

> If you just want to respect a user's choice to use threading in her
> code, the right solution is just to avoid things that would break
> threading.
>
> It would probably be enough that you could promise that different
> parser objects can be used from different thread contexts, but warn
> people not to access one object from multiple threads unless they add
> some locking.
>
>> I know now that using pthreads and a specific exception library
>> looks like a good idea,
>
> I think several of us stated that both sound like really bad ideas.

And that's OK.  I look forward to seeing how it actually works.

>> and that's nice to know, before I decide on ways to deal with
>> errors and choose something I'll end up typing a lot of characters
>> to change.
>>
>> I guess coming from Python I'm taking a more high-level approach
>> than what might be the norm.
>
> I have used C++ and Python quite a lot, and I think it has affected my
> C code.  Mostly in how I try to make my code stay close to the problem
> domain and not be swamped in details -- I want to separate the
> essential solution to the problem from the not so interesting details.
>
> So yes, I think that high-level thinking is a good thing in general,
> but for some things the high-level view does not help.  Especially not
> with C.

Yes it is important to have an overview so one doesn't let the details
dictate everything..

-Morten

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

#72809

On Tuesday, October 13, 2015 at 6:16:15 PM UTC-5, Morten W. Petersen wrote:
> My understanding is that a multi-threaded program has access to the same
> memory, so each thread has to have its state stored in the same global
> variable.  And that's done using the thread id?

Many single-processsor multi-threaded systems will allow user code to
associate a pointer value with each thread, and will on every task-switch
load a certain global variable with the pointer associated the current
thread.  Typically this will identify a user-defined structure type which
may then be used to hold any number of thread-specific values.

Exception handling mechanisms could use setjmp, store the result into a
field of the structure identified by the aforementioned pointer, and then
call the code that might need to throw.  If it does throw, it would use
the aforementioned global to find the jmp_buff o which it could transfer
control.

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

#72931

On 14.10.2015 09:36, supercat@casperkitty.com wrote:
> On Tuesday, October 13, 2015 at 6:16:15 PM UTC-5, Morten W. Petersen wrote:
>> My understanding is that a multi-threaded program has access to the same
>> memory, so each thread has to have its state stored in the same global
>> variable.  And that's done using the thread id?
>
> Many single-processsor multi-threaded systems will allow user code to
> associate a pointer value with each thread, and will on every task-switch
> load a certain global variable with the pointer associated the current
> thread.  Typically this will identify a user-defined structure type which
> may then be used to hold any number of thread-specific values.
>
> Exception handling mechanisms could use setjmp, store the result into a
> field of the structure identified by the aforementioned pointer, and then
> call the code that might need to throw.  If it does throw, it would use
> the aforementioned global to find the jmp_buff o which it could transfer
> control.

Yep.  If exceptions are used then they will have to support both
compiles with and without threads, and because of that I think the
best thing is to find some simple library that handles both instead
of rolling my own.

-Morten

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

#72753

Morten W. Petersen wrote:
> On 13.10.2015 23:39, Jorgen Grahn wrote:
>> On Tue, 2015-10-13, Morten W. Petersen wrote:
>>> On 13.10.2015 20:46, Ian Collins wrote:
>>>> Morten W. Petersen wrote:
>>>>> On 13.10.2015 17:26, supercat@casperkitty.com wrote:
>>> [...]
>>>>>
>>>>> Is it possible to look back up in the call stack, to search for a given
>>>>> point and restore to that?
>>>>
>>>> If you want C++ like exception handling, you know whee to look!
>>>
>>> Hmm, no, I don't want to rely on C++. :)
>>>
>>> I found this thing though:
>>>
>>>      http://www.nicemice.net/cexcept/
>>>
>>> Which is a exception system for C.  So there are alternatives, I
>>> just have to find the best one.
>>
>> If you don't want the mechanisms in C++, you probably shouldn't bolt
>> on emulations on top of C either -- /particularly/ not if you're
>> writing a library!
>
> Heh.  Well emulations are on thing, different implementations are
> another..
>
> What kind of overhead does the C++ try/catch thing have?

With current compilers little if any as long as you don't throw.  You 
should be able to get slightly better performance with

try { doSomething(); } catch(..) { handleError(); }

style code than with

if ( !doSomething(); ) handleError();

>> I recommend doing error handling like everyone else does it.
>
> Yes, that is an option that I might use.

s/might/should/

Everyone else does it the way they do for good reasons!

-- 
Ian Collins

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

#72754

On 13/10/15 23:49, Morten W. Petersen wrote:
> On 13.10.2015 23:39, Jorgen Grahn wrote:
>> On Tue, 2015-10-13, Morten W. Petersen wrote:
>>> On 13.10.2015 20:46, Ian Collins wrote:
>>>> Morten W. Petersen wrote:
>>>>> On 13.10.2015 17:26, supercat@casperkitty.com wrote:
>>> [...]
>>>>>
>>>>> Is it possible to look back up in the call stack, to search for a
>>>>> given
>>>>> point and restore to that?
>>>>
>>>> If you want C++ like exception handling, you know whee to look!
>>>
>>> Hmm, no, I don't want to rely on C++. :)
>>>
>>> I found this thing though:
>>>
>>>     http://www.nicemice.net/cexcept/
>>>
>>> Which is a exception system for C.  So there are alternatives, I
>>> just have to find the best one.
>>
>> If you don't want the mechanisms in C++, you probably shouldn't bolt
>> on emulations on top of C either -- /particularly/ not if you're
>> writing a library!
>
> Heh.  Well emulations are on thing, different implementations are
> another..
>
> What kind of overhead does the C++ try/catch thing have?

For most implementations, very little overhead.  There can be some 
tradeoff between overheads in size and speed, and in the speed of 
handling thrown exceptions versus the speed in normal runs.  Most 
implementations aim to minimise the speed cost when exceptions are not 
thrown.

You can expect far less overhead in using C++ for exceptions than any 
bolt-on exception stuff in C, or explict setjmp/longjmp nightmares.  It 
is often less overhead than explicit "normal" error checking in C.


As Ian says, writing proper exception-safe code is a difficult job in 
C++.  Trying to do it in a language that does not support exceptions is 
just daft.

So if you want fundamental C++ features, use C++.  If you want to write 
in C, write C.  And listen to what people with experience tell you, and 
use write your error handling in a way that matches common practice in C 
- there are good reasons for the common practice!


>
>> I recommend doing error handling like everyone else does it.
>
> Yes, that is an option that I might use.
>
> -Morten
>

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

#72756

On 10/13/2015 05:49 PM, Morten W. Petersen wrote:
> On 13.10.2015 23:39, Jorgen Grahn wrote:
...
>> If you don't want the mechanisms in C++, you probably shouldn't bolt
>> on emulations on top of C either -- /particularly/ not if you're
>> writing a library!
> 
> Heh.  Well emulations are on thing, different implementations are
> another..
> 
> What kind of overhead does the C++ try/catch thing have?

That varies with the implementation. You can implement exceptions that
take a lot of overhead, even when exceptions are not thrown, but where
throwing an exception is very quick. However, since exceptions are
supposed to be "exceptional", most modern implementations go in the
opposite direction, using methods that have almost no overhead when an
exception is not thrown, at the cost of making throw()/catch() itself a
very slow operation.

It's entirely feasible to write C++ code that uses throw() and catch()
as a substitute for the "break", "continue", "goto", or "return". Since
the typical modern C++ implementation is optimized for exceptions as
"exceptional" operations, that's a very BAD idea. I strongly recommend
using that approach if you decide to use C++, if there's any danger that
your code is executing too fast.
-- 
James Kuyper

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

#72825

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:

> If you don't want the mechanisms in C++, you probably shouldn't bolt
> on emulations on top of C either -- /particularly/ not if you're
> writing a library!
> 
> I recommend doing error handling like everyone else does it.

I second this. _Particularly_ in a library.

Richard

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

#72932

On 14.10.2015 13:37, Richard Bos wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>
>> If you don't want the mechanisms in C++, you probably shouldn't bolt
>> on emulations on top of C either -- /particularly/ not if you're
>> writing a library!
>>
>> I recommend doing error handling like everyone else does it.
>
> I second this. _Particularly_ in a library.

Well as I posted to Jorgen just now, the library parsing function
should be a black box that either succeeds or fails and gives
feedback if it fails.

Since there is so much doubt about exceptions here on comp.lang.c
there will have to be a lot of tests that trash around and test
things thoroughly.

-Morten

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

#72978

Morten W. Petersen wrote:
>
> Since there is so much doubt about exceptions here on comp.lang.c
> there will have to be a lot of tests that trash around and test
> things thoroughly.

Swamper tyres are a good fit on a 4WD but not on a Aston Martin.  Yes 
you can bolt them on, but the result is a mess!

-- 
Ian Collins

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

#73011

On 15.10.2015 20:56, Ian Collins wrote:
> Morten W. Petersen wrote:
>>
>> Since there is so much doubt about exceptions here on comp.lang.c
>> there will have to be a lot of tests that trash around and test
>> things thoroughly.
>
> Swamper tyres are a good fit on a 4WD but not on a Aston Martin.  Yes
> you can bolt them on, but the result is a mess!

Well I don't quite get that analogy...  For this project I guess an
analogy of a self-driving F1-car with is better. :)

-Morten

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

#72755

On 10/13/2015 04:06 PM, Morten W. Petersen wrote:
> On 13.10.2015 20:46, Ian Collins wrote:
>> Morten W. Petersen wrote:
>>> On 13.10.2015 17:26, supercat@casperkitty.com wrote:
> [...]
>>>
>>> Is it possible to look back up in the call stack, to search for a given
>>> point and restore to that?
>>
>> If you want C++ like exception handling, you know whee to look!
> 
> Hmm, no, I don't want to rely on C++. :)

C++ guarantees that the destructor for an object will be executed when
that object's lifetime ends, even if it ends a the result of a thrown
exception. C has no such guarantee. As a result of that rule, and
several other similar features, it's much harder to write exception-safe
code in C than in C++.
Are you being paid according to the time that you spend on this project,
and have no deadlines you need to meet? In that case, I strongly
recommend adopting a C-based exception system - it will keep you
profitably employed for years, tracking down the bugs.

> I found this thing though:
> 
>    http://www.nicemice.net/cexcept/
> 
> Which is a exception system for C.  So there are alternatives, I
> just have to find the best one.

The best available exception system for C will still be a clumsy error
prone exception system.
-- 
James Kuyper

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web