Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > is C++ worth it ?

Reply
Thread Tools

is C++ worth it ?

 
 
Stuart
Guest
Posts: n/a
 
      08-01-2012
Stuart wrote:
>> But unfortunately I have no more
>> information about where the Access Violation occurred since C++
>> exceptions are designed to be used in a different way.



On 7/31/12 Paavo Helde wrote:
> You can do that by defining your own handler (see _set_se_translator()) and
> studying the SEH exception codes and addresses etc. Note that this must be
> called in each thread in a multithreaded app.


>> A perfect language would generate an exception with a stacktrace upon an
>> Access Violation, which is much more preferable to a Core Dump. For
>> those who actually want to have the core dump, the language should
>> generate such a dump when the exception is not caught (AFAIK, Win32 does
>> not offer a setting that generates dumps upon Access Violations).


> You can do that too, by calling MiniDumpWriteDump() from your SEH exception
> handler. A minidump file can be loaded in Visual Studio later or elsewhere
> and the stack backtrace examined. On the positive side it is much smaller
> than Linux core dumps; on the negative side it is not generated
> automatically and setting the system up is not very trivial.


Didn't know this. Thanks for sharing.

> This is all off-topic for general C++ of course.


That's what I was whining about. In my opinion this should be a C++
topic, but apparently I'm in the minority.

Thanks,
Stuart

 
Reply With Quote
 
 
 
 
Mark
Guest
Posts: n/a
 
      08-01-2012
On Tue, 31 Jul 2012 21:39:26 +0200, Bo Persson <(E-Mail Removed)> wrote:

>Nobody wrote 2012-07-31 15:59:
>> On Mon, 30 Jul 2012 21:26:52 +0200, Bo Persson wrote:
>>
>>>> That surprises me when I recall that, even without exceptions, a benign-
>>>> looking plus operator or even an absence of a statement can emit dozens
>>>> of instructions, due to operator overloading and constructors/destructors.
>>>
>>> You mean unlike other languages, where an innocent looking function f(x)
>>> can call other functions 10 levels deep?

>>
>> In other languages, there will at least be an explicit function call.
>>
>> In C++, copy constructors, destructors, and conversion operators can all
>> insert "invisible" function calls.
>>

>
>So you mean that when you see matrix_add(x, y) you immediately see how
>much code that produces, while x + y is a mystery?
>
>I don't get it!


Both cases could result in a lot of extra code. However, for people
not familiar with C++, "x + y" looks like a simple expression.
--
(\__/) M.
(='.'=) If a man stands in a forest and no woman is around
(")_(") is he still wrong?

 
Reply With Quote
 
 
 
 
Mark
Guest
Posts: n/a
 
      08-01-2012
On Tue, 31 Jul 2012 17:49:51 -0500, BGB <(E-Mail Removed)> wrote:

