Is C++ worth it ?
    http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/

"But we are also moving away from low-level programming
and, yet, our software is still getting faster. I believe
that a major understated trend in the last decade or so
has been the increase in performance of the higher level
languages."

I disagree.

Lynn

On 27/07/2012 12:37, Lynn McGuire wrote:
> Is C++ worth it ?
> http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/
>
> "But we are also moving away from low-level programming
> and, yet, our software is still getting faster. I believe
> that a major understated trend in the last decade or so
> has been the increase in performance of the higher level
> languages."
>
> I disagree.
>

I agree with one of the comments:

"Please stop posting misleading microbenchmarks like these. Your 
methodology is not rigid and your benchmark is 3 lines of code. The 
whole loop might be replaced with a nop if the array doesn�t escape."

Also the author doesn't have a good answer to it.

Internet is full of this type of biased / non scientific tests  :-(

Best regards

-- 
Cholo Lennon
Bs.As.
ARG

On Fri, 27 Jul 2012 13:20:16 -0300
Cholo Lennon <chololennon@hotmail.com> wrote:

> On 27/07/2012 12:37, Lynn McGuire wrote:
> > Is C++ worth it ?
> > http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/
> >
> > "But we are also moving away from low-level programming
> > and, yet, our software is still getting faster. I believe
> > that a major understated trend in the last decade or so
> > has been the increase in performance of the higher level
> > languages."
> >
> > I disagree.
> >
>=20
> I agree with one of the comments:
>=20
> "Please stop posting misleading microbenchmarks like these. Your=20
> methodology is not rigid and your benchmark is 3 lines of code. The=20
> whole loop might be replaced with a nop if the array doesn=E2=80=99t esca=
pe."
>=20
> Also the author doesn't have a good answer to it.
>=20
> Internet is full of this type of biased / non scientific tests  :-(
>=20
> Best regards
>=20

Well, yes, in this case benchmark should show identical performance as
it is pretty simple. But gcc 4.8.0 and openjdk 1.7 shows that
Java is faster on my system.
No single option would help except that gcc optimizer was
bad at particular indexing.
When I changed this:
    public static void sum(int[] data) {
		if(data.length =3D=3D 0) return;
		for( int i =3D 1; i !=3D  data.length; ++i)
		  data[i] +=3D data[i-1];
	}

to this:
static void sum(std::vector<int>& data) {
                if(data.empty()) return;
                for( unsigned i =3D 0; i < data.size() - 1; ++i)
                  data[i+1] +=3D data[i];
        }

performance became identical as expected.
Somehow gcc generated non optimal code in first case...

Lynn McGuire <lmc@winsim.com>:
>  Is C++ worth it ?
>      http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/
> 
>  "But we are also moving away from low-level programming

I don't think of C++ as low level. I think of it as a language that
supports programming in terms of the concepts of the problem domain.
Oh, and yes, you can program in bits and bytes when needed.

Chris Gordon-Smith
www.simsoup.info

On Fri, 2012-07-27, Lynn McGuire wrote:
> Is C++ worth it ?
>     http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/
>
> "But we are also moving away from low-level programming
> and, yet, our software is still getting faster. I believe
> that a major understated trend in the last decade or so
> has been the increase in performance of the higher level
> languages."
>
> I disagree.

It's a weird read, mostly because his implicit assumption is that Java
is a "higher level" language and C++ is not.  What's so high about
Java -- garbage collection?

/Jorgen

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

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> It's a weird read, mostly because his implicit assumption is that Java
> is a "higher level" language and C++ is not.  What's so high about
> Java -- garbage collection?

There's a close almost 1-to-1 correspondence between C++ statements and
their equivalent assembler opcodes (with only a few exceptions, an
ironic example being, precisely, exceptions, which are not direct asm
constructs but are much higher concepts).

The correspondence between Java statements and asm opcodes is significantly
less straightforward. For example, one could hastily think that references
in Java are just asm memory addresses (like the references/pointers in C++),
but in fact they aren't. Java references are much more abstract than that.
(As an example of how abstract Java references are, they allow for automatic
behind-the-scenes memory compaction without the program even noticing. The
same is just impossible in C++ because references/pointers are literal
memory addresses, and memory compaction is basically impossible without
breaking the program.)

Also, the runtime environment where Java programs are run is (or at least
can be made to be) more akin go a virtualized environment than running the
program "raw". For example, if you made your own "Java compiler" that tried
to break some assertions made by the language specifications, the RTE can
catch it and refuse to run your program. (For example, if you tried to
make references that access illegal memory, or perform some other non-Java
weirdness such as pointer arithmetic, the RTE can catch such attempts and
stop the program before it wreaks havoc.)

As both hardware and compiler technology has advanced during the decades,
these security measures, including also such things as garbage collection,
cause less and less overhead to the actual execution times of the programs.

In C++ this would be much more difficult to implement and impose because
of the semantics of the language.

Cholo Lennon <chololennon@hotmail.com> wrote:
> I agree with one of the comments:
> 
> "Please stop posting misleading microbenchmarks like these. Your 
> methodology is not rigid and your benchmark is 3 lines of code. The 
> whole loop might be replaced with a nop if the array doesn???t escape."

I also agree. Comparing two languages with a two-line "benchmark" is
completely bollocks. It says absolutely nothing about anything.

When comparing languages for actual projects, there are many more important
questions than "which one can optimize a tight loop better?", such as:

- Does the language allow me to implement this project?
- How easily does it allow me to do that?
- How much effort is needed to implement the project, including writing the
actual implementation, and debugging it?
- What libraries and ready-made utilities does the language offer? How easy
are they to use?
- How safe is the language? How likely is it for a hidden bug to be uncaught
in testing, get to a release version, and then causing severe harm to the
user's system?
- If the application requires efficiency, how efficient is the code generated
with the programming language?

All those question are highly subjective, and there's no way to objectively
and unambiguously "measure" them.

On Sat, 2012-07-28, Juha Nieminen wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>> It's a weird read, mostly because his implicit assumption is that Java
>> is a "higher level" language and C++ is not.  What's so high about
>> Java -- garbage collection?
>
> There's a close almost 1-to-1 correspondence between C++ statements and
> their equivalent assembler opcodes

That definition of higher-level didn't come to mind. But yes, I
suppose that's what the author was thinking of.

I was thinking more of the mapping between code and my design, problem
domain and terminology -- the smaller the gap is there, the better.

/Jorgen

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

C++ has a lot of unnecessary complexity, but it is both:
low-level as well as high-level.

On 2012-07-28 04:36, Juha Nieminen wrote:
> 
> There's a close almost 1-to-1 correspondence between C++ statements and
> their equivalent assembler opcodes (with only a few exceptions, an
> ironic example being, precisely, exceptions, which are not direct asm
> constructs but are much higher concepts).

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.

-- 
Seungbeom Kim

Gerald Breuer <Gerald.Breuer@googlemail.com> wrote:
> C++ has a lot of unnecessary complexity

Care to give some examples?

Seungbeom Kim <musiphil@bawi.org> wrote:
> On 2012-07-28 04:36, Juha Nieminen wrote:
>> 
>> There's a close almost 1-to-1 correspondence between C++ statements and
>> their equivalent assembler opcodes (with only a few exceptions, an
>> ironic example being, precisely, exceptions, which are not direct asm
>> constructs but are much higher concepts).
> 
> 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.

As I said, there are exceptions. C++ is definitely "higer-level" than C,
but it's still pretty "close to the metal". (And that's how we like it,
really.)

Juha Nieminen <nospam@thanks.invalid> wrote in
news:jv0irg$1eu$1@speranza.aioe.org: 

> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>> It's a weird read, mostly because his implicit assumption is that
>> Java is a "higher level" language and C++ is not.  What's so high
>> about Java -- garbage collection?
> 
> There's a close almost 1-to-1 correspondence between C++ statements
> and their equivalent assembler opcodes (with only a few exceptions, an
> ironic example being, precisely, exceptions, which are not direct asm
> constructs but are much higher concepts).

In C++, I spend a lot of effort on class design: class hierarchies, public 
interfaces, private interfaces, function signatures etc. I think none of 
this corresponds to any assembler opcodes. And arguably C++ OO support is 
higher-level than that of Java (as it allows multiple inheritance). 

Actually it is not important which language is "higher level", whatever 
that would mean. One should rather pick a language which suits the task 
best, like for example Lisp for airline fare calculations 
(http://www.paulgraham.com/carl.html).

Cheers
Paavo

On 7/27/12 Lynn McGuire wrote:
> Is C++ worth it ?

Sadly, the answer to this question is yes.

If you are working in the industry, there is hardly a way around C++. 
First of all, most drivers are provided with a C interface, which makes 
C++ a "natural" choice. Besides this, hardware independence is mostly a 
minor issue since the hardware asset of a large company won't be changed 
overnight to a different platform, and for GUI related stuff there are 
still platform independent libraries out there.

Curiously, the answer won't be to use Java or C#, as they are supposed 
to be more high-level languages. Those are good languages that can be 
easily learned by the majority of programmers. Even after 12 years as 
C++ programming, and delving into some more obscure parts of template 
programming, not even I would consider myself an expert on C++ (I think 
Victor is one, and James).

Probably the flat learning curve that is what makes Java and C# so 
popular. What the software industry needs is a language that can be used 
suffiently well by the average programmer. 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). Those companies have to make do with the "human 
resources" they could get, so they want their programmers to struggle 
with the problem domain and not with the programming language.


Setting the "human" factor aside, when we want to talk about programming 
languages we have to consider several points:
(1) is the actual language better,
(2) are the available compilers/debuggers/whatever tools better, and
(3) are the available libraries better?

I think that C++ beats Java in point (1), but is inferior with regard to 
point (3). Point (2) is maybe a draw. Since the decision for either Java 
or C++ must always be based on all three points, it'll always be quite 
difficult to decide. And most often it are some very minor points that 
let the programmer tend to one or the other language.

For example, I start to tend to favour Java over C++ because whenever I 
make some grave mistake and get a Memory Access Violation, this is more 
or less the end of the world for a C++ application. Java, in contrast, 
nicely captures this and gives me an exception. This not only makes me 
able to shut down gracefully, but also provides me with enough error 
information about where I went wrong (there is no standard way under C++ 
to retrieve the stacktrace of an exception). I don't understand why such 
a feature is not important enough to make it into the C++ standard, 
while such gimmicks like lambdas and whatnot get huge attention. 
Happily, I can now finish with the only  answer for the whole topic:

Everyone can chose the programming language that meets his needs best.

Regards,
Stuart

On Mon, 2012-07-30, Stuart wrote:
> [...] And most often it are some very minor points that 
> let the programmer tend to one or the other language.
>
> For example, I start to tend to favour Java over C++ because whenever I 
> make some grave mistake and get a Memory Access Violation, this is more 
> or less the end of the world for a C++ application. Java, in contrast, 
> nicely captures this and gives me an exception. This not only makes me 
> able to shut down gracefully, but also provides me with enough error 
> information about where I went wrong (there is no standard way under C++ 
> to retrieve the stacktrace of an exception). I don't understand why such 
> a feature is not important enough to make it into the C++ standard, 
> while such gimmicks like lambdas and whatnot get huge attention. 

Java is more than a language: it's an environment and a lifestyle.
That's why it can specify such things, but that's also a reason Java
unsuitable in my environments!

In those environments (Linux-based) uncaught C++ exceptions give
excellent diagnostics.  But you cannot standardize that.

/Jorgen

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

Am 7/30/12 2:42 PM, schrieb Jorgen Grahn:
> On Mon, 2012-07-30, Stuart wrote:
>> [...] And most often it are some very minor points that
>> let the programmer tend to one or the other language.
>>
>> For example, I start to tend to favour Java over C++ because whenever I
>> make some grave mistake and get a Memory Access Violation, this is more
>> or less the end of the world for a C++ application. Java, in contrast,
>> nicely captures this and gives me an exception. This not only makes me
>> able to shut down gracefully, but also provides me with enough error
>> information about where I went wrong (there is no standard way under C++
>> to retrieve the stacktrace of an exception). I don't understand why such
>> a feature is not important enough to make it into the C++ standard,
>> while such gimmicks like lambdas and whatnot get huge attention.
>
> Java is more than a language: it's an environment and a lifestyle.
> That's why it can specify such things, but that's also a reason Java
> unsuitable in my environments!
>
> In those environments (Linux-based) uncaught C++ exceptions give
> excellent diagnostics.  But you cannot standardize that.

Um, can you try to explain that to me. Beware, I only majored 
theoretical computer science, so I might not understand everything you 
say ;-) It is probably not because the design of C++ inherently forbids 
such a feature, as there are solutions for various platforms.

I think that this a rather important feature of a language. It is of 
little use that the C++ standard says that we will get UB once we 
dereference a pointer that points to unallocated memory. Erring is 
human, so as long as the language allows me to fail, it would be nice if 
it could provide me with some decent information about at which point 
the error occurred. Just like the MS compilers do.

I know that some people would say that there are platforms where this is 
not possible. So I would be content with a standardization of a subset 
of platforms where stacktraces of exceptions or caught Access Violations 
are possible. Maybe the standardization of C++ should not stick to the 
smallest possible denominator.

Thanks in advance,
Stuart

