The Future of C++ ?

[Steven T. Hatton]

Steven T. Hatton:



Did you see the macros I wrote recently in another thread:

POST_IN_TERMS_OF
OP_IN_TERMS_OF
NON_CONST_IN_TERMS_OF

These macros are very handy, and they cut down on programmer time and
error.

What happens when somebody just happens to define something in a library you
include in your code that breaks your macros? It happens. I recently
spent many hours trying to figure out what was wrong with code I wrote
using macros from a library provider. I started out with a working
prototype based on example code. I modified the design making reasonable
changes which one should expect a programmer to make. Among those changes
was to remove certain header files which appeared to be superfluous, and
were not indicated in the documentation as essential to the feature I was
trying to implement. When I tried to compile the code, I got errors
telling me the macro wasn't being expanded. I located the macro definitions
in a header file with a name which seemed appropriate and included that in
my code. I could see the bloody macro definition right in front of my
eyes, and it was there in a file which I was pulling into the translation
unit. Nonetheless, the macro would not expand. After many hours of trying
reasonable approaches, I tried the brute force approach of simply copying
everything from the original working prototype I could possibly put in the
modified code. Among those elements was a header file which *should* *not*
have made a difference. Nonetheless, it *did* make a difference.

What is even more bizarre is that at one point, explicitly adding a default
constructor signature to a pure abstract base class caused the damn thing
to work!

I just checked a major project I was working with about a year ago because I
was going to use it as an example of what is wrong with macro madness.
Much to my pleasant surprise the macros are GONE! In many (dozens, perhaps
hundreds of) cases they have been replaced with templates.

I believe there is a place for "cookie cutter" code. What Cpp provides is a
means of crossing the boundary between code text, and compiled code. It is
a form of recursive self-reference, if you will pardon the redundancy.
That is actually a very powerful ability. Unfortunately it's provided by a
very weak tool.

This represents one of the most elegant (if the term can even be applied to
macros) uses of Cpp I've ever seen. I once took the entire thing and
turned it into normal source code with about 25 keystrokes using Emacs
regexp search and replace.

http://www.kdevelop.org/HEAD/doc/api/html/ast_8h-source.html

When I see macros, I consider the time I have spent trying to fix Cpp
related problems, and they never seem to have the potential for saving that
much time.

 

[Bo Persson]

All I can say is that Microsoft moves in mysterious ways their
wonders to perform.

I am intrigued as to why Microsoft released VC8.0 Express for free
though. I don't know why but speculating and first saying that
VC8.0 is a very capable C++ compiler with a lovely optimiser.

1) They want to introduce C++ coders to .Net.

They want to introduce everyone to .Net, so all the the Express compilers
are free.

2) They've given up on C++ and basically chucked VC8.0 like garbage
as their last C++ compiler.

No, they have really learned a lesson from their earlier free editions -
those without an optimizer. That earned them a "Microsoft compilers suck"
verdict.

3) gcc is free so they decided to compete on the same playing field.

Perhaps.


Bo Persson

 

[Steven T. Hatton]

Steven T. Hatton:



Are you five years old? '#' doesn't mean "preprocessor", never has and
never will. It's nothing more than a symbol which has different names in
different languages and dialects -- I myself call it the hash symbol.

From now on, when I say that there's a problem with '~', you can take it
to mean the mid-Atlantic currents.

Other than the one OOP programming course I took over a decade ago, and one
course in C I took even longer ago, I taught myself C++ starting about two
years ago. I believe I know it fairly well by now. I can say with
confidence and conviction that problems relating to Cpp were by far the
biggest obstacle, followed by problems related to linking. What I am
trying to tell anybody who is interested in what makes C++ hard to learn is
that the "real" language isn't the problem. Cpp is.

 

[Walter Bright]

For instance, let's say I'm driving fast, but there's a bend up ahead. I
want to get through that bend as quickly as possible. Driving an automatic,
I'll break as I approach the bend, then turn, then accelerate once I'm
through the turn. Driving a manual, I'll drop a gear as I approach the
bend, then the car will slow as I re-engage the engine dragging the revs
up, then I'll turn, then when I'm through the turn, I'll slip the clutch
and acclerate. The automatic method is certainly simpler, but the manual
method is far more efficient.

Using the engine to slow down the car is not efficient. It puts
excessive wear on the engine as unburned fuel in the cylinders will wash
the oil off the cylinder walls, causing more wear. It wastes fuel.