>On 7/31/2012 3:25 PM, Scott Lurndal wrote:
>> BGB <(E-Mail Removed)> writes:
>>> On 7/31/2012 9:20 AM, Scott Lurndal wrote:
>>>> James Kanze <(E-Mail Removed)> writes:
>>>>> On Monday, July 30, 2012 7:59:44 PM UTC+1, Stuart wrote:
>>>>>> On 7/30/12 Jorgen Grahn wrote:
>>>>>
>>>>>>> Wait a minute -- you say the MS compiler works as you want;
>>>>>>> I say gcc does on Linux ... where *do* you see the problem?
>>>>>
>>>>>> I thought gcc did not turn Access Violations into exceptions.
>>>>>> AFAIK, this is a unique feature of the MS compilers. However,
>>>>>> I would very much like to be proven wrong.
>>>>>
>>>>> This error is unique to MS compilers I think (and I think it's
>>>>> optional there). With g++ under Linux (and all other Unix
>>>>> compilers, I think), and access violation results in a core
>>>>> dump, which is far preferrable for most applications.\\
>>>>
>>>> technically, an access violation results in a signal, which if
>>>> not caught by the application will terminate the application with
>>>> a core file (if the core file resource limit allows, and if the
>>>> stupid Fedora ABRT package isn't running).
>>>>
>>>
>>> yeah, and nifty stuff can be done in signal handlers, potentially
>>> including, among other things, triggering an exception to the thrown and
>>> the stack to be unwound. whether or not this is a good idea is a
>>> separate issue, normal C++ exceptions may not necessarily work (a custom
>>> mechanism may be needed), and have not yet determined how portable or
>>> versatile this is.

>>
>> I tend to use siglongjmp() to unwind when I catch asynchronous signals
>> such as SIGTERM/SIGINT/SIGQUIT. When catching synchronous, such as SIGSEGV, there are
>> no assurances that the rest of the program is still sane, and attempting
>> to generate a C++ exception may result in undefined behaviour.
>>

>
>yeah. another issue though is that given how signals and C++ exceptions
>work on Linux, I would suspect (untested) that trying to throw a C++
>exception in a signal handler could very well cause it to blow up.
>
>but, yeah, siglongjmp() is probably a much better idea.


I often assume that if we receive a SIGTERM/SIGINT/SIGQUIT signal then
this is a request to terminate so the application would normally clean
up and quit.

With SIGSEGV I print out a stack trace and then allow the application
to create a core dump.
--
(\__/) M.
(='.'=) If a man stands in a forest and no woman is around
(")_(") is he still wrong?

 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      08-01-2012
On Jul 31, 7:51*pm, Paavo Helde <(E-Mail Removed)> wrote:
> Stuart <(E-Mail Removed)> wrote innews:jv81ag$77v$(E-Mail Removed):



> > But unfortunately I have no more
> > information about where the Access Violation occurred since C++
> > exceptions are designed to be used in a different way.

>
> You can do that by defining your own handler (see _set_se_translator()) and
> studying the SEH exception codes and addresses etc. Note that this must be
> called in each thread in a multithreaded app.
>
> > A perfect language would generate an exception with a stacktrace upon an
> > Access Violation, which is much more preferable to a Core Dump. For
> > those who actually want to have the core dump, the language should
> > generate such a dump when the exception is not caught (AFAIK, Win32 does
> > not offer a setting that generates dumps upon Access Violations).

>
> You can do that too, by calling MiniDumpWriteDump() from your SEH exception
> handler. A minidump file can be loaded in Visual Studio later or elsewhere
> and the stack backtrace examined. On the positive side it is much smaller
> than Linux core dumps; on the negative side it is not generated
> automatically and setting the system up is not very trivial.


but not very hard either. And fairly well documented.

> This is all off-topic for general C++ of course.
>
> Cheers
> Paavo


 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      08-01-2012
On Jul 31, 10:32*am, Stuart <(E-Mail Removed)> wrote:
> On Jul 30, Stuart wrote:
> [snip]
> *>> I know that this sounds
>
> >> contemptuous, but I know a lot of small companies that employ
> >> Quereinsteigers (didn't find a proper English word for it, there is
> >> probably none).


we used to use "retread"


> On 7/31/12 Nick Keighley wrote:
>
> >http://www.dw.de/dw/article/0,,6616141,00.html

>
> > learn a quirky German word each week...

>
> Nice page. Sits now in my bookmarks bar. Thanks.
> Stuart


 
Reply With Quote
 
none
Guest
Posts: n/a
 
      08-01-2012
In article <(E-Mail Removed)>,
Mark <(E-Mail Removed)> wrote:
>On Tue, 31 Jul 2012 21:39:26 +0200, Bo Persson <(E-Mail Removed)> wrote:
>
>>Nobody wrote 2012-07-31 15:59:
>>> On Mon, 30 Jul 2012 21:26:52 +0200, Bo Persson wrote:
>>>
>>>>> That surprises me when I recall that, even without exceptions, a benign-
>>>>> looking plus operator or even an absence of a statement can emit dozens
>>>>> of instructions, due to operator overloading and constructors/destructors.
>>>>
>>>> You mean unlike other languages, where an innocent looking function f(x)
>>>> can call other functions 10 levels deep?
>>>
>>> In other languages, there will at least be an explicit function call.
>>>
>>> In C++, copy constructors, destructors, and conversion operators can all
>>> insert "invisible" function calls.
>>>

>>
>>So you mean that when you see matrix_add(x, y) you immediately see how
>>much code that produces, while x + y is a mystery?
>>
>>I don't get it!

>
>Both cases could result in a lot of extra code. However, for people
>not familiar with C++, "x + y" looks like a simple expression.


Hmm... if one is so "unfamiliar" with the language that he doesn't
even know about operator overloading then really one should not read
the code and worry about how mouch code is execute when one line of
source code is read. It's not as if C++ was the only language
offering operatior overloading. Of course if the only language one
has ever been exposed to is Java, one might find C++ operator
overloading a novel concept.

Operator overloading can have two effect:
A) Improve the code base and make it more readable and more
maintainable.
B) Obfuscate the code base and make it less maintainable.