On Mon, 2012-07-30, Stuart wrote:
> Am 7/30/12 2:42 PM, schrieb Jorgen Grahn:
>> On Mon, 2012-07-30, Stuart wrote:
>>> [...] And most often it are some very minor points that
>>> let the programmer tend to one or the other language.
>>>
>>> For example, I start to tend to favour Java over C++ because whenever I
>>> make some grave mistake and get a Memory Access Violation, this is more
>>> or less the end of the world for a C++ application. Java, in contrast,
>>> nicely captures this and gives me an exception. This not only makes me
>>> able to shut down gracefully, but also provides me with enough error
>>> information about where I went wrong (there is no standard way under C++
>>> to retrieve the stacktrace of an exception). I don't understand why such
>>> a feature is not important enough to make it into the C++ standard,
>>> while such gimmicks like lambdas and whatnot get huge attention.
>>
>> Java is more than a language: it's an environment and a lifestyle.
>> That's why it can specify such things, but that's also a reason Java
>> unsuitable in my environments!
>>
>> In those environments (Linux-based) uncaught C++ exceptions give
>> excellent diagnostics.  But you cannot standardize that.
>
> Um, can you try to explain that to me.

Well, technically I guess you *can* standardize, but as I understand
it the committee has traditionally chosen not to intervene in such
things. The closest I can think of is that if your code is
sufficiently broken, the compiler must tell you.

And of course, a compiler can ignore the standard, like almost all did
with 'export'. Stroustrup won't sue you.

> ... it would be nice if 
> it could provide me with some decent information about at which point 
> the error occurred. Just like the MS compilers do.

Wait a minute -- you say the MS compiler works as you want; I say gcc
does on Linux ... where *do* you see the problem?

/Jorgen

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

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.

And to come back to backtraces in exceptions: Why not standardize it 
"optionally", so that if the platform provides this feature, it can be 
used in a standard way?

Thanks,
Stuart

PS: Of course my list of C++ gurus was not exhaustive. Of course, you 
are on it, too, as well as Igor Tandetnik. Unfortunately he is no longer 
to be seen on usenet, he's probably off to the MS web-based forums. 
That's a pity.

Am 30.07.12 20:59, schrieb Stuart:
> 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.

It does not, indeed. But on Linux one can use valgrind, which is one of 
the best memory debugging tools available:

	http://valgrind.org/

It executes the program in a virtual machine to find access violations 
at the first possible event.

	Christian

On Mon, 2012-07-30, 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.

Ok, I didn't notice the switch in subject.  As far as I know gcc
doesn't do this -- on Unix the program is pretty much dead if a 
segmentation fault happens.

....
> PS: Of course my list of C++ gurus was not exhaustive. Of course, you 
> are on it,

I'm flattered but sorry, I'm not. I'm sometimes vocal here and I *do*
think I can use C++ effectively most of the time, but I'm not an
expert.  There are large chunks of the language I've never used and
probably never will use.

/Jorgen

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

Seungbeom Kim skrev 2012-07-28 20:59:
> On 2012-07-28 04:36, Juha Nieminen wrote:
>>
>> There's a close almost 1-to-1 correspondence between C++ statements and
>> their equivalent assembler opcodes (with only a few exceptions, an
>> ironic example being, precisely, exceptions, which are not direct asm
>> constructs but are much higher concepts).
>
> 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?


Bo Persson

Stuart skrev 2012-07-30 19:32:
> Am 7/30/12 2:42 PM, schrieb Jorgen Grahn:
>> On Mon, 2012-07-30, Stuart wrote:
>>> [...] And most often it are some very minor points that
>>> let the programmer tend to one or the other language.
>>>
>>> For example, I start to tend to favour Java over C++ because whenever I
>>> make some grave mistake and get a Memory Access Violation, this is more
>>> or less the end of the world for a C++ application. Java, in contrast,
>>> nicely captures this and gives me an exception. This not only makes me
>>> able to shut down gracefully, but also provides me with enough error
>>> information about where I went wrong (there is no standard way under C++
>>> to retrieve the stacktrace of an exception). I don't understand why such
>>> a feature is not important enough to make it into the C++ standard,
>>> while such gimmicks like lambdas and whatnot get huge attention.

The language standard cannot require a stacktrace without first 
requiring that ALL implementations must use a stack. That would be 
limiting, and exclude some of the platforms that were available when the 
first C and C++ standards were written. ISO standards strive for a 
consensus, which is hard if some manufacturers are excluded.

Java doesn't have this problem as it only runs on one platform, the JVM. 
All JVMs have to do the same thing, even if the underlying platform does 
not.


> I think that this a rather important feature of a language. It is of
> little use that the C++ standard says that we will get UB once we
> dereference a pointer that points to unallocated memory. Erring is
> human, so as long as the language allows me to fail, it would be nice if
> it could provide me with some decent information about at which point
> the error occurred. Just like the MS compilers do.

The Java VM requires that access violations are caught. The C++ standard 
allows it, but also allows programs to run on systems without hardware 
memory management. On those systems it is perhaps unacceptably expensive 
to detect a violation. So the language allows it to fail instead.

>
> I know that some people would say that there are platforms where this is
> not possible. So I would be content with a standardization of a subset
> of platforms where stacktraces of exceptions or caught Access Violations
> are possible. Maybe the standardization of C++ should not stick to the
> smallest possible denominator.
>

The standard committee members have been VERY reluctant to standardize 
functionality that not all of them can implement. How good is it to be 
almost standard C++?

It is also possible to standardize this outside of the language, like 
POSIX does for some other things.


Bo Persson

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.

> And to come back to backtraces in exceptions: Why not
> standardize it "optionally", so that if the platform provides
> this feature, it can be used in a standard way?

The reason C++ doesn't have backtraces in exceptions is that
that's not what exceptions are for.  Exceptions are designed to
be caught, so any backtrace would be ignored.  If you have a
programming error, you want to stop immediately (in most
applications, anyway).  Violently, and with a backtrace.  In the
core file, or its equivalent---your client can't do anything
with a backtrace, but he can send you a core dump, so that you
can do something.  (And of course, if the core dump isn't in
your test cases, you're not testing sufficiently.)

-- 
James

On Monday, July 30, 2012 8:46:40 PM UTC+1, Bo Persson wrote:
> Stuart skrev 2012-07-30 19:32:

> The language standard cannot require a stacktrace without first 
> requiring that ALL implementations must use a stack. That would be 
> limiting, and exclude some of the platforms that were available when the 
> first C and C++ standards were written. ISO standards strive for a 
> consensus, which is hard if some manufacturers are excluded.

In the sense that you use the word here, C++ does require a
stack.  It requires that you can return from a function, and
refind the environment that you left.  However the
implementation does this, it can provide a backtrace.  (Since
throwing an exception requires stack unwinding, an
implementation is required to have code which can do this.)

-- 
James

On July 30, 2012 Stuart wrote:
>> 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.

On July 31, 2012 James Kanze wrote:
> 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.

>> And to come back to backtraces in exceptions: Why not
>> standardize it "optionally", so that if the platform provides
>> this feature, it can be used in a standard way?
>
> The reason C++ doesn't have backtraces in exceptions is that
> that's not what exceptions are for.  Exceptions are designed to
> be caught, so any backtrace would be ignored.  If you have a
> programming error, you want to stop immediately (in most
> applications, anyway).  Violently, and with a backtrace.  In the
> core file, or its equivalent---your client can't do anything
> with a backtrace, but he can send you a core dump, so that you
> can do something.  (And of course, if the core dump isn't in
> your test cases, you're not testing sufficiently.)


I had the following scenario: Software for quality assurance, it 
controls a measurement machine with cameras and stage. Measurements take 
up to 8 hours, so the user should be able to abort measurements if he 
sees that the measured object is not good enough.

I implemented the aborting of measurements by means of an exception, so 
that the stack is neatly unwound and the cameras stop acquisition and 
the stages will be powered off. With exceptions this is rather 
comfortable, since I don't have to clutter my code with

Picture* picture = 0;
if (acquirePicture (&picture) == ERROR_CODE_SHOULD_STOP)
   return ERROR_CODE_SHOULD_STOP;

but simply write

Picture* picture = acquirePicture ();

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.

I ended up setting up my own stack that can be examined later on, but 
this is rather clumsy and requires all my actions to push themselves on 
this stack (not too bad) and pop when they have finished. The later is 
quite cumbersome since every code path where the action stops without an 
exception has to ensure that the action pops itself from the stack, or 
else my stack gets messed up.

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).

Thanks in advance,
Stuart

PS: @Jorgen: Come on, you may not know every little bit of the language 
(who does), but certainly you know a LOT more than the average C++ 
programmer. I tend to read most of your posts because changes are good 
that I can learn something new.
@James: The same goes for you.

On Jul 30, 8:59=A0am, Stuart <DerTop...@web.de> wrote:
> On 7/27/12 Lynn McGuire wrote:
>
> > Is C++ worth it ?
>
> Sadly, the answer to this question is yes.
>
> If you are working in the industry, there is hardly a way around C++.
> First of all, most drivers are provided with a C interface, which makes
> C++ a "natural" choice. Besides this, hardware independence is mostly a
> minor issue since the hardware asset of a large company won't be changed
> overnight to a different platform, and for GUI related stuff there are
> still platform independent libraries out there.
>
> Curiously, the answer won't be to use Java or C#, as they are supposed
> to be more high-level languages. Those are good languages that can be
> easily learned by the majority of programmers. Even after 12 years as
> C++ programming, and delving into some more obscure parts of template
> programming, not even I would consider myself an expert on C++ (I think
> Victor is one, and James).
>
> Probably the flat learning curve that is what makes Java and C# so
> popular. What the software industry needs is a language that can be used
> suffiently well by the average programmer. 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).

http://www.dw.de/dw/article/0,,6616141,00.html

learn a quirky German word each week...


> Those companies have to make do with the "human
> resources" they could get, so they want their programmers to struggle
> with the problem domain and not with the programming language.
>
> Setting the "human" factor aside, when we want to talk about programming
> languages we have to consider several points:
> (1) is the actual language better,
> (2) are the available compilers/debuggers/whatever tools better, and
> (3) are the available libraries better?
>
> I think that C++ beats Java in point (1), but is inferior with regard to
> point (3). Point (2) is maybe a draw. Since the decision for either Java
> or C++ must always be based on all three points, it'll always be quite
> difficult to decide. And most often it are some very minor points that
> let the programmer tend to one or the other language.
>
> For example, I start to tend to favour Java over C++ because whenever I
> make some grave mistake and get a Memory Access Violation, this is more
> or less the end of the world for a C++ application. Java, in contrast,
> nicely captures this and gives me an exception. This not only makes me
> able to shut down gracefully, but also provides me with enough error
> information about where I went wrong (there is no standard way under C++
> to retrieve the stacktrace of an exception). I don't understand why such
> a feature is not important enough to make it into the C++ standard,
> while such gimmicks like lambdas and whatnot get huge attention.
> Happily, I can now finish with the only =A0answer for the whole topic:
>
> Everyone can chose the programming language that meets his needs best.
>
> Regards,
> Stuart

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).


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

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.

James Kanze <james.kanze@gmail.com> 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).

scott

Stuart <DerTopper@web.de> wrote in news:jv81ag$77v$1@dont-email.me:

> 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.

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

Cheers
Paavo
 

On 7/31/2012 9:20 AM, Scott Lurndal wrote:
> James Kanze <james.kanze@gmail.com> 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.

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