Use the brakes. That's what the darned things are for! They're a lot
cheaper to replace than the engine is.

Proper maximum performance turning technique is:

1) Brake as late as possible, and as hard as possible (just up to
locking, but not actually locking, the tires), just before turning the
wheel.

1.5) While braking, heel-toe double clutch to insert the transmission
into the right gear for the turn exit. Engage the clutch *before*
finishing braking, which also means 'feeling' the engine revs to match
up with the transmission speed so there is no slipping.

2) Turn the wheel while releasing the brake in a coordinated manner so
the turning force takes up where the braking force leaves off.

3) Keep constant pressure on the gas, adding or releasing pressure will
cause a slide.

4) After the apex, gradually straighten the wheel applying pressure to
the gas, again in a coordinated manner to keep constant pressure on the
wheels at just short of skidding.

There are some nuances to this to get even better performance once one
gets smooth at it. It takes a fair amount of practice to do it right,
though. Probably less than 0.1% of drivers can do it. That's why race
car drivers get paid the big bucks <g>.

 

[kwikius]

Using the engine to slow down the car is not efficient. It puts
excessive wear on the engine as unburned fuel in the cylinders will wash
the oil off the cylinder walls, causing more wear. It wastes fuel.

Unless of course, its an electric car. In which case the most efficient
way to brake is to use the motor as a dynamo to charge the batteries.
The software for which should obviously be written in C++ . And of
course the best way to save fuel is to drive sensibly, anticipating the
bend ahead well before you reach it. This saves both fuel and brake
wear. Again some suitable C++ software could be used to monitor the
optimum rate of decceleration for economy or even connected the cars
automatic navigation system to a satnav, so I can just sit back and
work on my C++ applications while my electric car automatically takes
me where I need to go.

BTW did you know we missed wombat day this year? :-(

regards
Andy Little

 

[kwikius]

BTW did you know we missed wombat day this year? :-(

Just so everyone doesnt forget next years wombat day:

http://www.wombania.com/wombats/index.htm

regards
Andy Little

 

[Frederick Gotham]

Walter Bright:

Using the engine to slow down the car is not efficient.

Not efficient in terms of what? Racing performance or car maintenance? It
slows the car down at an appropriate rate without using any energy. The
breaks, on the other hand, use energy.

It puts excessive wear on the engine as unburned fuel in the cylinders
will wash the oil off the cylinder walls, causing more wear. It wastes
fuel.

Actually, I think most cars cut off the petrol supply when they sense that:

(1) The accelerator isn't depressed.
(2) The revs are falling below minimum.

I've never heard of "cluth-engage braking" wearing the engine, no more so
than simply reving the engine.

Use the brakes. That's what the darned things are for! They're a lot
cheaper to replace than the engine is.

Actually, people who have driven both manual and automatic argue the exact
opposite: Breaks wear quicker in an automatic, and they're more expensive
to replace than a clutch. My own father drove an automatic for about a
decade, then a manual for about five years, and now he's back in an
automatic. He says that he spent much more money on maintenance for the
automatics, particularly the brakes.

Proper maximum performance turning technique is:

1) Brake as late as possible, and as hard as possible (just up to
locking, but not actually locking, the tires), just before turning the
wheel.

If the objective is to slow down _as_ _fast_ _as_ _possible_, then yes.
This method is a little extreme though if you're driving through a
neighourhood.

1.5) While braking, heel-toe double clutch to insert the transmission
into the right gear for the turn exit. Engage the clutch *before*
finishing braking, which also means 'feeling' the engine revs to match
up with the transmission speed so there is no slipping.

If I'm not mistaken, not even competitive drivers double-clutch anymore,
ever since the advent of synchromeshes in the gear box. I belive the "drop
a gear and engage the clutch dragging up the revs" braking method is
superior, as the revs are just at the right rate when you want to
accelerate out of the turn. If you need more stopping power, then you can
always push the brake at the same time.

2) Turn the wheel while releasing the brake in a coordinated manner so
the turning force takes up where the braking force leaves off.

Sounds good.

3) Keep constant pressure on the gas, adding or releasing pressure will
cause a slide.

Not too sure on this one. I did a race course there a little while ago, and
all I did was brake in a straight line, then release the brake and turn the
wheel. When through the apex of the turn, I hit the accelerator hard. (I
didn't hold on the accelerator going through the turn.)

4) After the apex, gradually straighten the wheel applying pressure to
the gas, again in a coordinated manner to keep constant pressure on the
wheels at just short of skidding.