The difference between A) and B) is good programmers vs crap
programmers. C++ philosophy is to give good programmers the tools to
write better programs. Protection against B) is not built in the
language.

The typical criticism against operator overloading is overuse of it
for non-natural purpose but such a criticism can apply equally to
badly named functions.

Yannick




 
Reply With Quote
 
Nobody
Guest
Posts: n/a
 
      08-01-2012
On Tue, 31 Jul 2012 21:39:26 +0200, Bo Persson wrote:

> So you mean that when you see matrix_add(x, y) you immediately see how
> much code that produces, while x + y is a mystery?


No. The former involves an unknown amount of code in any language. In
C++, the latter also involves an unknown amount of code (and that code
isn't limited to the definition of operator+, as copy or conversion
operators may be invoked before operator+ is called).

Operator overloading is the least of the issues; many languages allow
functions to have non-alphanumeric names. It's the constructors,
destructors, and conversion operators which are the main pitfall.

 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      08-01-2012
On 8/1/2012 9:04 AM, Scott Lurndal wrote:
> Mark <(E-Mail Removed)> writes:
>> On Tue, 31 Jul 2012 17:49:51 -0500, BGB <(E-Mail Removed)> wrote:
>>
>>> On 7/31/2012 3:25 PM, Scott Lurndal wrote:
>>>> BGB <(E-Mail Removed)> writes:
>>>>> On 7/31/2012 9:20 AM, Scott Lurndal wrote:
>>>>>> James Kanze <(E-Mail Removed)> writes:
>>>>>>> On Monday, July 30, 2012 7:59:44 PM UTC+1, Stuart wrote:
>>>>>>>> On 7/30/12 Jorgen Grahn wrote:
>>>>>>>
>>>>>>>>> Wait a minute -- you say the MS compiler works as you want;
>>>>>>>>> I say gcc does on Linux ... where *do* you see the problem?
>>>>>>>
>>>>>>>> I thought gcc did not turn Access Violations into exceptions.
>>>>>>>> AFAIK, this is a unique feature of the MS compilers. However,
>>>>>>>> I would very much like to be proven wrong.
>>>>>>>
>>>>>>> This error is unique to MS compilers I think (and I think it's
>>>>>>> optional there). With g++ under Linux (and all other Unix
>>>>>>> compilers, I think), and access violation results in a core
>>>>>>> dump, which is far preferrable for most applications.\\
>>>>>>
>>>>>> technically, an access violation results in a signal, which if
>>>>>> not caught by the application will terminate the application with
>>>>>> a core file (if the core file resource limit allows, and if the
>>>>>> stupid Fedora ABRT package isn't running).
>>>>>>
>>>>>
>>>>> yeah, and nifty stuff can be done in signal handlers, potentially
>>>>> including, among other things, triggering an exception to the thrown and
>>>>> the stack to be unwound. whether or not this is a good idea is a
>>>>> separate issue, normal C++ exceptions may not necessarily work (a custom
>>>>> mechanism may be needed), and have not yet determined how portable or
>>>>> versatile this is.
>>>>
>>>> I tend to use siglongjmp() to unwind when I catch asynchronous signals
>>>> such as SIGTERM/SIGINT/SIGQUIT. When catching synchronous, such as SIGSEGV, there are
>>>> no assurances that the rest of the program is still sane, and attempting
>>>> to generate a C++ exception may result in undefined behaviour.
>>>>
>>>
>>> yeah. another issue though is that given how signals and C++ exceptions
>>> work on Linux, I would suspect (untested) that trying to throw a C++
>>> exception in a signal handler could very well cause it to blow up.
>>>
>>> but, yeah, siglongjmp() is probably a much better idea.

>>
>> I often assume that if we receive a SIGTERM/SIGINT/SIGQUIT signal then
>> this is a request to terminate so the application would normally clean
>> up and quit.
>>
>> With SIGSEGV I print out a stack trace and then allow the application
>> to create a core dump.

>
> If, for example, the SIGSEGV was because the FILE structure for stdout
> had been stepped on (or the stdout OutputStream), then attempting to print
> the stack trace will also fault - likewise, if you're using the glibc
> backtrace helpers, they could also encounter undefined behavior after
> a SIGSEGV/SIGBUS. You could use write(2, buf, strlen(buf)) to avoid
> a subsequent signal in the stdio code, but the backtrace helpers may
> still encounter issues if the stack got stepped on.
>


even this may not necessarily be unworkable, depending on how the logic
is set up. carefully written logic can still operate in the case of
bad/uncertain pointers. IOW: don't access memory through a pointer
unless it is (presumably) already known to be valid, ...

whether or not this is practical is a different matter (usually, it is
limited to special logic where the possibility of corrupted memory is
not unexpected, such as in the internals of a memory manager, ...).


more often though, the reason a person might be catching a SIGSEGV or
similar might actually be because a failure is expected in a certain
context, say:
potentiallyUnsafeOperation()
{
setup special signal handler;
do unsafe operation;
restore signal handler.
}

usually, in such a case, a person will know why the SIGSEGV or similar
has taken place, and so the intention is to trap and handle it.

in other cases, it might be because, actually, something "clever" is
being done with a memory region, so the signal handler may be used as a
way to handle it (I am aware of people doing this sort of thing partly
for reasons of implementing shared-memory and persistent memory systems,
among other things).

a big reason for not doing this though in the general case (such as
trying to use signal catching in an attempt to make a "crash-proof"
app), it that it may impede the ability to effectively debug the app
(and, may also just create an app that basically just goes into an
endless crash/recovery loop and is unable to resume normal operation
anyways).


 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      08-01-2012
On Tuesday, July 31, 2012 8:26:08 AM UTC+1, Stuart wrote:
> On July 30, 2012 Stuart wrote:


[...]
> Now I have the problem that I am bound to the Windows platform
> (drivers), so when I do something wrong and get an Access Violation,
> I'll get an BAD_ACCESS exception. This is actually a good thing because
> my application does not shut down without a pip, but the stack is
> unwound and the measurement machine returns to a defined state (stages
> stopped, camera in idle mode). But unfortunately I have no more
> information about where the Access Violation occurred since C++
> exceptions are designed to be used in a different way. Well, this works
> well for my StopException since I don't care which particalur action has
> been performed when the user aborted the measurement, but in case
> something went wrong, I'd like to see what happened.


That's a problem regarding the platform, *not* C++. The last
thing you want in such cases is for the stack to be unwound.
You want a dump of the state exactly where the error occurred.
A core dump, under Unix. (From what I understand, it's possible
to configure Windows to behave correctly as well.)

[...]
> A perfect language would generate an exception with a stacktrace upon an
> Access Violation, which is much more preferable to a Core Dump. For
> those who actually want to have the core dump, the language should
> generate such a dump when the exception is not caught (AFAIK, Win32 does
> not offer a setting that generates dumps upon Access Violations).


How is unwinding the stack preferrable to a core dump. The
stack trace tells where you were, but doesn't offer any
possiblity to see the surrounding state at each level.
Unwinding the stack looses important information.

(Where I work, when we have such problems, the first step is to
recreate them in the Unix environment, where we can get a core
dump, with all of the essential information.)

--
James
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      08-01-2012
On Tuesday, July 31, 2012 8:12:11 PM UTC+1, BGB wrote:
> On 7/31/2012 9:20 AM, Scott Lurndal wrote:


[...]
> yeah, and nifty stuff can be done in signal handlers, potentially
> including, among other things, triggering an exception to the thrown and
> the stack to be unwound. whether or not this is a good idea is a
> separate issue, normal C++ exceptions may not necessarily work (a custom
> mechanism may be needed), and have not yet determined how portable or
> versatile this is.


You cannot throw in a signal handler. The results are undefined
behavior. And it doesn't reliably work on any platform I know.

> though, granted, some of this could be determined by testing it.


Testing won't give you many answers here. Throwing in a signal
handler is undefined behavior. It may work in your tests, but
not in any real application.

--
James
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Worth buying modem router? =?Utf-8?B?QmFkQW5nbGVy?= Wireless Networking 2 07-05-2005 02:33 PM
How much is Bill worth right now? Me_and_you ASP .Net 18 02-12-2005 03:21 AM
Market worth? Nickolas Microsoft Certification 2 12-10-2004 12:06 AM
Is it worth it? Russ McKenna ASP .Net 5 12-06-2003 06:47 PM
MCSE Cert. Is it still worth it? Dominique Feteau Microsoft Certification 3 11-05-2003 08:43 PM



Advertisments