Op 31-Jul-12 9:26, Stuart schreef:
> On July 30, 2012 Stuart wrote:
>>> 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.
>
> On July 31, 2012 James Kanze wrote:
>> 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.
>
>>> And to come back to backtraces in exceptions: Why not
>>> standardize it "optionally", so that if the platform provides
>>> this feature, it can be used in a standard way?
>>
>> The reason C++ doesn't have backtraces in exceptions is that
>> that's not what exceptions are for.  Exceptions are designed to
>> be caught, so any backtrace would be ignored.  If you have a
>> programming error, you want to stop immediately (in most
>> applications, anyway).  Violently, and with a backtrace.  In the
>> core file, or its equivalent---your client can't do anything
>> with a backtrace, but he can send you a core dump, so that you
>> can do something.  (And of course, if the core dump isn't in
>> your test cases, you're not testing sufficiently.)
>
>
> I had the following scenario: Software for quality assurance, it
> controls a measurement machine with cameras and stage. Measurements take
> up to 8 hours, so the user should be able to abort measurements if he
> sees that the measured object is not good enough.
>
> I implemented the aborting of measurements by means of an exception, so
> that the stack is neatly unwound and the cameras stop acquisition and
> the stages will be powered off. With exceptions this is rather
> comfortable, since I don't have to clutter my code with
>
> Picture* picture = 0;
> if (acquirePicture (&picture) == ERROR_CODE_SHOULD_STOP)
>    return ERROR_CODE_SHOULD_STOP;
>
> but simply write
>
> Picture* picture = acquirePicture ();
>
> 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.
>
> I ended up setting up my own stack that can be examined later on, but
> this is rather clumsy and requires all my actions to push themselves on
> this stack (not too bad) and pop when they have finished. The later is
> quite cumbersome since every code path where the action stops without an
> exception has to ensure that the action pops itself from the stack, or
> else my stack gets messed up.

Maintaining your own stack isn't necessary on the Windows platform. On 
Windows you have the option to capture the structured exception (is not 
the same as a C++ exception) when things like an access violation 
occurs. At the point the handler is invoked the stack is still there to 
be examined. Windows also provides functions to walk the call stack. 
Many years ago I created a library for one of my clients to pinpoint 
where in the code their software had crashed (which in spite of 
extensive testing typically happened at some important client at the 
other side of the world with very few if any clues on how to reproduce 
the problem). This library installed a handler for structured exceptions 
and uncaught C++ exceptions, and logs the point in the code exactly 
where the exception originated from and the call stack at that point. It 
also triggered flushing the trace buffers, collecting some other 
information diagnostic information and put all of this in a .zip file, 
pop-up a dialog instructing how to proceed and terminate the 
application. The nice thing about this approach is that the existing 
code (about 2+ million lines) didn't need to be changed.

Of course this library relied heavily on Windows specific calls. However 
requiring this as part of the C++ standard would reduce the number of 
platforms on which C++ can be used.

BGB=E6=96=BC 2012=E5=B9=B48=E6=9C=881=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89UT=
C+8=E4=B8=8A=E5=8D=883=E6=99=8212=E5=88=8611=E7=A7=92=E5=AF=AB=E9=81=93=EF=
=BC=9A
> On 7/31/2012 9:20 AM, Scott Lurndal wrote:
>=20
> > James Kanze <james.kanze@gmail.com> writes:
>=20
> >> On Monday, July 30, 2012 7:59:44 PM UTC+1, Stuart wrote:
>=20
> >>> On 7/30/12 Jorgen Grahn wrote:
>=20
> >>
>=20
> >>>> Wait a minute -- you say the MS compiler works as you want;
>=20
> >>>> I say gcc does on Linux ... where *do* you see the problem?
>=20
> >>
>=20
> >>> I thought gcc did not turn Access Violations into exceptions.
>=20
> >>> AFAIK, this is a unique feature of the MS compilers. However,
>=20
> >>> I would very much like to be proven wrong.
>=20
> >>
>=20
> >> This error is unique to MS compilers I think (and I think it's
>=20
> >> optional there).  With g++ under Linux (and all other Unix
>=20
> >> compilers, I think), and access violation results in a core
>=20
> >> dump, which is far preferrable for most applications.\\
>=20
> >
>=20
> > technically, an access violation results in a signal, which if
>=20
> > not caught by the application will terminate the application with
>=20
> > a core file (if the core file resource limit allows, and if the
>=20
> > stupid Fedora ABRT package isn't running).
>=20
> >
>=20
>=20
>=20
> yeah, and nifty stuff can be done in signal handlers, potentially=20
>=20
> including, among other things, triggering an exception to the thrown and=
=20
>=20
> the stack to be unwound. whether or not this is a good idea is a=20
>=20
> separate issue, normal C++ exceptions may not necessarily work (a custom=
=20
>=20
> mechanism may be needed), and have not yet determined how portable or=20
>=20
> versatile this is.
>=20
>=20
>=20
> though, granted, some of this could be determined by testing it.

Well, I have checked the size of C++ compiler from time to time.

It is always getting fatter and fatter. I think a slim JVM with the linux=
=20
in the mobile phone systems is attracting more people to work on "new"=20
software on mobile phones every day.
=20

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!


Bo Persson

BGB <cr88192@hotmail.com> writes:
>On 7/31/2012 9:20 AM, Scott Lurndal wrote:
>> James Kanze <james.kanze@gmail.com> 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.

scott

On Tue, 2012-07-31, Bo Persson 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?

Perhaps he's just presenting this very common complaint from people
who dislike C++, and who's own favorite language doesn't have operator
overloading.

> I don't get it!

Me neither, but as you know people who don't use C++ have been
complaining about this for ~30 years.

/Jorgen

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

On 7/31/2012 3:25 PM, Scott Lurndal wrote:
> BGB <cr88192@hotmail.com> writes:
>> On 7/31/2012 9:20 AM, Scott Lurndal wrote:
>>> James Kanze <james.kanze@gmail.com> 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.


> scott
>

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

On Tue, 31 Jul 2012 21:39:26 +0200, Bo Persson <bop@gmb.dk> 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?

On Tue, 31 Jul 2012 17:49:51 -0500, BGB <cr88192@hotmail.com> wrote:

>On 7/31/2012 3:25 PM, Scott Lurndal wrote:
>> BGB <cr88192@hotmail.com> writes:
>>> On 7/31/2012 9:20 AM, Scott Lurndal wrote:
>>>> James Kanze <james.kanze@gmail.com> 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?

On Jul 31, 7:51=A0pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> Stuart <DerTop...@web.de> wrote innews:jv81ag$77v$1@dont-email.me:


> > 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()) a=
nd
> studying the SEH exception codes and addresses etc. Note that this must b=
e
> called in each thread in a multithreaded app.
>
> > A perfect language would generate an exception with a stacktrace upon a=
n
> > 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 doe=
s
> > not offer a setting that generates dumps upon Access Violations).
>
> You can do that too, by calling MiniDumpWriteDump() from your SEH excepti=
on
> handler. A minidump file can be loaded in Visual Studio later or elsewher=
e
> 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

On Jul 31, 10:32=A0am, Stuart <DerTop...@web.de> wrote:
> On Jul 30, Stuart wrote:
> [snip]
> =A0>> 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

In article <59oh181e65lt3452o3eoh1gr0lcsps1cc4@4ax.com>,
Mark  <y5ojlnx02@sneakemail.com> wrote:
>On Tue, 31 Jul 2012 21:39:26 +0200, Bo Persson <bop@gmb.dk> 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


 

Mark <i@dontgetlotsofspamanymore.invalid> writes:
>On Tue, 31 Jul 2012 17:49:51 -0500, BGB <cr88192@hotmail.com> wrote:
>
>>On 7/31/2012 3:25 PM, Scott Lurndal wrote:
>>> BGB <cr88192@hotmail.com> writes:
>>>> On 7/31/2012 9:20 AM, Scott Lurndal wrote:
>>>>> James Kanze <james.kanze@gmail.com> 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.

scott

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.

On 8/1/2012 9:04 AM, Scott Lurndal wrote:
> Mark <i@dontgetlotsofspamanymore.invalid> writes:
>> On Tue, 31 Jul 2012 17:49:51 -0500, BGB <cr88192@hotmail.com> wrote:
>>
>>> On 7/31/2012 3:25 PM, Scott Lurndal wrote:
>>>> BGB <cr88192@hotmail.com> writes:
>>>>> On 7/31/2012 9:20 AM, Scott Lurndal wrote:
>>>>>> James Kanze <james.kanze@gmail.com> 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).

BGB <cr88192@hotmail.com> writes:
>On 8/1/2012 9:04 AM, Scott Lurndal wrote:

>> 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, ...

  "already known to be valid" is the hard part.

>
  [[snip]]

>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).

In fact, the original shell written by Steven Bourne used SIGSEGV
to manage (grow) the shell heap.    While it worked (usually well), it
also exercised oddball architectures and new kernels in unusual
ways.  DAMHIKT.

>
>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).

Yes.

scott

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

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

On 8/1/2012 4:20 PM, James Kanze wrote:
> 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.
>

probably it wouldn't be "throwing" via using C++ exceptions directly 
within the signal handler, but probably rather via a different mechanism.

one possible strategy would be using siglongjmp to get out of the singal 
handler, and then throw at this point using a different 
exception-handling mechanism.

On Aug 1, 12:12=A0pm, yatremblay@bel1lin202.(none) (Yannick Tremblay)
wrote:
> In article <59oh181e65lt3452o3eoh1gr0lcsps1...@4ax.com>,
> Mark =A0<y5ojln...@sneakemail.com> wrote:
> >On Tue, 31 Jul 2012 21:39:26 +0200, Bo Persson <b...@gmb.dk> 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 be=
nign-
> >>>>> looking plus operator or even an absence of a statement can emit do=
zens
> >>>>> of instructions, due to operator overloading and constructors/destr=
uctors.
>
> >>>> 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.

the invisible ones are more worrisome IMHO. the operator overloading
"problem"
is a bit of a myth to my thinking.

> >>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. =A0However, 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. =A0It's not as if C++ was the only language
> offering operatior overloading. =A0Of 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. =A0C++ philosophy is to give good programmers the tools to
> write better programs. =A0Protection against B) is not built in the
> language.

I'm not sure it could be built into *any* language. If the language
is expressive enough to be useful then you give the programmer the
freedom to express things badly.

> 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.

In article <463a40dc-4461-48a5-9b50-c15155f2c7f6@a4g2000vbt.googlegroups.com>,
Nick Keighley  <nick_keighley_nospam@hotmail.com> wrote:
>On Aug 1, 12:12pm, yatremblay@bel1lin202.(none) (Yannick Tremblay)
>wrote:
>> 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.
>
>I'm not sure it could be built into *any* language. If the language
>is expressive enough to be useful then you give the programmer the
>freedom to express things badly.

Absolutely, no language can stop crap programmers writing crap code. 
Some languages are easier than other but the languages can only go so 
far.  Java excuse for not including operator overloading is very 
flimsy and I reckon invalid. Operator overloading allows a good
programmer to write code that is actually more maintainable contrary
to some claims by Java proponents.

A good programmer will use operator overloading for something like a
Matrix class and implement Matrix addition and multiplication as
overloaded operators.

This leads to clearer code:

Matrix a, b;
// populate a and b;
Matrix c = a + b;
Matrix d = a * b;

The above is clear, usable, maintainable.  Using a function named
"MatrixMult" or "MatrixAdd" would actually reduce the readability of
the code.


>> 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.

For example, a bad programmers will do silly things like:

class Rectangle
{
  //...
  Rectangle operator+(Rectangle &);
  Rectangle operator+(Point &);
  Rectangle operator+(Line &);
 //...

Rectangle a, b;
Point p;
Rectangle c = a + b;  // ??  WTF is adding 2 rectangles?
Rectangle d = a + p;  // ??  WTF is adding a point to a rectangle?

Whatever the bad programmer meant would be much clearer if he used
informative functions named something like 
Rectangle RetangleEnlarge(Rectangle &, int, int) or
Rectangle RectangleRelocate(Rectangle &, Point) or whatever is
actually intended but using the function name to make the code clear.  

But in the absence of operator overload, the bad programmer would
probably just of called the function Add(...).  In the absence of
function overloading, the bad programmer would probably have created
AddPoint(...) and AddRectangle(...)

So nothing a language can do.

Yannick

In article <pan.2012.08.01.17.22.07.318000@nowhere.com>,
Nobody  <nobody@nowhere.com> wrote:
>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.

I am finding it interesting and worrying that you are bunching
destructors with conversion operator like that.  

I am willing to agree that conversion operators have drawbacks that
may trump their benefits and that using ToInt(blah), ToString(foo) is
quite easy and make code clear.  However, removing destructors from
the language would definitely make the language worse.  They are one
of the most important thing in C++ and RAII is an fantastic tool to
make code higher quality, faster to write, easier to maintain.

Yannick

In article <jvchff$3rn$1@news.albasani.net>, BGB  <cr88192@hotmail.com> wrote:
>On 8/1/2012 4:20 PM, James Kanze wrote:
>> 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.
>>
>
>probably it wouldn't be "throwing" via using C++ exceptions directly 
>within the signal handler, but probably rather via a different mechanism.
>
>one possible strategy would be using siglongjmp to get out of the singal 
>handler, and then throw at this point using a different 
>exception-handling mechanism.

And close your eyes, put you fingers in your ears while signing loudly:
"THIS WILL WORK!  THIS WILL WORK! ..."

??

As mentinoned, signal handler are out of scope of C++ but this is well
documented that you should not try to do anything too fancy in a
signal handler.  It's potentially even worse in C++, your suggestion
would siglongjmp outside the previously executing function, all
automatics would not get destroyed potentially leading to very
undesireable consequences

Yannick

On Thu, 02 Aug 2012 13:38:06 +0000, yatremblay wrote:

> I am willing to agree that conversion operators have drawbacks that may
> trump their benefits and that using ToInt(blah), ToString(foo) is quite
> easy and make code clear.  However, removing destructors from the language
> would definitely make the language worse.  They are one of the most
> important thing in C++ and RAII is an fantastic tool to make code higher
> quality, faster to write, easier to maintain.

I'm not suggesting that destructors are a Bad Thing overall, just that
they're a pitfall. If you're going to write non-trivial destructors, it's
especially important that they're thread-safe, exception-safe and
otherwise devoid of surprises.

James Kanze wrote:

> On Tuesday, July 31, 2012 8:12:11 PM UTC+1, BGB 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. [...]
> 
> You cannot throw in a signal handler.  The results are undefined
> behavior.  And it doesn't reliably work on any platform I know.

What does then the following GCC option do? [1]