I take it you don't do drifting

There are some nuances to this to get even better performance once one
gets smooth at it. It takes a fair amount of practice to do it right,
though. Probably less than 0.1% of drivers can do it. That's why race
car drivers get paid the big bucks <g>.

I don't think race car drivers do heal-toe or double-clutching anymore. As
far as I'm aware, it's best to take advantage of synchromeshes if they're
there.

In normal driving, the main advantages of "clutch-engage-drag-up-revs
braking" is that the brakes don't get worn, and that you're at a nice rev-
rate when you're exiting the turn.

In race driving, use of this braking method will help keep the brakes cool,
plus you'll be at a nice rev-rate when leaving the turn.

That said though, double-clutching is good fun. I used to do it... until I
needed a new clutch. I tried heal-toe braking one time but I nearly caused
an "accident".

I don't know the exact physics behind it, but I find that intentionally
slipping the clutch upon exiting a turn gives that extra little bit of
acceleration (might be something to do with torque but I don't know).

 

[Frederick Gotham]

Steven T. Hatton:

What happens when somebody just happens to define something in a library
you include in your code that breaks your macros? It happens.

What happens when someone hits their finger with a hammer? Do we stop
selling hammers?

I recently spent many hours trying to figure out what was wrong with code
I wrote using macros from a library provider. I started out with a
working prototype based on example code. I modified the design making
reasonable changes which one should expect a programmer to make. Among
those changes was to remove certain header files which appeared to be
superfluous, and were not indicated in the documentation as essential to
the feature I was trying to implement.

So why did you have these header files included in the first place?

When I tried to compile the
code, I got errors telling me the macro wasn't being expanded. I located
the macro definitions in a header file with a name which seemed
appropriate and included that in my code. I could see the bloody macro
definition right in front of my eyes, and it was there in a file which I
was pulling into the translation unit. Nonetheless, the macro would not
expand. After many hours of trying reasonable approaches, I tried the
brute force approach of simply copying everything from the original
working prototype I could possibly put in the modified code. Among
those elements was a header file which *should* *not* have made a
difference. Nonetheless, it *did* make a difference.

It didn't by any chance have:

#undef MY_SPECIAL_MACRO

What is even more bizarre is that at one point, explicitly adding a
default constructor signature to a pure abstract base class caused the
damn thing to work!

Sounds a little odd, I'd have to look at the code to see what's happening.

I just checked a major project I was working with about a year ago
because I was going to use it as an example of what is wrong with macro
madness. Much to my pleasant surprise the macros are GONE! In many
(dozens, perhaps hundreds of) cases they have been replaced with
templates.

I believe there is a place for "cookie cutter" code. What Cpp provides
is a means of crossing the boundary between code text, and compiled
code.

And it's very handy, as shown by my IN_TERMS_OF macros.

It is a form of recursive self-reference, if you will pardon the
redundancy. That is actually a very powerful ability. Unfortunately
it's provided by a very weak tool.

The preprocessor is just fine as far as I'm concerned. I just hope we get
Variable Length Argument List macros also.

This represents one of the most elegant (if the term can even be applied
to macros) uses of Cpp I've ever seen. I once took the entire thing and
turned it into normal source code with about 25 keystrokes using Emacs
regexp search and replace.

http://www.kdevelop.org/HEAD/doc/api/html/ast_8h-source.html

You should see some of the works of genius they churn out over on
comp.lang.c. Ever heard of IMAX_BITS?

When I see macros, I consider the time I have spent trying to fix Cpp
related problems, and they never seem to have the potential for saving
that much time.

I think they're great, C++ would be less of a language without them.

 

[Tony]

That's like saying you can't have proprietary databases because they
have to support standard SQL.

Not really, because the multi-billion dollar proprietary cow is pre-existing
and standardizing a GUI API threatens its existence. Other products based
upon the standard API would probably have to be successful in taking away
market share before MS would change Windows.

Tony

 

[Tony]

From: "kwikius" <[email protected]>
Newsgroups: comp.lang.c++
Subject: Re: The Future of C++ ?
Date: Tue, 28 Nov 2006 04:42:40 -0800



All I can say is that Microsoft moves in mysterious ways their wonders
to perform.

I am intrigued as to why Microsoft released VC8.0 Express for free
though.

Because they released it as cripple-ware in hopes that you'd upgrade to the
fully featured version.

Beyond the limited horizons of 'implementation defined' C++ though, I
have a funny feeling that the idea of a virtual machine is the way of
the future. Ultimately this is the power of Java and the Microsoft .Net
languages. and its attractive to me and its a standard with cross
platform and cross language libraries... and and.... ;-)