  -fnon-call-exceptions
    Generate code that allows trapping instructions to throw exceptions. 
    Note that this requires platform-specific runtime support that does 
    not exist everywhere. Moreover, it only allows trapping instructions 
    to throw exceptions, i.e. memory references or floating-point 
    instructions. It does not allow exceptions to be thrown from 
    arbitrary signal handlers such as SIGALRM. 

I know that this is not portable, and that this is not defined in the
C++ standard. (In this sense it is "undefined behavior", but this
doesn't mean that a given compiler and platform can't define it.)

This seems to indicate that GCC allows to throw an exception in a signal
handler for a SIGSEGV, at least on some platforms.

Or do I read this wrong?

Thanks,
Gerhard

[1] http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html

Gerhard Fiedler <gelists@gmail.com> writes:
>James Kanze wrote:
>
>> On Tuesday, July 31, 2012 8:12:11 PM UTC+1, BGB 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. [...]
>> 
>> You cannot throw in a signal handler.  The results are undefined
>> behavior.  And it doesn't reliably work on any platform I know.
>
>What does then the following GCC option do? [1]
>
>  -fnon-call-exceptions
>    Generate code that allows trapping instructions to throw exceptions. 
>    Note that this requires platform-specific runtime support that does 
>    not exist everywhere. Moreover, it only allows trapping instructions 
>    to throw exceptions, i.e. memory references or floating-point 
>    instructions. It does not allow exceptions to be thrown from 
>    arbitrary signal handlers such as SIGALRM. 
>
>I know that this is not portable, and that this is not defined in the
>C++ standard. (In this sense it is "undefined behavior", but this
>doesn't mean that a given compiler and platform can't define it.)
>
>This seems to indicate that GCC allows to throw an exception in a signal
>handler for a SIGSEGV, at least on some platforms.

James said "reliably".   It's likely that it would work properly when
catching a SIGFPE.  However, with SIGSEGV all bets are off, since the
unwind tables used during exception delivery could have been corrupted,
or some object referenced in the try/catch block may have been corrupted.

scott

On Thursday, August 2, 2012 5:57:15 PM UTC+1, Gerhard Fiedler wrote:
> James Kanze wrote:

> > On Tuesday, July 31, 2012 8:12:11 PM UTC+1, BGB 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. [...]

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

> What does then the following GCC option do? [1]

>   -fnon-call-exceptions
>     Generate code that allows trapping instructions to throw exceptions. 
>     Note that this requires platform-specific runtime support that does 
>     not exist everywhere. Moreover, it only allows trapping instructions 
>     to throw exceptions, i.e. memory references or floating-point 
>     instructions. It does not allow exceptions to be thrown from 
>     arbitrary signal handlers such as SIGALRM. 

> I know that this is not portable, and that this is not defined in the
> C++ standard. (In this sense it is "undefined behavior", but this
> doesn't mean that a given compiler and platform can't define it.)

> This seems to indicate that GCC allows to throw an exception in a signal
> handler for a SIGSEGV, at least on some platforms.

It does.  I'd be interested in seeing how they implement it.
And on what platforms it's supported.  

I suspect that the limitation to SIGSEGV is somehow linked to
the fact that you can't get a SIGSEGV at the critical moment,
after a successful call but before the necessary information has
been set up in the stack frame.  Which isn't true for Intel
boxes, I don't think.

And does it work for all sources of SIGSEGV?  Most Unix systems
I know convert stack overflow into SIGSEGV (which may mean that
you can't catch the signal).

Anyway, it's interesting information.  *Most* of the time, you
don't want to convert the signal into an exception---you want an
immediate core dump.  But for the rare times you do want the
exception...

-- 
James

On Thursday, August 2, 2012 7:01:20 PM UTC+1, Scott Lurndal wrote:
> Gerhard Fiedler <gelists@gmail.com> writes:

> >James Kanze wrote:

> >> On Tuesday, July 31, 2012 8:12:11 PM UTC+1, BGB 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. [...]

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

> >What does then the following GCC option do? [1]

> >  -fnon-call-exceptions
> >    Generate code that allows trapping instructions to throw exceptions. 
> >    Note that this requires platform-specific runtime support that does 
> >    not exist everywhere. Moreover, it only allows trapping instructions 
> >    to throw exceptions, i.e. memory references or floating-point 
> >    instructions. It does not allow exceptions to be thrown from 
> >    arbitrary signal handlers such as SIGALRM. 

> >I know that this is not portable, and that this is not defined in the
> >C++ standard. (In this sense it is "undefined behavior", but this
> >doesn't mean that a given compiler and platform can't define it.)

> >This seems to indicate that GCC allows to throw an exception in a signal
> >handler for a SIGSEGV, at least on some platforms.

> James said "reliably".   It's likely that it would work properly when
> catching a SIGFPE.  However, with SIGSEGV all bets are off, since the
> unwind tables used during exception delivery could have been corrupted,
> or some object referenced in the try/catch block may have been corrupted.

I think that there are some obvious restrictions; if the SIGSEGV
comes because you're memset'ing a local array, and you got the
count wrong by a couple of meg (overwriting *all* of the stack);
quite obviously, there's no way that they can make it work.  A
more interesting question is if the SIGSEGV is due to stack
overflow.

And while the traditional core dump is usually what you want,
there are exceptions where being able to catch it most of the
time is useful.

-- 
James

James Kanze <james.kanze@gmail.com> writes:
>On Thursday, August 2, 2012 5:57:15 PM UTC+1, Gerhard Fiedler wrote:
>> James Kanze wrote:
>
>> > On Tuesday, July 31, 2012 8:12:11 PM UTC+1, BGB 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. [...]
>
>> > You cannot throw in a signal handler.  The results are undefined
>> > behavior.  And it doesn't reliably work on any platform I know.
>
>> What does then the following GCC option do? [1]
>
>>   -fnon-call-exceptions
>>     Generate code that allows trapping instructions to throw exceptions. 
>>     Note that this requires platform-specific runtime support that does 
>>     not exist everywhere. Moreover, it only allows trapping instructions 
>>     to throw exceptions, i.e. memory references or floating-point 
>>     instructions. It does not allow exceptions to be thrown from 
>>     arbitrary signal handlers such as SIGALRM. 
>
>> I know that this is not portable, and that this is not defined in the
>> C++ standard. (In this sense it is "undefined behavior", but this
>> doesn't mean that a given compiler and platform can't define it.)
>
>> This seems to indicate that GCC allows to throw an exception in a signal
>> handler for a SIGSEGV, at least on some platforms.
>
>It does.  I'd be interested in seeing how they implement it.
>And on what platforms it's supported.  
>
>I suspect that the limitation to SIGSEGV is somehow linked to
>the fact that you can't get a SIGSEGV at the critical moment,
>after a successful call but before the necessary information has
>been set up in the stack frame.  Which isn't true for Intel
>boxes, I don't think.
>
>And does it work for all sources of SIGSEGV?  Most Unix systems
>I know convert stack overflow into SIGSEGV (which may mean that
>you can't catch the signal).

If you setup an alternate stack for signals (sigaltstack(2)),
you should be ok as far as catching the signal goes.

You likely cannot throw an exeception then since the alternate
stack starts with the signal handler activation record.  Siglongjmp
would work, but after the longjmp, you'd still have the problem
where you don't know _what_ corruption resulted in the SIGSEGV.


scott

Nobody <nobody@nowhere.com> wrote in
news:pan.2012.08.02.15.35.43.804000@nowhere.com: 
>
> I'm not suggesting that destructors are a Bad Thing overall, just that
> they're a pitfall. If you're going to write non-trivial destructors,
> it's especially important that they're thread-safe, exception-safe and
> otherwise devoid of surprises.

Thread-safety is easy, in a destructor one can assume no other threads are 
trying to access the object any more. If they do, this is a bug (as they 
will access a destroyed object), but the destructor cannot do anything 
about it, it's too late. So actually the destructor is one piece of code 
where one actually does not need to worry about thread-safety at all.

Cheers
Paavo

On Thu, 02 Aug 2012 17:56:51 -0500, Paavo Helde
<myfirstname@osa.pri.ee> wrote:

>Nobody <nobody@nowhere.com> wrote in
>news:pan.2012.08.02.15.35.43.804000@nowhere.com: 
>>
>> I'm not suggesting that destructors are a Bad Thing overall, just that
>> they're a pitfall. If you're going to write non-trivial destructors,
>> it's especially important that they're thread-safe, exception-safe and
>> otherwise devoid of surprises.
>
>Thread-safety is easy, in a destructor one can assume no other threads are 
>trying to access the object any more. If they do, this is a bug (as they 
>will access a destroyed object), but the destructor cannot do anything 
>about it, it's too late. So actually the destructor is one piece of code 
>where one actually does not need to worry about thread-safety at all.


What if the destructor in question is responsible for ending some
threads accessing the object being destroyed?

On Thu, 02 Aug 2012 18:13:27 -0500
Robert Wessel <robertwessel2@yahoo.com> wrote:

> On Thu, 02 Aug 2012 17:56:51 -0500, Paavo Helde
> <myfirstname@osa.pri.ee> wrote:
> 
> >Nobody <nobody@nowhere.com> wrote in
> >news:pan.2012.08.02.15.35.43.804000@nowhere.com: 
> >>
> >> I'm not suggesting that destructors are a Bad Thing overall, just
> >> that they're a pitfall. If you're going to write non-trivial
> >> destructors, it's especially important that they're thread-safe,
> >> exception-safe and otherwise devoid of surprises.
> >
> >Thread-safety is easy, in a destructor one can assume no other
> >threads are trying to access the object any more. If they do, this
> >is a bug (as they will access a destroyed object), but the
> >destructor cannot do anything about it, it's too late. So actually
> >the destructor is one piece of code where one actually does not need
> >to worry about thread-safety at all.
> 
> 
> What if the destructor in question is responsible for ending some
> threads accessing the object being destroyed?

thread joining in destructor was common practice...

On 8/2/2012 3:20 PM, Scott Lurndal wrote:
> James Kanze <james.kanze@gmail.com> writes:
>> On Thursday, August 2, 2012 5:57:15 PM UTC+1, Gerhard Fiedler wrote:
>>> James Kanze wrote:
>>
>>>> On Tuesday, July 31, 2012 8:12:11 PM UTC+1, BGB 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. [...]
>>
>>>> You cannot throw in a signal handler.  The results are undefined
>>>> behavior.  And it doesn't reliably work on any platform I know.
>>
>>> What does then the following GCC option do? [1]
>>
>>>    -fnon-call-exceptions
>>>      Generate code that allows trapping instructions to throw exceptions.
>>>      Note that this requires platform-specific runtime support that does
>>>      not exist everywhere. Moreover, it only allows trapping instructions
>>>      to throw exceptions, i.e. memory references or floating-point
>>>      instructions. It does not allow exceptions to be thrown from
>>>      arbitrary signal handlers such as SIGALRM.
>>
>>> I know that this is not portable, and that this is not defined in the
>>> C++ standard. (In this sense it is "undefined behavior", but this
>>> doesn't mean that a given compiler and platform can't define it.)
>>
>>> This seems to indicate that GCC allows to throw an exception in a signal
>>> handler for a SIGSEGV, at least on some platforms.
>>
>> It does.  I'd be interested in seeing how they implement it.
>> And on what platforms it's supported.
>>
>> I suspect that the limitation to SIGSEGV is somehow linked to
>> the fact that you can't get a SIGSEGV at the critical moment,
>> after a successful call but before the necessary information has
>> been set up in the stack frame.  Which isn't true for Intel
>> boxes, I don't think.
>>
>> And does it work for all sources of SIGSEGV?  Most Unix systems
>> I know convert stack overflow into SIGSEGV (which may mean that
>> you can't catch the signal).
>
> If you setup an alternate stack for signals (sigaltstack(2)),
> you should be ok as far as catching the signal goes.
>
> You likely cannot throw an exeception then since the alternate
> stack starts with the signal handler activation record.  Siglongjmp
> would work, but after the longjmp, you'd still have the problem
> where you don't know _what_ corruption resulted in the SIGSEGV.
>

in many/most cases, probably.

there are some cases though where one may know what caused it.

consider for example a person implementing a garbage collector which 
scans the stack. upon trying to read from a guard-page, then a signal 
may be generated, and can be fairly safely handled (the signal then 
essentially serving as an indication that the end of the stack being 
scanned has been reached). (whether or not this is a good way to 
implement stack-scanning in a GC is a secondary issue).

likewise, in such a scenario, recovering from a signal may be relatively 
safe (rather then in the general case, where a SIGSEGV or similar can be 
taken as an indication that something went wrong).

>A perfect language would generate an exception with a stacktrace upon an
>Access Violation, which is much more preferable to a Core Dump. For

Why? You can load the Core Dump with Visual Studio under Windows and
then you have stack traces of all threads running when the access
violation occured.



>generate such a dump when the exception is not caught (AFAIK, Win32 does 
>not offer a setting that generates dumps upon Access Violations).

The opposite is the case. Windows does generate dumps by default - always.
If no debugger is running the default debugger will be started.
- Either Dr. Watson or in newer versions of Windows Windows Error Reporting
  is started.
- On Blue Screens (core dumps) a mini dump file will be written

These applications can send dump files to a central server (application must 
be registered
by the developer for that), where they can be downloaded.
Optionally they can generated by calling a single Win API function or copied 
from the Windows
temporary directory, which is generated by Dr. Watson / WER (Windows Error 
Reporting).

>Thanks in advance,
>Stuart

Andre 

Robert Wessel <robertwessel2@yahoo.com> wrote in
news:192m18hi9cvllg358gmk82ok8pjcje57eu@4ax.com: 

> On Thu, 02 Aug 2012 17:56:51 -0500, Paavo Helde
> <myfirstname@osa.pri.ee> wrote:
> 
>>Nobody <nobody@nowhere.com> wrote in
>>news:pan.2012.08.02.15.35.43.804000@nowhere.com: 
>>>
>>> I'm not suggesting that destructors are a Bad Thing overall, just
>>> that they're a pitfall. If you're going to write non-trivial
>>> destructors, it's especially important that they're thread-safe,
>>> exception-safe and otherwise devoid of surprises.
>>
>>Thread-safety is easy, in a destructor one can assume no other threads
>>are trying to access the object any more. If they do, this is a bug
>>(as they will access a destroyed object), but the destructor cannot do
>>anything about it, it's too late. So actually the destructor is one
>>piece of code where one actually does not need to worry about
>>thread-safety at all. 
> 
> 
> What if the destructor in question is responsible for ending some
> threads accessing the object being destroyed?

Oh, you are right, this should work, and on the same time introduces 
extra complications regarding if the destructor is the one of the most 
derived object or not. Yeah, I should have known better than claiming 
that something is simple in C++ ;-)

Cheers
Paavo

On July 31, 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.

On 8/1/12 James Kanze wrote:
> 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.)

Actually, I'm relying heavily on the stack unwind, since this 
constitutes a kind of emergency stop procedure for me. The only 
alternative would be to create a separate stack with emergency stop 
actions that should be executed when an Access Violation occurs, but 
that would be equally cumbersome.

>> 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.

I totally agree. But I thought that if backtraces in exceptions will 
never make it into the standard, then core dumps will be out of the 
question.

So let me rephrase it: Ideally, I would like the language to dump when 
an Access Violation occurs (gives me all the information to debug the 
programming error later on), and then to unwind the stack (brings the 
measurement machine back into a defined state). Unfortunately, the C++ 
standard just says that upon Access Violations I will enter the land of UB.

I wonder how all those life-critical components for example in the 
medical or aviation business are written. Probably with some compiler 
that won't bust upon Access Violations. I mean, what good is a core dump 
when your plane is already cruising at an altitude of 10.000 feet?

Regards,
Stuart

On 8/3/12  Andre Kaufmann wrote:
> The opposite is the case. Windows does generate dumps by default - always.
> If no debugger is running the default debugger will be started.
> - Either Dr. Watson or in newer versions of Windows Windows Error Reporting
>   is started.
> - On Blue Screens (core dumps) a mini dump file will be written
>
> These applications can send dump files to a central server (application
> must be registered
> by the developer for that), where they can be downloaded.
> Optionally they can generated by calling a single Win API function or
> copied from the Windows
> temporary directory, which is generated by Dr. Watson / WER (Windows
> Error Reporting).

Gosh, I never even suspected such a thing. I think what fooled me into 
this belief is that the window that informs you about an Access 
Violation tells you that it wants to send some information to Microsoft 
but never even mentions that it generated a core dump file. Our 
workaround was to run the measurement application from the debugger, but 
that is not an option when the application should run in the field.

Thanks,
Stuart

On Fri, 2012-08-03, Stuart wrote:
....
> Actually, I'm relying heavily on the stack unwind, since this 
> constitutes a kind of emergency stop procedure for me. The only 
> alternative would be to create a separate stack with emergency stop 
> actions that should be executed when an Access Violation occurs, but 
> that would be equally cumbersome.
....
> So let me rephrase it: Ideally, I would like the language to dump when 
> an Access Violation occurs (gives me all the information to debug the 
> programming error later on), and then to unwind the stack (brings the 
> measurement machine back into a defined state).

There's possibly one non-C++ mechanism at play here.

If you're into controlling hardware (or other I/O not heavily
encapsulated by the OS) you often have OS mechanisms as a last resort.

E.g. if you control a flatbed scanner you want the light to go off and
the camera arm to move back to its parked position. A well-designed
device driver for that will see its file descriptor (in Unix) close as
the application crashes, and reset itself.  Placing responsibility for
the reset on the application would be a very bad idea.  Even if you
changed C++ so you could reliably do that before crashing, the device
could still not be safely used from C, Python, Perl, ...

> Unfortunately, the C++ 
> standard just says that upon Access Violations I will enter the land of UB.
>
> I wonder how all those life-critical components for example in the 
> medical or aviation business are written. Probably with some compiler 
> that won't bust upon Access Violations.

Such software must always rely on assumptions not found in the C++
standard, e.g. what the OS promises.  I think the situation would be
the same if you chose any other mainstream language.

> I mean, what good is a core dump 
> when your plane is already cruising at an altitude of 10.000 feet?

Ever watch Discovery Channel?  Lots of people are very interested in
finding out why a plane crashed.  I'm sure there are very detailed
requirements for this.

/Jorgen

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

On Thu, 02 Aug 2012 17:56:51 -0500, Paavo Helde wrote:

> So actually the destructor is one piece of code
> where one actually does not need to worry about thread-safety at all.

Other threads shouldn't be accessing the object being destroyed, but the
destructor may need to access referenced objects.

In theory, the issues can be dealt with by ensuring that all such accesses
are thread-safe (e.g. protected by a mutex). In practice, fine-grained
locking can have signicant performance costs, so it's not uncommon to seek
strategies to reduce this. Some of those strategies push the burden of
thread-safety onto callers, which may be problematic when calls are
implicit.

Robert Wessel <robertwessel2@yahoo.com> writes:
>On Thu, 02 Aug 2012 17:56:51 -0500, Paavo Helde
><myfirstname@osa.pri.ee> wrote:
>
>>Nobody <nobody@nowhere.com> wrote in
>>news:pan.2012.08.02.15.35.43.804000@nowhere.com: 
>>>
>>> I'm not suggesting that destructors are a Bad Thing overall, just that
>>> they're a pitfall. If you're going to write non-trivial destructors,
>>> it's especially important that they're thread-safe, exception-safe and
>>> otherwise devoid of surprises.
>>
>>Thread-safety is easy, in a destructor one can assume no other threads are 
>>trying to access the object any more. If they do, this is a bug (as they 
>>will access a destroyed object), but the destructor cannot do anything 
>>about it, it's too late. So actually the destructor is one piece of code 
>>where one actually does not need to worry about thread-safety at all.
>
>
>What if the destructor in question is responsible for ending some
>threads accessing the object being destroyed?

c_netport::~c_netport(void)
{
    ssize_t  diag;

    n_terminate = true;
    if (n_thread != pthread_self()) {
        // Trip the port thread off the poll(2) call.
        diag = write(n_cmd_pipe[1], &n_terminate, sizeof(n_terminate));
        if (diag != sizeof(n_terminate)) {
            n_logger->log("Unable to trigger netport thread"
                          " termination (%zd of %zu): %s\n",
                          diag, sizeof(n_terminate), strerror(errno));
        }
        pthread_join(n_thread, NULL);
    }

    if (n_connect_socket != -1) {
        (void) shutdown(n_connect_socket, SHUT_RDWR);
        (void) close(n_connect_socket);
        n_connect_socket = -1;
    }

    if (n_listen_socket != -1) {
        (void) close(n_listen_socket);
        n_listen_socket = -1;
    }

    (void) close(n_cmd_pipe[0]);
    (void) close(n_cmd_pipe[1]);

    pthread_mutex_destroy(&n_lock);
    pthread_cond_destroy(&n_wait);
}

On 8/3/2012 2:49 AM, Jorgen Grahn wrote:
> On Fri, 2012-08-03, Stuart wrote:
> ...
>> Actually, I'm relying heavily on the stack unwind, since this
>> constitutes a kind of emergency stop procedure for me. The only
>> alternative would be to create a separate stack with emergency stop
>> actions that should be executed when an Access Violation occurs, but
>> that would be equally cumbersome.
> ...
>> So let me rephrase it: Ideally, I would like the language to dump when
>> an Access Violation occurs (gives me all the information to debug the
>> programming error later on), and then to unwind the stack (brings the
>> measurement machine back into a defined state).
>
> There's possibly one non-C++ mechanism at play here.
>
> If you're into controlling hardware (or other I/O not heavily
> encapsulated by the OS) you often have OS mechanisms as a last resort.
>
> E.g. if you control a flatbed scanner you want the light to go off and
> the camera arm to move back to its parked position. A well-designed
> device driver for that will see its file descriptor (in Unix) close as
> the application crashes, and reset itself.  Placing responsibility for
> the reset on the application would be a very bad idea.  Even if you
> changed C++ so you could reliably do that before crashing, the device
> could still not be safely used from C, Python, Perl, ...
>

yeah. it also makes sense to try to design software so that it can 
recover from crashes.

usually, this often means explicit recover mechanisms, say the app can 
fix its data once it restarts, and generally avoid leaving data in a 
state where it will be "dead in the water" if a crash occurs.


drivers can often help here.

likewise, even a lot of hardware itself has its own safety mechanisms, 
usually in the form of on-device firmware, and sometimes via 
electromechanical mechanisms or similar, such as in the case of HDDs and 
similar (for example, if an HDD looses power, it will automatically park 
the heads, ...).

sadly, OS filesystem drivers and similar are often not as robustly 
designed, as damage in the right spot may often render the drive unable 
to recover (say, damage to the partition table / MBR, corruption of the 
boot-sector or other core filesystem structures, ...).

things like journals/... can help, but usually performance and low 
overhead are preferred over robustness, which is often left over to the 
HDD (which itself is left implementing things like ECC and 
sector-remapping, ..., at some cost to total drive capacity).


but, ultimately, I think this is also part of why file-based software 
(and OS's which does full reboots, and recompiling software from 
source-code, ...) are ultimately preferable to software based solely on 
"process images" and "living systems", since in this latter case, if 
something crashes or goes terribly wrong, there may be no recovery 
(whereas with a file-based system, in the worst case, assuming the HDD 
still works, a person can still recover all of their files from the 
drive, reinstall the OS and software, and get back to whatever they were 
doing).



>> Unfortunately, the C++
>> standard just says that upon Access Violations I will enter the land of UB.
>>
>> I wonder how all those life-critical components for example in the
>> medical or aviation business are written. Probably with some compiler
>> that won't bust upon Access Violations.
>
> Such software must always rely on assumptions not found in the C++
> standard, e.g. what the OS promises.  I think the situation would be
> the same if you chose any other mainstream language.
>
>> I mean, what good is a core dump
>> when your plane is already cruising at an altitude of 10.000 feet?
>
> Ever watch Discovery Channel?  Lots of people are very interested in
> finding out why a plane crashed.  I'm sure there are very detailed
> requirements for this.
>

I once saw an episode of Nova talking about a plane that crashed.
basically, something went wrong (wind speed sensor froze, started 
returning 0 wind-speed, causing control software to crash), the plane 
sent a crash dump back to the manufacturer over radio, and then the 
plane promptly crashed into the ocean.

the manufacturer later found the crash dump and this helped them 
identify why the plane crashed.

>Gosh, I never even suspected such a thing.

I still wonder why such a feature isn't communicated widely by Microsoft.

>but never even mentions that it generated a core dump file.

Yes, not directly. But there is a link in the lower half of the dialog,
"additional info" or "view attached files" or something like that.

If you click on that it will open a list with some files. One of these
files is the dump file (*.dmp).


Additionally since IIRC Windows Vista you can write a dump file
of an application by right clicking on it's entry in the task manager.


I've added a kind of live debugging feature to our application.
You can load directly a snapshot dump file from inside Visual Studio
over a http channel of our running application and debug for example 
deadlocks.

>Thanks,
>Stuart

Your welcome,
Andre

BGB wrote:

> On 8/2/2012 3:20 PM, Scott Lurndal wrote:
>> James Kanze <james.kanze@gmail.com> writes:
>>> On Thursday, August 2, 2012 5:57:15 PM UTC+1, Gerhard Fiedler wrote:
>>>> James Kanze wrote:
>>>
>>>>> On Tuesday, July 31, 2012 8:12:11 PM UTC+1, BGB 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. [...]
>>>
>>>>> You cannot throw in a signal handler.  The results are undefined
>>>>> behavior.  And it doesn't reliably work on any platform I know.
>>>
>>>> What does then the following GCC option do? [1]
>>>
>>>>    -fnon-call-exceptions
>>>>      Generate code that allows trapping instructions to throw exceptions.
>>>>      Note that this requires platform-specific runtime support that does
>>>>      not exist everywhere. Moreover, it only allows trapping instructions
>>>>      to throw exceptions, i.e. memory references or floating-point
>>>>      instructions. It does not allow exceptions to be thrown from
>>>>      arbitrary signal handlers such as SIGALRM.
>>>
>>>> I know that this is not portable, and that this is not defined in the
>>>> C++ standard. (In this sense it is "undefined behavior", but this
>>>> doesn't mean that a given compiler and platform can't define it.)
>>>
>>>> This seems to indicate that GCC allows to throw an exception in a signal
>>>> handler for a SIGSEGV, at least on some platforms.
>>>
>>> It does.  I'd be interested in seeing how they implement it.
>>> And on what platforms it's supported.
>>>
>>> I suspect that the limitation to SIGSEGV is somehow linked to
>>> the fact that you can't get a SIGSEGV at the critical moment,
>>> after a successful call but before the necessary information has
>>> been set up in the stack frame.  Which isn't true for Intel
>>> boxes, I don't think.
>>>
>>> And does it work for all sources of SIGSEGV?  Most Unix systems
>>> I know convert stack overflow into SIGSEGV (which may mean that
>>> you can't catch the signal).
>>
>> If you setup an alternate stack for signals (sigaltstack(2)),
>> you should be ok as far as catching the signal goes.
>>
>> You likely cannot throw an exeception then since the alternate
>> stack starts with the signal handler activation record.  Siglongjmp
>> would work, but after the longjmp, you'd still have the problem
>> where you don't know _what_ corruption resulted in the SIGSEGV.
>>
> 
> in many/most cases, probably. 
> 
> there are some cases though where one may know what caused it. 
> 
> consider for example a person implementing a garbage collector which
> scans the stack. upon trying to read from a guard-page, then a signal
> may be generated, and can be fairly safely handled (the signal then
> essentially serving as an indication that the end of the stack being
> scanned has been reached). (whether or not this is a good way to
> implement stack-scanning in a GC is a secondary issue). 
> 
> likewise, in such a scenario, recovering from a signal may be
> relatively safe (rather then in the general case, where a SIGSEGV or
> similar can be taken as an indication that something went wrong).

FWIW, it was such "controlled" segfaults of which I was thinking, not
the rogue type where you really don't know what and why.

I don't think it would work for SIGSEGVs because of stack overflow.
Either your stack is bad, or you're using a separate stack for signal
handlers, in which case it seems that the mechanism won't work.

I haven't yet found an answer to the platform support. (GCC
documentation only says "Note that this requires platform-specific
runtime support that does not exist everywhere.") If anybody happens to
have a pointer for documentation about the platform support of this
feature, I'd be grateful. 

Thanks,
Gerhard

On 8/4/2012 5:41 PM, Gerhard Fiedler wrote:
> BGB wrote:
>
>> On 8/2/2012 3:20 PM, Scott Lurndal wrote:
>>> James Kanze <james.kanze@gmail.com> writes:
>>>> On Thursday, August 2, 2012 5:57:15 PM UTC+1, Gerhard Fiedler wrote:
>>>>> James Kanze wrote:
>>>>
>>>>>> On Tuesday, July 31, 2012 8:12:11 PM UTC+1, BGB 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. [...]
>>>>
>>>>>> You cannot throw in a signal handler.  The results are undefined
>>>>>> behavior.  And it doesn't reliably work on any platform I know.
>>>>
>>>>> What does then the following GCC option do? [1]
>>>>
>>>>>     -fnon-call-exceptions
>>>>>       Generate code that allows trapping instructions to throw exceptions.
>>>>>       Note that this requires platform-specific runtime support that does
>>>>>       not exist everywhere. Moreover, it only allows trapping instructions
>>>>>       to throw exceptions, i.e. memory references or floating-point
>>>>>       instructions. It does not allow exceptions to be thrown from
>>>>>       arbitrary signal handlers such as SIGALRM.
>>>>
>>>>> I know that this is not portable, and that this is not defined in the
>>>>> C++ standard. (In this sense it is "undefined behavior", but this
>>>>> doesn't mean that a given compiler and platform can't define it.)
>>>>
>>>>> This seems to indicate that GCC allows to throw an exception in a signal
>>>>> handler for a SIGSEGV, at least on some platforms.
>>>>
>>>> It does.  I'd be interested in seeing how they implement it.
>>>> And on what platforms it's supported.
>>>>
>>>> I suspect that the limitation to SIGSEGV is somehow linked to
>>>> the fact that you can't get a SIGSEGV at the critical moment,
>>>> after a successful call but before the necessary information has
>>>> been set up in the stack frame.  Which isn't true for Intel
>>>> boxes, I don't think.
>>>>
>>>> And does it work for all sources of SIGSEGV?  Most Unix systems
>>>> I know convert stack overflow into SIGSEGV (which may mean that
>>>> you can't catch the signal).
>>>
>>> If you setup an alternate stack for signals (sigaltstack(2)),
>>> you should be ok as far as catching the signal goes.
>>>
>>> You likely cannot throw an exeception then since the alternate
>>> stack starts with the signal handler activation record.  Siglongjmp
>>> would work, but after the longjmp, you'd still have the problem
>>> where you don't know _what_ corruption resulted in the SIGSEGV.
>>>
>>
>> in many/most cases, probably.
>>
>> there are some cases though where one may know what caused it.
>>
>> consider for example a person implementing a garbage collector which
>> scans the stack. upon trying to read from a guard-page, then a signal
>> may be generated, and can be fairly safely handled (the signal then
>> essentially serving as an indication that the end of the stack being
>> scanned has been reached). (whether or not this is a good way to
>> implement stack-scanning in a GC is a secondary issue).
>>
>> likewise, in such a scenario, recovering from a signal may be
>> relatively safe (rather then in the general case, where a SIGSEGV or
>> similar can be taken as an indication that something went wrong).
>
> FWIW, it was such "controlled" segfaults of which I was thinking, not
> the rogue type where you really don't know what and why.
>
> I don't think it would work for SIGSEGVs because of stack overflow.
> Either your stack is bad, or you're using a separate stack for signal
> handlers, in which case it seems that the mechanism won't work.
>
> I haven't yet found an answer to the platform support. (GCC
> documentation only says "Note that this requires platform-specific
> runtime support that does not exist everywhere.") If anybody happens to
> have a pointer for documentation about the platform support of this
> feature, I'd be grateful.
>

I think GCC has this support on Linux and x86.

what little I am aware of is that GCC (often?) implements exception 
unwinding using a variant of the DWARF debug format, and by making calls 
to API functions. the API magic then proceeds basically to start 
unwinding call frames and restoring registers.

the uncertainty I have is regarding how Linux goes about transferring 
control to the signal handler. there is a certain possibility that 
control will pass through code which potentially lacks 
exception-handling data, at which case the behavior of the unwinding 
logic would be uncertain, though it is just as possible that the 
unwinding API could just as easily detect/handle this case specially 
(restoring the preserved state or similar, and resuming normal unwind 
behavior within the code which generated the signal).

granted, yes, even if it does work, it is probably not exactly portable, 
so other options may still be better.

I have not actually tried any of this personally though. most of my 
experience has more been with longjmp and Win32 SEH and implementing a 
"fake SEH" mechanism and similar (basically, unwinding via recursive 
longjmp), which are admittedly a bit different from using C++ exceptions.


or such...


> Thanks,
> Gerhard
>

On Monday, July 30, 2012 12:59:17 AM UTC-7, Stuart wrote:

> For example, I start to tend to favour Java over C++ because whenever I=
=20
>=20
> make some grave mistake and get a Memory Access Violation, this is more=
=20
>=20
> or less the end of the world for a C++ application. Java, in contrast,=20
>=20
> nicely captures this and gives me an exception. This not only makes me=20
>=20
> able to shut down gracefully, but also provides me with enough error=20
>=20
> information about where I went wrong (there is no standard way under C++=
=20
>=20
> to retrieve the stacktrace of an exception). I don't understand why such=
=20
>=20
> a feature is not important enough to make it into the C++ standard,=20
>=20
> while such gimmicks like lambdas and whatnot get huge attention.=20

To a great degree this kind of feature IS in the standard.  The vector 'at'=
 function for example throws an exception if bounds are violated.  This is =
all Java does.

The main difference here is that C++ doesn't impose this upon you.  The 'at=
' function is provided for times when you really need to do bounds checking=
 and other operations are provided for when you really do not.

I think the problem comes when people pay too much attention to the C part =
of C++.  Raw arrays and such are mostly a thing of the past in C++.  There'=
s no really good reason to use them outside of a backward compatibility sce=
nario.  I believe the library provided abstractions are even quite competit=
ive in the high-performance, micro-optimization niche.

On Aug 6, 6:45=A0pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> On Monday, July 30, 2012 12:59:17 AM UTC-7, Stuart wrote:
> > For example, I start to tend to favour Java over C++ because whenever I
>
> > make some grave mistake and get a Memory Access Violation, this is more
>
> > or less the end of the world for a C++ application. Java, in contrast,
>
> > nicely captures this and gives me an exception. This not only makes me
>
> > able to shut down gracefully, but also provides me with enough error
>
> > information about where I went wrong (there is no standard way under C+=
+
>
> > to retrieve the stacktrace of an exception). I don't understand why suc=
h
>
> > a feature is not important enough to make it into the C++ standard,
>
> > while such gimmicks like lambdas and whatnot get huge attention.
>
> To a great degree this kind of feature IS in the standard. =A0The vector =
'at' function for example throws an exception if bounds are violated. =A0Th=
is is all Java does.
>
> The main difference here is that C++ doesn't impose this upon you. =A0The=
 'at' function is provided for times when you really need to do bounds chec=
king and other operations are provided for when you really do not.
>
> I think the problem comes when people pay too much attention to the C par=
t of C++. =A0Raw arrays and such are mostly a thing of the past in C++. =A0=
There's no really good reason to use them outside of a backward compatibili=
ty scenario. =A0I believe the library provided abstractions are even quite =
competitive in the high-performance, micro-optimization niche.

low level programming? Interfacing to hardware?

On Mon, 6 Aug 2012 10:45:33 -0700 (PDT)
Noah Roberts <roberts.noah@gmail.com> wrote:
>I think the problem comes when people pay too much attention to the C part =
>of C++.  Raw arrays and such are mostly a thing of the past in C++.  There'=

Not if you do any low level or network programming. 

>nario.  I believe the library provided abstractions are even quite competit=
>ive in the high-performance, micro-optimization niche.

For quite competetive read not as fast as.

B2003

On Tue, 2012-08-07, boltar2003@boltar.world wrote:
> On Mon, 6 Aug 2012 10:45:33 -0700 (PDT)
> Noah Roberts <roberts.noah@gmail.com> wrote:
>>I think the problem comes when people pay too much attention to the C part =
>>of C++.  Raw arrays and such are mostly a thing of the past in C++.  There'=
>
> Not if you do any low level or network programming. 

OK, but there's no excuse not to isolate and encapsulate arrays so
they are largely invisible.  If you want potential buffer overflows
everywhere, you might as well use C.

>>nario.  I believe the library provided abstractions are even quite competit=
>>ive in the high-performance, micro-optimization niche.
>
> For quite competetive read not as fast as.

Given the beginner's mistake you did with std::set in another current
thread[0], your opinion doesn't have much weight yet.  Work with the
library for a year or so, and you may change your mind.

/Jorgen

[0] <jvr9u8$tgb$1@speranza.aioe.org>

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

Noah Roberts <roberts.noah@gmail.com> writes:
>To a great degree this kind of feature IS in the standard.  The vector 'at' function for example throws an exception if bounds are violated.  This is all Java does.
>The main difference here is that C++ doesn't impose this upon you.  The 'at' function is provided for times when you really need to do bounds checking and other operations are provided for when you really do not.

  It turns out that programmers are notoriously bad at
  estimating when bounds checking is needed. Otherwise, there
  would be far less buffer overrun exploits. Java can detect
  certain situations where it can statically prove that
  bounds checking is not needed and then omit dynamical bounds
  checking for those cases it. Some people are posting to a
  technical newsgroup and then can't even control their line
  lengths to be less than about 72.

On Tuesday, August 7, 2012 2:19:56 PM UTC-4, Jorgen Grahn wrote:

> 
> Given the beginner's mistake you did with std::set in another current
> 
> thread[0], your opinion doesn't have much weight yet.  Work with the
> 
> library for a year or so, and you may change your mind.
> 
> 

Perhaps he normally uses an alternative to ::std::set.  
I prefer Boost Intrusive's rbtree 

http://www.boost.org/doc/libs/1_50_0/doc/html/intrusive/set_multiset.html

to ::std::map or ::std::set.


Brian 
Ebenezer Enterprises
http://webEbenezer.net


I'm not endorsing Romney, but I hope people are
aware of what a loser Obama is by now.

Stefan Ram wrote:

> It turns out that programmers are notoriously bad at
> estimating when bounds checking is needed. Otherwise, there
> would be far less buffer overrun exploits. Java can detect
> certain situations where it can statically prove that
> bounds checking is not needed and then omit dynamical bounds
> checking for those cases it. Some people are posting to a
> technical newsgroup and then can't even control their line
> lengths to be less than about 72.

That's only a problem if your usenet client is buggy.  Meanwhile, there are 
plenty of usenet clients that were adequately developed, and therefore don't 
suffer from that limitation.


Rui Maciel

On Wed, 2012-08-08, Rui Maciel wrote:
> Stefan Ram wrote:
>
>> It turns out that programmers are notoriously bad at
>> estimating when bounds checking is needed. Otherwise, there
>> would be far less buffer overrun exploits. Java can detect
>> certain situations where it can statically prove that
>> bounds checking is not needed and then omit dynamical bounds
>> checking for those cases it. Some people are posting to a
>> technical newsgroup and then can't even control their line
>> lengths to be less than about 72.
>
> That's only a problem if your usenet client is buggy.  Meanwhile, there are 
> plenty of usenet clients that were adequately developed, and therefore don't 
> suffer from that limitation.

We have been through this a number of times before.  What you call a
"buggy" client is what others call "supports Usenet conventions and
netiquette". It's hard to do anything about that.

(That said, I wish SR hadn't brought Usenet length limits into a
completely unrelated discussion.)

/Jorgen

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

On 7 Aug 2012 18:19:56 GMT
Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>On Tue, 2012-08-07, boltar2003@boltar.world wrote:
>> On Mon, 6 Aug 2012 10:45:33 -0700 (PDT)
>> Noah Roberts <roberts.noah@gmail.com> wrote:
>>>I think the problem comes when people pay too much attention to the C part =
>>>of C++.  Raw arrays and such are mostly a thing of the past in C++.  There'=
>>
>> Not if you do any low level or network programming. 
>
>OK, but there's no excuse not to isolate and encapsulate arrays so
>they are largely invisible.  If you want potential buffer overflows
>everywhere, you might as well use C.

If you know the exact size of the data you're dealing with , eg a packet
header, then you won't get any buffer overflows because you'll only ever
read in that amount.

>> For quite competetive read not as fast as.
>
>Given the beginner's mistake you did with std::set in another current

What beginners mistake? I was quite well aware of the built in find() in
set, I'd just never used the standard version on it and was surprised it
wasn't optimised.

>thread[0], your opinion doesn't have much weight yet.  Work with the
>library for a year or so, and you may change your mind.

Thanks, I've been using it for 10 years or so. Go take your patronising
bullshit somewhere else.

B2003

On Thu, 2012-08-09, boltar2003@boltar.world wrote:
> On 7 Aug 2012 18:19:56 GMT
> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>>On Tue, 2012-08-07, boltar2003@boltar.world wrote:
>>> On Mon, 6 Aug 2012 10:45:33 -0700 (PDT)
>>> Noah Roberts <roberts.noah@gmail.com> wrote:
>>>>I think the problem comes when people pay too much attention to the C part =
>>>>of C++.  Raw arrays and such are mostly a thing of the past in C++.  There'=
>>>
>>> Not if you do any low level or network programming. 
>>
>>OK, but there's no excuse not to isolate and encapsulate arrays so
>>they are largely invisible.  If you want potential buffer overflows
>>everywhere, you might as well use C.
>
> If you know the exact size of the data you're dealing with , eg a packet
> header, then you won't get any buffer overflows because you'll only ever
> read in that amount.

The key here is "/if/ you know".  Usually you don't.

>>> For quite competetive read not as fast as.
>>
>>Given the beginner's mistake you did with std::set in another current
>
> What beginners mistake? I was quite well aware of the built in find() in
> set, I'd just never used the standard version on it and was surprised it
> wasn't optimised.

The "beginner's mistake" was to assume algorithms like std::find can
and will do anything clever.  Perhaps you're right: perhaps it's not
obvious that that won't happen.  It was obvious to /me/, but I can't
recall how I learned it.

>>thread[0], your opinion doesn't have much weight yet.  Work with the
>>library for a year or so, and you may change your mind.
>
> Thanks, I've been using it for 10 years or so. Go take your patronising
> bullshit somewhere else.

I was not trying to be patronizing.  I got the firm impression that
you hadn't used the standard library a lot.

/Jorgen

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

On Fri, 03 Aug 2012 12:49:15 -0500, BGB <cr88192@hotmail.com> wrote:

>I once saw an episode of Nova talking about a plane that crashed.
>basically, something went wrong (wind speed sensor froze, started 
>returning 0 wind-speed, causing control software to crash), the plane 
>sent a crash dump back to the manufacturer over radio, and then the 
>plane promptly crashed into the ocean.

I am horrified that this software was ever certified.  I used to work
on safety critical software for the aerospace industry.  All software
should be tested to see how it copes with sensor failure.  Generally
such systems will have multiple sensors and redundant
software/hardware that can still work even if significant parts stop
working.
-- 
(\__/)  M.
(='.'=) If a man stands in a forest and no woman is around
(")_(") is he still wrong?

Mark <i@dontgetlotsofspamanymore.invalid> writes:
>On Fri, 03 Aug 2012 12:49:15 -0500, BGB <cr88192@hotmail.com> wrote:
>
>>I once saw an episode of Nova talking about a plane that crashed.
>>basically, something went wrong (wind speed sensor froze, started 
>>returning 0 wind-speed, causing control software to crash), the plane 
>>sent a crash dump back to the manufacturer over radio, and then the 
>>plane promptly crashed into the ocean.
>
>I am horrified that this software was ever certified.  I used to work
>on safety critical software for the aerospace industry.  All software
>should be tested to see how it copes with sensor failure.

Air france AF 447; jun 2009.

>  Generally
>such systems will have multiple sensors and redundant
>software/hardware that can still work even if significant parts stop
>working.

However, see above.   The humans were the failure point.

scott

Use the right tool for the job. For certain use cases, although considerabl=
y less as time goes on, you need the low level features of C, C++, or Ada. =
JITs are getting so good, though, that for typical 32-bit programming, usin=
g C++ amounts to a micro-optimization. High level constructs like virtuals =
or exceptions are often better handled by a JIT.

That said, if you're a developer working on the JIT, you're probably going =
to be using C++. The language will always remain dominant for infrastructur=
al software. Another good area for C++ is embedded platforms. It's not a go=
od idea to run a JIT on a smartphone.

I'm sorry to say that "modern C++" is still not as safe as managed language=
s. Ref counting, for instance, is not as safe as GC. Programming is about t=
radeoffs. Would you take a 10% to 30% performance hit for an easier, safer =
development environment?

unnamed <zdsnyder@gmail.com> wrote:
> Use the right tool for the job. For certain use cases, although
> considerably less as time goes on, you need the low level features of C,
> C++, or Ada. JITs are getting so good, though, that for typical 32-bit
> programming, using C++ amounts to a micro-optimization. High level
> constructs like virtuals or exceptions are often better handled by a JIT.

Our products written in C++ are almost always faster than those of our
competitors (often written in Java) often by a factor of 100 or similar.
There are probably also other causes, but the language is surely one of
them.

> That said, if you're a developer working on the JIT, you're probably
> going to be using C++. The language will always remain dominant for
> infrastructural software. Another good area for C++ is embedded
> platforms. It's not a good idea to run a JIT on a smartphone.
> 
> I'm sorry to say that "modern C++" is still not as safe as managed
> languages. Ref counting, for instance, is not as safe as GC. Programming
> is about tradeoffs. Would you take a 10% to 30% performance hit for an
> easier, safer development environment?

We have almost never any problems with memory leaks, they are rather easy
to detect.
Actually from what I hear from Java programmers, they have more problems
with GC (GC pauses, nondeterminism) than we have with refcounting/manual
management. And those problems are not as easy to solve as memory leaks.

IMO, the biggest advantage of Java or .Net are not GC or managed code, but
the huge standard libraries.

Tobi

On Sunday, August 19, 2012 2:32:50 AM UTC+1, unnamed wrote:

> I'm sorry to say that "modern C++" is still not as safe as managed languages.
> Ref counting, for instance, is not as safe as GC.

Not using dynamic allocation at all can be safer than GC.  And while GC
can allow a higher degree of safety than other systems which manipulate
pointers, the code I've seen in Java and C# doesn't implement this
higher degree of safety (and you can use GC in C++, if you need it).

In the end, it depends on what you mean by safety.  If you're handling
web reqests on an open server, and you're worried about viruses, then GC
is a must, even in C++; you simply cannot run the risk of a block of
memory being reused as long as there are pointers around which refer to
it in it's previous use.  (Of course, this safety is really only useful
if you actively mark the memory as invalid, and crash the code if it is
accessed.)  For a lot of applications, however, C++ is far simpler and
safer than Java or C#.  (Overloaded operators and value semantics are
almost necessary for anything mathematical, for example.  You just
cannot do mathematical software in Java.)