..Net standard and cross-platform??

Tony

 

[Tony]

No, that problem is not a problem that can be solved by other known means.

So how do you handle a constructor error without exceptions?

No, that's incorrect. Exceptions were adopted late in the standardization
process, that's true. But first, they weren't invented to support
constructors, nor vice versa, and second, they weren't invented in C++.
Experience with exceptions had been gained from Ada and other languages,
as well as at a low level in e.g. Windows NT. They fitted the
requirements of constructors, and no other scheme did.

I meant the reason why they were implemented in C++ (context counts).

Tony

 

[Tony]

A C++ course is neither a substitute for an
introduction to computer architecture nor a class on data structures and
algorithms.

The topics need not be taught separately though. It's up to the course
designer to decide what the scope will be. It could be a lot of C++ with
data structure examples sprinkled in (may as well learn something useful
while learning syntax) or it could be a lot of design with a little C++
as the implementation language. The latter being similar to books on
OO that give C++ examples but don't implement production-level code
because they are more concerned with the patterns than the language
idiosyncracies.

Tony

 

[Tony]

That might be a good name for a book...


"Implementing Standard C++"

"Accelerated C++" is a book that already works the vector problem above.

Tony

 

[Walter Bright]

Walter Bright:
Not efficient in terms of what? Racing performance or car maintenance?

Not efficient in terms of fuel usage, performance, dollars, or maintenance.

It
slows the car down at an appropriate rate without using any energy. The
breaks, on the other hand, use energy.

The brakes don't use energy, they disperse it.

Actually, I think most cars cut off the petrol supply when they sense that:

(1) The accelerator isn't depressed.
(2) The revs are falling below minimum.

Maybe some do. Most do not. Certainly, carbureted ones do not.

I've never heard of "cluth-engage braking" wearing the engine, no more so
than simply reving the engine.

Actually, people who have driven both manual and automatic argue the exact
opposite:
Breaks wear quicker in an automatic, and they're more expensive
to replace than a clutch. My own father drove an automatic for about a
decade, then a manual for about five years, and now he's back in an
automatic. He says that he spent much more money on maintenance for the
automatics, particularly the brakes.

Brake pads are $25 each, and you need 4. You can't touch a clutch job
for that. How you drive can also have a big impact on brake wear and
clutch wear. I usually get twice the life out of a clutch that "normal"
people do.

If the objective is to slow down _as_ _fast_ _as_ _possible_,

No, the objective is to get around the track as fast as possible.
Braking later and harder means your average speed is higher.

then yes.
This method is a little extreme though if you're driving through a
neighourhood.

Generally, you shouldn't be using maximum performance driving techniques
where kids are playing in the street.

If I'm not mistaken, not even competitive drivers double-clutch anymore,
ever since the advent of synchromeshes in the gear box.

A lot of racing trannies do not have synchros, as they are not needed
for competent drivers, and they are more complex and prone to failure.

I belive the "drop
a gear and engage the clutch dragging up the revs" braking method is
superior, as the revs are just at the right rate when you want to
accelerate out of the turn. If you need more stopping power, then you can
always push the brake at the same time.

You can believe whatever you want. But my information comes from:

1) mechanics who work on professional race cars
2) professional race car drivers
3) (1) and (2) who took the time to explain the physics of it to me
4) I have an undergraduate degree in mechanical engineering
5) I have taken cars completely apart and reassembled them, so I am very
familiar with how they work.

Your belief is a common one, but it is simply wrong. For one thing, the
engine does not add to the "stopping power". The stopping power is
limited by the grip of the tires on the pavement. The brakes can
*easily* exceed this. Using the engine in addition to the brakes causes
problems because the engine braking only happens on the rear wheels.
Brake pressures are very carefully 'biased' front to rear, throwing in
engine braking just on the rear will upset that, most likely causing the
back end to slide out from under you.