-- 
James Kanze

On Sunday, August 19, 2012 6:54:56 AM UTC+1, Tobias M=FCller wrote:
> unnamed <zdsnyder@gmail.com> wrote:
>=20
> > Use the right tool for the job. For certain use cases, although
>=20
> > considerably less as time goes on, you need the low level features of C=
,
>=20
> > C++, or Ada. JITs are getting so good, though, that for typical 32-bit
>=20
> > programming, using C++ amounts to a micro-optimization. High level
>=20
> > constructs like virtuals or exceptions are often better handled by a JI=
T.
>=20
>=20
>=20
> Our products written in C++ are almost always faster than those of our
>=20
> competitors (often written in Java) often by a factor of 100 or similar.
>=20
> There are probably also other causes, but the language is surely one of
>=20
> them.
>=20
>=20
>=20
> > That said, if you're a developer working on the JIT, you're probably
>=20
> > going to be using C++. The language will always remain dominant for
>=20
> > infrastructural software. Another good area for C++ is embedded
>=20
> > platforms. It's not a good idea to run a JIT on a smartphone.
>=20
> >=20
>=20
> > I'm sorry to say that "modern C++" is still not as safe as managed
>=20
> > languages. Ref counting, for instance, is not as safe as GC. Programmin=
g
>=20
> > is about tradeoffs. Would you take a 10% to 30% performance hit for an
>=20
> > easier, safer development environment?
>=20
>=20
>=20
> We have almost never any problems with memory leaks, they are rather easy
>=20
> to detect.
>=20
> Actually from what I hear from Java programmers, they have more problems
>=20
> with GC (GC pauses, nondeterminism) than we have with refcounting/manual
>=20
> management. And those problems are not as easy to solve as memory leaks.
>=20
>=20
>=20
> IMO, the biggest advantage of Java or .Net are not GC or managed code, bu=
t
>=20
> the huge standard libraries.
>=20
>=20
>=20
> Tobi

On 19/08/2012 12:08, James Kanze wrote:
> In the end, it depends on what you mean by safety.  If you're handling
> web reqests on an open server, and you're worried about viruses, then GC
> is a must, even in C++; you simply cannot run the risk of a block of
> memory being reused as long as there are pointers around which refer to
> it in it's previous use.  (Of course, this safety is really only useful

You are seriously saying that all Internet servers must be implemented 
using GC due to the unsafeness of C++ pointers and viruses?  What utter 
nonsense.

/Leigh

On Sunday, August 19, 2012 4:32:50 AM UTC+3, unnamed wrote:
> Use the right tool for the job. For certain use cases, although considera=
bly less as time goes on, you need the low level features of C, C++, or Ada=
.. JITs are getting so good, though, that for typical 32-bit programming, us=
ing C++ amounts to a micro-optimization. High level constructs like virtual=
s or exceptions are often better handled by a JIT.

So the JIT handles your bugs well? So what? Even embedded debuggers are qui=
te good these days. When there are no bugs then it still loses 2 - 5 times =
of efficiency to well-written C++. It does not stop there. When the C++ guy=
 uses GPU for processing too then it is often orders of magnitude ahead.=20

>=20
> That said, if you're a developer working on the JIT, you're probably goin=
g to be using C++. The language will always remain dominant for infrastruct=
ural software. Another good area for C++ is embedded platforms. It's not a =
good idea to run a JIT on a smartphone.

For certain limited use cases scripts run fast enough. Even in embedded env=
ironment. So on these cases there are no need to burden with overhead from =
JIT compiler or the like just a lightweight script interpreter is fine.  Th=
at makes most powerful is code compiled to native instructions + script.=20

>=20
> I'm sorry to say that "modern C++" is still not as safe as managed langua=
ges. Ref counting, for instance, is not as safe as GC. Programming is about=
 tradeoffs. Would you take a 10% to 30% performance hit for an easier, safe=
r development environment?

As a developer or as end user? End user does not care about your developmen=
t environment at all. Why he should care how soft is your chair is or how l=
arge coffee mug you got?=20

The end user notices good performance. 10%-30% is the modern wishful thinki=
ng trend. In practice it is 200%-500%. Sure i can write trash Assembler tha=
t loses to Python but in reality best competes with best and rest of the sh=
it is dead.=20

So what mattes is how fast it starts, how fast it runs, how responsive it i=
s. It is end user's (life)time that the good performance saves. Native comp=
iled languages like C++ or C or Objective C are the winners. Nothing to do.=
 It is quite narrow market where performance does not matter. Like the free=
 Flash puzzle games for kids, (but Flash is again script not JIT AFAIK).

For some panicked marketroids (they can impact the minds of your bosses) it=
 is time-to-market that matters everything, despite (unless it is some sort=
 of short-term trend software) you can take the market over later by better=
 performing product anyway.

To please such marketroids it is still better to make a part of software us=
ing scripts (like Python) and rewrite them in version 2.0. Yes the scripts =
might reveal things to your competitors but also the JIT stuff is so easy t=
o reverse engineer that no much difference there.

If something is worth writing at all it is worth writing it in C++. If you =
really need GC, stack tracing or what not then just link a library that doe=
s it. There simply are no tricks or technologies that you can not use from =
C++ if you want that so much.

On Sunday, August 19, 2012 2:08:15 PM UTC+3, James Kanze wrote:
> On Sunday, August 19, 2012 2:32:50 AM UTC+1, unnamed wrote:
> 
> 
> 
> > I'm sorry to say that "modern C++" is still not as safe as managed languages.
> 
> > Ref counting, for instance, is not as safe as GC.
> 
> 
> 
> Not using dynamic allocation at all can be safer than GC.  And while GC
> 
> can allow a higher degree of safety than other systems which manipulate
> 
> pointers, the code I've seen in Java and C# doesn't implement this
> 
> higher degree of safety (and you can use GC in C++, if you need it).

Sometimes a jump in efficiency and safety can be gained by turning off
dynamic de-allocation and by multiprocessing. No special idioms needed like with GC versus ref-counting, just turn operator delete() or free() into NOP.

Have a separate process for highly demanding complex calculation, clone it for 
processing, pipe out the results and terminate for freeing all the resources at 
once. The highest peak of memory that such a process needs does not usually 
differ much if you free up memory on the way or not but it will be lot quicker
if you don't. 

Further advantage is that it is easier to measure the memory that is needed by 
a separate process. So it is simpler to learn to predict resource usage that
way and so to turn off dynamic allocation as well and it also allows to refuse
to take too demanding tasks before even starting those.

Such trick also scales very well since such processes can be later spread all 
over the farm when the problems grow and a single PC stops satisfying. I am not 
sure what Java or C# can offer as competition there, not too familiar with 
those.

On Sun, 19 Aug 2012 13:47:52 -0700 (PDT)
ootiib@hot.ee wrote:

> On Sunday, August 19, 2012 2:08:15 PM UTC+3, James Kanze wrote:
> > On Sunday, August 19, 2012 2:32:50 AM UTC+1, unnamed wrote:
> > 
> > 
> > 
> > > I'm sorry to say that "modern C++" is still not as safe as
> > > managed languages.
> > 
> > > Ref counting, for instance, is not as safe as GC.
> > 
> > 
> > 
> > Not using dynamic allocation at all can be safer than GC.  And
> > while GC
> > 
> > can allow a higher degree of safety than other systems which
> > manipulate
> > 
> > pointers, the code I've seen in Java and C# doesn't implement this
> > 
> > higher degree of safety (and you can use GC in C++, if you need it).
> 
> Sometimes a jump in efficiency and safety can be gained by turning off
> dynamic de-allocation and by multiprocessing. No special idioms
> needed like with GC versus ref-counting, just turn operator delete()
> or free() into NOP.
> 
That would be possible only if memory cannot be exhausted ;)