Not too sure on this one. I did a race course there a little while ago, and
all I did was brake in a straight line, then release the brake and turn the
wheel. When through the apex of the turn, I hit the accelerator hard. (I
didn't hold on the accelerator going through the turn.)

The problem is called "lift throttle oversteer", and I've done it. You
get a nice spin doing it.

I take it you don't do drifting

Drifting is something entirely different, and it is not about maximum
speed through a turn. Drifting is more of an art form. Drift cars are
deliberately set up to minimize weight on the back tires so they'll
slide easily.

In normal driving, the main advantages of "clutch-engage-drag-up-revs
braking" is that the brakes don't get worn, and that you're at a nice rev-
rate when you're exiting the turn.

In race driving, use of this braking method will help keep the brakes cool,

Brake overheating can be a problem with race cars, but this problem has
been solved by building better heat dispersing brakes.

plus you'll be at a nice rev-rate when leaving the turn.

Um, you put the car in the right gear to get the right rpms on turn
exit. That has nothing to do with using the engine to slow the car down.

That said though, double-clutching is good fun. I used to do it... until I
needed a new clutch.

Double clutching properly actually reduces the wear on the clutch (and
transmission).

I tried heal-toe braking one time but I nearly caused
an "accident".

Few can do it properly, and it takes a lot of practice. You shouldn't
practice it in traffic.

I don't know the exact physics behind it, but I find that intentionally
slipping the clutch upon exiting a turn gives that extra little bit of
acceleration (might be something to do with torque but I don't know).

Probably because your engine doesn't pull well at low revs, and slipping
the clutch gives you more revs. That's hard on the clutch, though, and
you might consider dropping a gear.

 

[Howard Hinnant]

Not efficient in terms of fuel usage, performance, dollars, or maintenance.


The brakes don't use energy, they disperse it.

<snip>

Ok, I have to put this into perspective.

I just got through reading a post here complaining that discussing
hash_map was off topic for comp.lang.c++ because it isn't in the
standard. Such a statement isn't what I would personally call rational,
but hey, everyone is entitled to their opinion. And it happens daily
here at comp.lang.c++. Over the years I've come to actually enjoy
reading such posts in a somewhat warped and twisted way. I've become
amused at what the next self-appointed moderator will claim as off
topic. Ok it's cheap entertainment, but better than reality TV.

Then I see this "future of C++" thread. Gee, that thread has been going
on forever. What could they possibly be discussing over there?!

Cars.

Not software in cars. Just driving techniques.

This isn't a flame on Walter. Walter is a great guy who I've personally
met (Hi Walter!). I'm just chuckling at the irony, and being off topic
myself.

-Howard

 

[Alf P. Steinbach]

* Tony:

So how do you handle a constructor error without exceptions?

You don't: you transform it to something else.

E.g., you can transform it to a fatal error (aborting the program), or
to a silent failure (ignoring further operations), or to a recurring
nightmare (e.g. popping up an error dialog box for every attempted
operation on the object), or most likely, you'll either transform it to
an initialization failure by using two-phase construction, where the
constructor no longer has a role to play, or, which may arise naturally
with two-phase construction, to a nest of bugs.

No matter which such course is taken the problem persists.

I meant the reason why they were implemented in C++ (context counts).

There were many reasons. In his paper "What is "Object-Oriented
Programming?"", mid 1986, Bjarne Stroustrup wrote

As programs grow, and especially when libraries are used extensively,
standards for handling errors (or more generally: "exceptional
circumstances") become important. Ada, Algol68, and Clu each support a
standard way of handling exceptions. Unfortunately, C++ does not.
Where needed exceptions are "faked" using pointers to functions,
"exception objects," "error states", and the C library signal and
longjmp facilities. This is not satisfactory in general and fails even
to provide a standard framework for error handling.

I pulled that quote from <url:
http://www.research.att.com/~bs/hopl2.pdf>, where he further writes that
"Exceptions were considered in the original design of C++, but were
postponed because there wasn't time to do a thorough job of exploring
the design and implementation issues. Exceptions were considered
essential for error handling in programs composed out of separately
designed libraries. The actual design of the C++ exception mechanism
stretched from 1984 to 1989."

Now go do your own research... ;-)

 

[Steven T. Hatton]

Steven T. Hatton:



What happens when someone hits their finger with a hammer? Do we stop
selling hammers?

If someone else hits my thumb with a hammer, that becomes a different story.
If I get hit by the head of a hammer because it fell off the handle, I'm
going to look into why that happened. If it happens repeatedly with the
same make of hammer, I'm going to go looking for a new kind of hammer.

So why did you have these header files included in the first place?

Because it was part of the sample code, and it is an "include everything"
file the library provider has taken to using in their implementation files.
It may be due to a suggestions in the Template book by van de Voorde and
Josuttis. Something I am now convinced was bad advice. I took it out
because I only want what is necessary to make my code work. That avoids
introducing hidden dependencies such as the one I discovered.

It didn't by any chance have:

#undef MY_SPECIAL_MACRO

The fix was not taking it out. It was putting it in. I really don't know
what it had in it. Ironically, I had opted for not going with the
bleedingest edge stuff for a change - reasoning that such problems would be
less likely. Well, they seem to have corrected it in the development
branch. They now have header files with sane names that work.

Sounds a little odd, I'd have to look at the code to see what's happening.

I wouldn't try to reproduce the problem if my life depended on it at this
point.

And it's very handy, as shown by my IN_TERMS_OF macros.

I like to see code written out in C++. I can understand that. Even if I
don't see everything relevant to the situation, I can usually get a pretty
good idea of what the possibilities are directly from the immediate code.
That simply doesn't work with Cpp.

The preprocessor is just fine as far as I'm concerned. I just hope we get
Variable Length Argument List macros also.

You probably also think vi should be used for more than fixing an emacs
build script in a pinch.

You should see some of the works of genius they churn out over on
comp.lang.c. Ever heard of IMAX_BITS?

I've attempted to read the GCC code. Some people might find it wonderful.
I found it painful. I can read Roberto's parser. I even wrote an XML tree
walker over it that dumped the AST to XML tags. I can't imagine there is
something significantly faster.

I think they're great, C++ would be less of a language without them.

I _know_ they make creating versatile and powerful development tools more
difficult. I also know that they cause a lot of problems for me and for
other people. It's often not even the number of problems they create that
incurs the real cost. It's the difficulty in identifying and solving the
problems they create. The make the language significantly harder to learn,
and they make it less pleasant to work with. Much of what is done with
macros can be done with templates, or native code. What I enjoy doing with
C++ is finding the one-liner that is both expressive to the human reader,
and ideal for solving a problem for which someone - perhaps me - has
written several lines of code.

If often take a fair amount of thinking and investigating what the
capabilities of the available constructs are. But I have found that I can
often reduce the size of a program significantly, while at the same time
make it more maintainable and flexible.

 

[Tony]

* Tony:

You don't: you transform it to something else.

E.g., you can transform it to a fatal error (aborting the program), or to
a silent failure (ignoring further operations), or to a recurring
nightmare (e.g. popping up an error dialog box for every attempted
operation on the object), or most likely, you'll either transform it to an
initialization failure by using two-phase construction, where the
constructor no longer has a role to play, or, which may arise naturally
with two-phase construction, to a nest of bugs.

No matter which such course is taken the problem persists.

What percentage of exceptions get handled anyway (that is, in a way
other than abort)?

There were many reasons. In his paper "What is "Object-Oriented
Programming?"", mid 1986, Bjarne Stroustrup wrote

[...]

Well why they were deemed most necessary then rather than all the
potential benefits.

Tony

 

[Alf P. Steinbach]

* Tony:

What percentage of exceptions get handled anyway (that is, in a way
other than abort)?

Try to do your own research.

There were many reasons. In his paper "What is "Object-Oriented
Programming?"", mid 1986, Bjarne Stroustrup wrote

[...]

Well why they were deemed most necessary then rather than all the
potential benefits.

Try to do your own research. I can suggest the D&E book. But I haven't
read it.

 

[Tony]

* Tony:

Try to do your own research.

The question was rhetorical.

Constructors weren't created as a result of exception handling, EH
was
created as a result of constructors.
No, that's incorrect. Exceptions were adopted late in the
standardization process, that's true. But first, they weren't
invented to support constructors, nor vice versa, and second, they
weren't invented in C++. Experience with exceptions had been gained
from Ada and other languages, as well as at a low level in e.g.
Windows NT. They fitted the requirements of constructors, and no
other scheme did.
I meant the reason why they were implemented in C++ (context counts).
There were many reasons. In his paper "What is "Object-Oriented
Programming?"", mid 1986, Bjarne Stroustrup wrote

[...]

Well why they were deemed most necessary then rather than all the
potential benefits.

Try to do your own research. I can suggest the D&E book. But I haven't
read it.

That wasn't a question (note the absence of any question mark).

Tony