On Sun, 19 Aug 2012 04:08:15 -0700 (PDT)
James Kanze <james.kanze@gmail.com> wrote:

> On Sunday, August 19, 2012 2:32:50 AM UTC+1, unnamed wrote:
> 
> > I'm sorry to say that "modern C++" is still not as safe as managed
> > languages. Ref counting, for instance, is not as safe as GC.
> 
> Not using dynamic allocation at all can be safer than GC.  And while
> GC can allow a higher degree of safety than other systems which
> manipulate pointers, the code I've seen in Java and C# doesn't
> implement this higher degree of safety (and you can use GC in C++, if
> you need it).
> 
> In the end, it depends on what you mean by safety.  If you're handling
> web reqests on an open server, and you're worried about viruses, then
> GC is a must, even in C++;

Why?

 you simply cannot run the risk of a block
> of memory being reused as long as there are pointers around which
> refer to it in it's previous use.

Aha. You mean deallocating block of memory while still being used.
I think that's a bug in software. Does not happens usually...

Melzzzzz=E6=96=BC 2012=E5=B9=B48=E6=9C=8820=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=B8=80UTC+8=E4=B8=8A=E5=8D=885=E6=99=8219=E5=88=8626=E7=A7=92=E5=AF=AB=E9=
=81=93=EF=BC=9A
> On Sun, 19 Aug 2012 13:47:52 -0700 (PDT)
>=20
> ootiib@hot.ee wrote:
>=20
>=20
>=20
> > On Sunday, August 19, 2012 2:08:15 PM UTC+3, James Kanze wrote:
>=20
> > > On Sunday, August 19, 2012 2:32:50 AM UTC+1, unnamed wrote:
>=20
> > >=20
>=20
> > >=20
>=20
> > >=20
>=20
> > > > I'm sorry to say that "modern C++" is still not as safe as
>=20
> > > > managed languages.
>=20
> > >=20
>=20
> > > > Ref counting, for instance, is not as safe as GC.
>=20
> > >=20
>=20
> > >=20
>=20
> > >=20
>=20
> > > Not using dynamic allocation at all can be safer than GC.  And
>=20
> > > while GC
>=20
> > >=20
>=20
> > > can allow a higher degree of safety than other systems which
>=20
> > > manipulate
>=20
> > >=20
>=20
> > > pointers, the code I've seen in Java and C# doesn't implement this
>=20
> > >=20
>=20
> > > higher degree of safety (and you can use GC in C++, if you need it).
>=20
> >=20
>=20
> > Sometimes a jump in efficiency and safety can be gained by turning off
>=20
> > dynamic de-allocation and by multiprocessing. No special idioms
>=20
> > needed like with GC versus ref-counting, just turn operator delete()
>=20
> > or free() into NOP.
>=20
> >=20
>=20
> That would be possible only if memory cannot be exhausted ;)



Melzzzzz=E6=96=BC 2012=E5=B9=B48=E6=9C=8820=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=B8=80UTC+8=E4=B8=8A=E5=8D=885=E6=99=8219=E5=88=8626=E7=A7=92=E5=AF=AB=E9=
=81=93=EF=BC=9A
> On Sun, 19 Aug 2012 13:47:52 -0700 (PDT)
>=20
> ootiib@hot.ee wrote:
>=20
>=20
>=20
> > On Sunday, August 19, 2012 2:08:15 PM UTC+3, James Kanze wrote:
>=20
> > > On Sunday, August 19, 2012 2:32:50 AM UTC+1, unnamed wrote:
>=20
> > >=20
>=20
> > >=20
>=20
> > >=20
>=20
> > > > I'm sorry to say that "modern C++" is still not as safe as
>=20
> > > > managed languages.
>=20
> > >=20
>=20
> > > > Ref counting, for instance, is not as safe as GC.
>=20
> > >=20
>=20
> > >=20
>=20
> > >=20
>=20
> > > Not using dynamic allocation at all can be safer than GC.  And
>=20
> > > while GC
>=20
> > >=20
>=20
> > > can allow a higher degree of safety than other systems which
>=20
> > > manipulate
>=20
> > >=20
>=20
> > > pointers, the code I've seen in Java and C# doesn't implement this
>=20
> > >=20
>=20
> > > higher degree of safety (and you can use GC in C++, if you need it).
>=20
> >=20
>=20
> > Sometimes a jump in efficiency and safety can be gained by turning off
>=20
> > dynamic de-allocation and by multiprocessing. No special idioms
>=20
> > needed like with GC versus ref-counting, just turn operator delete()
>=20
> > or free() into NOP.
>=20
> >=20
>=20
> That would be possible only if memory cannot be exhausted ;)

OK, lets talk about programming in C++ with the container librariy.

Well, the results of the Fibnaci series, Fib(n) can not  be stored=20
in 32 or 64 bits except those trivial cases for novices.

But if I need to genenrate Fib(2000) in C++, then the long integer=20
part is not standardized in C++ aftr so manny years.

On Tuesday, August 7, 2012 12:38:04 AM UTC-7, Nick Keighley wrote:
> On Aug 6, 6:45=A0pm, Noah Roberts <roberts.n...@gmail.com> wrote:
>=20
> > On Monday, July 30, 2012 12:59:17 AM UTC-7, Stuart wrote:
>=20
> > > For example, I start to tend to favour Java over C++ because whenever=
 I
>=20
> >
>=20
> > > make some grave mistake and get a Memory Access Violation, this is mo=
re
>=20
> >
>=20
> > > or less the end of the world for a C++ application. Java, in contrast=
,
>=20
> >
>=20
> > > nicely captures this and gives me an exception. This not only makes m=
e
>=20
> >
>=20
> > > able to shut down gracefully, but also provides me with enough error
>=20
> >
>=20
> > > information about where I went wrong (there is no standard way under =
C++
>=20
> >
>=20
> > > to retrieve the stacktrace of an exception). I don't understand why s=
uch
>=20
> >
>=20
> > > a feature is not important enough to make it into the C++ standard,
>=20
> >
>=20
> > > while such gimmicks like lambdas and whatnot get huge attention.
>=20
> >
>=20
> > To a great degree this kind of feature IS in the standard. =A0The vecto=
r 'at' function for example throws an exception if bounds are violated. =A0=
This is all Java does.
>=20
> >
>=20
> > The main difference here is that C++ doesn't impose this upon you. =A0T=
he 'at' function is provided for times when you really need to do bounds ch=
ecking and other operations are provided for when you really do not.
>=20
> >
>=20
> > I think the problem comes when people pay too much attention to the C p=
art of C++. =A0Raw arrays and such are mostly a thing of the past in C++. =
=A0There's no really good reason to use them outside of a backward compatib=
ility scenario. =A0I believe the library provided abstractions are even qui=
te competitive in the high-performance, micro-optimization niche.
>=20
>=20
>=20
> low level programming? Interfacing to hardware?

Depends.  If you have a static, known size that cannot change and you want =
to use automatic variables then the C data types are a good response.  As s=
oon as there is variant size or you're allocating on the heap though it is =
better to have a class of some sort with RAII semantics.  In most cases, wi=
th any optimizations turned on at all, std::vector<char> is just as fast as=
 char[].

On Tuesday, August 7, 2012 6:02:08 AM UTC-7, (unknown) wrote:
> On Mon, 6 Aug 2012 10:45:33 -0700 (PDT)
> 
> Noah Roberts <roberts.noah@gmail.com> wrote:
> 
> >I think the problem comes when people pay too much attention to the C part =
> 
> >of C++.  Raw arrays and such are mostly a thing of the past in C++.  There'=
> 
> 
> 
> Not if you do any low level or network programming. 

I generally use std::vector<char> when using recv and std::string for send.
> 
> 
> 
> >nario.  I believe the library provided abstractions are even quite competit=
> 
> >ive in the high-performance, micro-optimization niche.
> 
> 
> 
> For quite competetive read not as fast as.

That's some poor reading comprehension skills.  Sometimes the C++ structure is actually faster.

On Monday, August 20, 2012 12:19:26 AM UTC+3, Melzzzzz wrote:
> On Sun, 19 Aug 2012 13:47:52 -0700 (PDT)
> 
> 
> > Sometimes a jump in efficiency and safety can be gained by turning off
> 
> > dynamic de-allocation and by multiprocessing. No special idioms
> 
> > needed like with GC versus ref-counting, just turn operator delete()
> 
> > or free() into NOP.
> 
> > 
> 
> That would be possible only if memory cannot be exhausted ;)

I explained *how* *that* *is* *mitigated* in the part that you snipped. Read again.

On Monday, August 20, 2012 6:44:53 PM UTC+3, Noah Roberts wrote:
> On Tuesday, August 7, 2012 12:38:04 AM UTC-7, Nick Keighley wrote:
> > On Aug 6, 6:45=A0pm, Noah Roberts <roberts.n...@gmail.com> wrote:
>=20
> > > I think the problem comes when people pay too much attention to the C=
 part of C++. =A0Raw arrays and such are mostly a thing of the past in C++.=
 =A0There's no really good reason to use them outside of a backward compati=
bility scenario. =A0I believe the library provided abstractions are even qu=
ite competitive in the high-performance, micro-optimization niche.
>=20
> >=20
> > low level programming? Interfacing to hardware?
>=20
> Depends.  If you have a static, known size that cannot change and you wan=
t to use automatic variables then the C data types are a good response.  As=
 soon as there is variant size or you're allocating on the heap though it i=
s better to have a class of some sort with RAII semantics.  In most cases, =
with any optimizations turned on at all, std::vector<char> is just as fast =
as char[].

There is std::array<T,N> now and has been boost::array<T,N> for long time f=
or static sized arrays. AFAIK those assert on out of limits in []() and thr=
ow on out of limits in at() like with vectors. When NDEBUG is defined then =
generated instructions for usage of a[n] are exactly same as with raw array=
..=20

On Sun, 2012-08-19, unnamed wrote:

> Use the right tool for the job. For certain use cases, although
> considerably less as time goes on, you need the low level features of
> C, C++, or Ada. JITs are getting so good, though, that for typical
> 32-bit programming, using C++ amounts to a micro-optimization.

What if I don't use C++ because I need extreme performance and
low-level things, but primarily because I believe it's a better
high-level language for expressing my design?

The low-level things are not the the main benefits of C++. If they
were, I'd use Python everywhere, since it has been fast enough for me
in 99% of all cases.

/Jorgen

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

Leigh Johnston wrote:

> You are seriously saying that all Internet servers must be implemented
> using GC due to the unsafeness of C++ pointers and viruses?  What utter
> nonsense.

I suspect he meant that GC is used by some programmers as an excuse to cover 
up their failure in putting in place a working memory management policy.


Rui Maciel

On Friday, July 27, 2012 9:03:27 PM UTC+2, Melzzzzz wrote:
> 
> When I changed this:
> 
>     public static void sum(int[] data) {
> 
> 		if(data.length == 0) return;
> 
> 		for( int i = 1; i !=  data.length; ++i)
> 
> 		  data[i] += data[i-1];
> 
> 	}
> 
> 
> 
> to this:
> 
> static void sum(std::vector<int>& data) {
> 
>                 if(data.empty()) return;
> 
>                 for( unsigned i = 0; i < data.size() - 1; ++i)
> 
>                   data[i+1] += data[i];
> 
>         }
> 

You didn't think that having the same result
was important?

On Fri, 24 Aug 2012 08:03:48 -0700 (PDT)
fungus <tooby@artlum.com> wrote:

> On Friday, July 27, 2012 9:03:27 PM UTC+2, Melzzzzz wrote:
> > 
> > When I changed this:
> > 
> >     public static void sum(int[] data) {
> > 
> > 		if(data.length == 0) return;
> > 
> > 		for( int i = 1; i !=  data.length; ++i)
> > 
> > 		  data[i] += data[i-1];
> > 
> > 	}
> > 
> > 
> > 
> > to this:
> > 
> > static void sum(std::vector<int>& data) {
> > 
> >                 if(data.empty()) return;
> > 
> >                 for( unsigned i = 0; i < data.size() - 1; ++i)
> > 
> >                   data[i+1] += data[i];
> > 
> >         }
> > 
> 
> You didn't think that having the same result
> was important?

I think that's equivalent...

On Sunday, August 19, 2012 10:21:26 PM UTC+1, Melzzzzz wrote:
> On Sun, 19 Aug 2012 04:08:15 -0700 (PDT)

> James Kanze <james.kanze@gmail.com> wrote:

> > On Sunday, August 19, 2012 2:32:50 AM UTC+1, unnamed wrote:

> > > I'm sorry to say that "modern C++" is still not as safe as managed
> > > languages. Ref counting, for instance, is not as safe as GC.

> > Not using dynamic allocation at all can be safer than GC.  And while
> > GC can allow a higher degree of safety than other systems which
> > manipulate pointers, the code I've seen in Java and C# doesn't
> > implement this higher degree of safety (and you can use GC in C++, if
> > you need it).

> > In the end, it depends on what you mean by safety.  If you're handling
> > web reqests on an open server, and you're worried about viruses, then
> > GC is a must, even in C++;

> Why?

> > you simply cannot run the risk of a block
> > of memory being reused as long as there are pointers around which
> > refer to it in it's previous use.

> Aha. You mean deallocating block of memory while still being used.

> I think that's a bug in software. Does not happens usually...

It's clearly an error in the software.  In practice, it happens
a lot.  There are well known techniques to exploit it.  (In
practice, they're not used that much, because the techniques to
exploit buffer overflow are easier, and that's another frequent
error.)

-- 
James Kanze