Overloading on nothrow - C++ language, library and standards

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

Overloading on nothrow
Goto page 1, 2 Next

C++Talk.NET Forum Index -> C++ language, library and standards

View previous topic :: View next topic

Author

Message

Sergey P. Derevyago
Guest

Posted: Thu Aug 07, 2003 4:29 pm Post subject: Overloading on nothrow

mvitalo wrote:

Quote:

It would be nice to have a container class where the methods are
overloaded to throw or not, for example.

But I don't understand how you arrive here from the foregoing. How
would having such overloaded methods be useful (if it's even
possible)?

Having a container type that had methods overloaded on "nothrow" could
allow me to use the same container in kernel and user space components.

Sorry, you missed the point.

1. Suppose you have to write a function template:

template<class T> void f(T t)
{
// ...
}

2. And you call t.g() inside f():

template<class T> void f(T t)
{
// ...
t.g();
// ...
}

3. And your implementation substantively depends on the fact whether t.g()
throws. I.e. you have a bulk general case algorithm_1 (that has to cope with
exceptions) and an "optimal" algorithm_2 (which is free to be fast).

4. Then you define two versions of f() overloaded on nothrow:

template<class T> void f(T t)
{
algorithm_1
}

and

template<class T> void f(T t) nothrow
{
algorithm_2
}

5. Well, that's all: say compiler can pick algorithm_1 for f<string>() and
algorithm_2 for f<int>().

6. For example:

template <class T>
class StrictlyRelatedPair {
T a;
T b;

// general case with strong guarantee
StrictlyRelatedPair& operator=(const StrictlyRelatedPair& other)
{
StrictlyRelatedPair tmp(other);
this->swap(tmp);
return *this;
}

// lightweight version in the case of T& operator=(const T&) nothrow
StrictlyRelatedPair& operator=(const StrictlyRelatedPair& other) nothrow
{
a=other.a;
b=other.b;
return *this;
}
};

--
With all respect, Sergey. http://cpp3.virtualave.net/
mailto : ders at skeptik.net

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Bob Bell
Guest

Posted: Wed Aug 13, 2003 1:41 pm Post subject: Re: Overloading on nothrow

"Sergey P. Derevyago" <non-existent (AT) iobox (DOT) com> wrote

[snip]

Quote:

4. Then you define two versions of f() overloaded on nothrow:

template<class T> void f(T t)
{
algorithm_1
}

and

template<class T> void f(T t) nothrow
{
algorithm_2
}

SomeType foo;

f(foo);

Which f does the compiler choose?

[snip]

Quote:

6. For example:

template <class T
class StrictlyRelatedPair {
T a;
T b;

// general case with strong guarantee
StrictlyRelatedPair& operator=(const StrictlyRelatedPair& other)
{
StrictlyRelatedPair tmp(other);
this->swap(tmp);
return *this;
}

// lightweight version in the case of T& operator=(const T&) nothrow
StrictlyRelatedPair& operator=(const StrictlyRelatedPair& other) nothrow
{
a=other.a;
b=other.b;
return *this;
}
};

StrictlyRelatedPair<Foo, Bar> x, y;

x = y;

Which operator= does the compiler choose?

Bob

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Sergey P. Derevyago
Guest

Posted: Thu Aug 14, 2003 1:29 am Post subject: Re: Overloading on nothrow

Bob Bell wrote:

Quote:

4. Then you define two versions of f() overloaded on nothrow:

template<class T> void f(T t)
{
algorithm_1
}

and

template<class T> void f(T t) nothrow
{
algorithm_2
}

SomeType foo;

f(foo);

Which f does the compiler choose?

It depends on the signature of SomeType::g(), i.e.

void SomeType::g();

or

void SomeType::g() nothrow;

Please note that non-template SomeType shall have only one g() which is
definitely nothrow or not, while template class SomeType (and/or template
SomeType::g()) is allowed to have both versions overloaded on nothrow.

PS The statically checked nothrow specification was described by me several
times. For example
http://groups.google.com/groups?ie=UTF-8&oe=UTF-8&selm=3A5887F9.6CFCFFD7%40iobox.com
-----------------------------------8<-----------------------------------
IMHO compiler needs exactly one answer: whether function can throw. It doesn't
matter _what_ it gonna throw. So it seems like a nothrow keyword would be
much more useful. Consider:

1.
// f can throw what it wants
void f()
{
// ...
}

2.
// f is not allowed to throw (checked at compile time)
void f() nothrow
{
// ...
}

3.
void f()
{
// ...

nothrow { // you can't throw in this scope (checked at compile time)

// ...

}

// ...
}

IMHO with nothrow clauses and blocks one can easily create exception-safe
code, which is a nightmare in current C++.
-----------------------------------8<-----------------------------------
With all respect, Sergey. http://cpp3.virtualave.net/
mailto : ders at skeptik.net

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Bob Bell
Guest

Posted: Thu Aug 14, 2003 12:23 pm Post subject: Re: Overloading on nothrow

"Sergey P. Derevyago" <non-existent (AT) iobox (DOT) com> wrote

Quote:

Bob Bell wrote:
4. Then you define two versions of f() overloaded on nothrow:

template<class T> void f(T t)
{
algorithm_1
}

and

template<class T> void f(T t) nothrow
{
algorithm_2
}

SomeType foo;

f(foo);

Which f does the compiler choose?

It depends on the signature of SomeType::g(), i.e.

void SomeType::g();

or

void SomeType::g() nothrow;

What's so special about SomeType::g()? In particular, as the one who
wants to call f with a SomeType object, I know there are two functions
available:

template<class T> void f(T t);
template<class T> void f(T t) nothrow;

Why does SomeType::g() come into it? How am I to know (looking at
these declarations of f()) that SomeType::g() is the determining
function and not SomeType::h()?

If SomeType::g() is the special function (presumably because it's
being used somewhere inside f()), what happens if f's implementation
changes in the future and now calls SomeType::h() instead/as well? If
SomeType::g() is nothrow, but SomeType::h() isn't for some reason,
then the next build will silently switch from the non throwing f() to
the throwing f(). This kind of silent change seems pretty bad.
(Although if the throw/nothrow thing is checked statically, as you
suggest later, maybe it's not a silent change. But static checking has
its own problems, from what I understand.)

In any case, if the compiler makes its choice based on the set of
SomeType functions that are called within f(), that means that the
overloading won't work unless the compiler has access to the
implementation of f(). This may be a problem with exported templates,
but I'm not an implementer so I'm not sure. (Later in your post you
rule out overloading on nothrow with non-template functions, if I read
correctly, so only template functions need to be considered.)

Unless I'm missing something (which happens more often than I'd like
to admit), it seems that this kind of "overload on nothrow" is very
different from ordinary overloading. With ordinary overloading, the
function signature of the overloaded function is all you need to see
to predict which overload will be called with a given set of
arguments. With overload on nothrow, you need to know not only the
function signature, but _how_ those types are used within the function
to predict which overload will be selected. This means that the
interface (in terms of which function gets called) has a dependency on
the implementation, and seems like a loss of encapsulation.

I kind of like the idea of overloading on nothrow, but this seems to
be a big problem, and anyway, others have asked for examples of
problems that can be solved with it, and no convincing answers have
been given.

Bob
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Sergey P. Derevyago
Guest

Posted: Fri Aug 15, 2003 4:34 am Post subject: Re: Overloading on nothrow

Bob Bell wrote:

Quote:

What's so special about SomeType::g()?

It seems like you haven't read my message. The corresponding snippet is:

-----------------------------------8<-----------------------------------
2. And you call t.g() inside f():

template {
// ...
t.g();
// ...
}

3. And your implementation substantively depends on the fact whether t.g()
throws. I.e. you have a bulk general case algorithm_1 (that has to cope with
exceptions) and an "optimal" algorithm_2 (which is free to be fast).
-----------------------------------8<-----------------------------------

Quote:

2. It trys to instantiate f<SomeType>() specialization:

2.1. It trys to instantiate f<SomeType>() nothrow version. If the body of
f<SomeType>() specialization throws it will try the second version:

2.2. It trys to instantiate f<SomeType>() plain version.
--
With all respect, Sergey. http://cpp3.virtualave.net/
mailto : ders at skeptik.net

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Sergey P. Derevyago
Guest

Posted: Fri Aug 22, 2003 4:41 pm Post subject: Re: Overloading on nothrow

[I've sent this reply on Fri, 15 Aug 2003 but it seems like it was lost]

James Kuyper wrote:

Quote:

The way C++ currently works, all you need to determine which overload
of f() to use is the declaration of f(), and the declarations of the
types which are passed to it as arguments.
Not, really.

I propose to overload a _template_ f(). And even in current C++ you
have to do a huge amount of work in order to figure out what exactly will be
the result of f<>((SomeType)st) call: specializations, traits and so on must
be taken into the consideration.
--
With all respect, Sergey. http://cpp3.virtualave.net/
mailto : ders at skeptik.net

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Bob Bell
Guest

Posted: Fri Aug 22, 2003 4:41 pm Post subject: Re: Overloading on nothrow

"Sergey P. Derevyago" <non-existent (AT) iobox (DOT) com> wrote

Quote:

Bob Bell wrote:
What's so special about SomeType::g()?

It seems like you haven't read my message. The corresponding snippet is:
-----------------------------------8<-----------------------------------
2. And you call t.g() inside f():

template {
// ...
t.g();
// ...
}

3. And your implementation substantively depends on the fact whether t.g()
throws. I.e. you have a bulk general case algorithm_1 (that has to cope with
exceptions) and an "optimal" algorithm_2 (which is free to be fast).
-----------------------------------8<-----------------------------------

It seems you missed my point. From the interface of f no way for me to deduce that SomeType::g() must be nothrow in order
for the overload resolution to pick the non-throwing version of
f<T>(). The interface may be all I have, if the f<T>() is an exported
template.

Quote:

If SomeType::g() is the special function (presumably because it's
being used somewhere inside f()), what happens if f's implementation
changes in the future and now calls SomeType::h() instead/as well?

1. Compiler sees two versions of f<>() overloaded on nothrow.

2. It trys to instantiate f<SomeType>() specialization:

2.1. It trys to instantiate f<SomeType>() nothrow version. If the body of
f<SomeType>() specialization throws it will try the second version:

2.2. It trys to instantiate f<SomeType>() plain version.

You also seem to have missed my point about silent changes to the
meaning of my code, as well as the point about this being a new kind
of overloading that depends on the implementation of the overloaded
function.

Bob

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Bob Bell
Guest

Posted: Sun Aug 31, 2003 1:40 am Post subject: Re: Overloading on nothrow

"Sergey P. Derevyago" <non-existent (AT) iobox (DOT) com> wrote

Quote:

Bob Bell wrote:
It seems you missed my point. From the interface of f<T>(), there is
no way for me to deduce that SomeType::g() must be nothrow in order
for the overload resolution to pick the non-throwing version of
f<T>(). The interface may be all I have, if the f<T>() is an exported
template.

Well, it doesn't really matter whether SomeType::g() throws. The overloading
on nothrow is a powerful feature. And just like every powerful feature it can
be _mis_used. In particular, your example is about how _not_ to use it.

This isn't my example, it's yours; I just asked a question about it.
You were the one that said that for overload resolution to pick the
nonthrowing f<T>, T::g() must be nothrow. How can I, as someone who
wants to use f<T>, know that?

Unless I can read the source code (which I may not be able to do), I
can't know that. Which means that I don't know how to write SomeType
so that instantiating f<SomeType> will pick the nothrow version. So
how can I use this feature?

Overload on nothrow changes the meaning of overloading significantly:
it means that overload resolution would depend on the implementation
of the overloaded functions. I don't see this as an improvement at
all. I see it as creating inappropriate dependencies between my code
and the implementations of the functions I call -- as demonstrated by
your example, where the precise version of f<T> I call depends on how
f<T> is implemented.

Quote:

Sometimes you have a template<class T> YourClass<T> and you know that
YourClass<SomeType> "doesn't throw" if corresponding methods of SomeType don't
throw.

Note that this guideline won't help the user of f<T> in your example.

Quote:

Via the overloading on nothrow you can tell your users (actually, you tell it
to the C++ type system) that YourClass<SomeType>::f() is a nothrow function.
Without this feature _all_ specializations of YourClass will be "canthrow"
(from the C++ type system POV) despite the fact that some of them can't really
throw and this can be unambiguously deduced at compile time.

I don't tell that the overloading on nothrow can't be misused. I does tell
that it improves C++ type system when used correctly (and it's not so hard to
get it rigth).

I remain unconvinced. I haven't seen any serious discussion of the
problems for which overload on nothrow is a solution. What is the
problem? How often does it come up in real code? What are the
workarounds, if any, and how error-prone are they? What side-effects
does the proposed solution have (e.g, how does it relate to name
lookup)? Given that the changes to overload resolution are so
significant (especially considering the problems it introduces), I
would expect correspondingly significant answers to these questions,
but so far I haven't seen any.

Bob

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Bob Bell
Guest

Posted: Sun Aug 31, 2003 1:40 am Post subject: Re: Overloading on nothrow

"Sergey P. Derevyago" <non-existent (AT) iobox (DOT) com> wrote

Quote:

Bob Bell wrote:
It seems you missed my point. From the interface of f<T>(), there
is
no way for me to deduce that SomeType::g() must be nothrow in
order
for the overload resolution to pick the non-throwing version of
f<T>(). The interface may be all I have, if the f<T>() is an
exported
template.

Well, it doesn't really matter whether SomeType::g() throws.
The overloading
on nothrow is a powerful feature. And just like every powerful
feature it can
be _mis_used. In particular, your example is about how _not_ to use
it.

It wasn't my example, it was yours. You gave the example of f<T>()'s
overload resolution depending on whether or not T::g() throws. My
question is, how can I know, seeing the _declaration_ of f<T>(), that
T::g() is the member of T that discriminates between throwing and
non-throwing f<T>()?

Of course, the answer is I can't know that. Nothing about the
declaration of f<T>() tells me that T::g() is the discriminating
member. The only way I can tell is if I can look at the _definition_
of f<T>(), which I may not be able to see (e.g., if the f<T>() is an
exported template).

Also, this situation is quite different from today's use of templates.
With today's templates, if I try to call f<T>(), and internally f<T>()
calls T::g(), and there is no T::g(), I get a compiler error. Either
it compiles, or it doesn't, and if it compiles, the function that gets
called is determined wholly by the interface of the available
f<T>()'s. The fact that T::g() is called does not play any part in
_which_ f<T>() gets called. You are proposing to change that, and I
think that's a mistake.

Quote:

Sometimes you have a template<class T> YourClass<T> and you
know that
YourClass<SomeType> "doesn't throw" if corresponding methods of
SomeType don't
throw.

Note that this guideline wouldn't have helped the programmer who wants
to call f<T>() above.

Quote:

I understand what you want, but it doesn't seem to be as simple as you
think. Consider this example:

template<typename T>
void F() nothrow
{
// ...
Foo();
// ...
}

template<typename T>
void F()
{
// ...
Foo();
// ...
}

Suppose no operation of X throws any exception, and I call

f<X>();

It seems to me that which F<T>() gets called now depends on whether or
not Foo() throws. Do I need to mark Foo(), an ordinary function, as
throwing or non-throwing? I'm guessing yes.

Consider this example:

template<typename T>
void F() nothrow
{
try {
T t;

t.foo();
}
catch (...) {
}
}

template<typename T>
void F()
{
T t;

t.foo();
}

F<X>();

Here it doesn't matter whether X throws or not (either function
works), so which overload with the compiler pick? More importantly,
how does it make the choice?

How about this example:

template<typename T>
void F() nothrow
{
try {
T t;

t.foo();
}
catch (Bar&) {
}
}

template<typename T>
void F()
{
T t;

t.foo();
}

F<X>();

Now the compiler's choice is harder: as long as X throws only Bar
exceptions, or exceptions derived from Bar, the compiler can pick the
nothrow function. But in general, it's not possible to determine at
compile time what exceptions a function might throw.

You might say that that is a "mis-use" of overload on nothrow, but
that doesn't change the validity of the questions; even if you don't
like this use of overload on nothrow, the compiler will still have to
do something if it sees code like this. So what should it do?

Quote:

I don't tell that the overloading on nothrow can't be misused.
I does tell
that it improves C++ type system when used correctly (and it's not
so hard to
get it rigth).

I don't see this as affecting the type system at all. There are still
lots of unanswered questions. How does this feature interact with
other overloads and specializations? How does this feature interact
with name lookup? How often does the problem that overload on nothrow
solves come up in real code? For real code where this is a problem,
what are the workarounds? Are these workarounds error-prone, or do
they have other disadvantages? What are the disadvantages of overload
on nothrow and how do they compare to the workarounds? How should this
feature behave when the compiler can't determine if a function is
actually nothrow or not? What happens when the compiler gets it wrong
(in particular, when a function which should be nothrow actually
throws an exception)?

For myself, I'm not convinced this is a problem worth solving; I've
never known it to be a problem with any code I've written. The
disadvantages seem to outweigh the advantages, so at this point, I say
overload on nothrow is a mistake C++ should avoid making.

Bob

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Sergey P. Derevyago
Guest

Posted: Mon Sep 01, 2003 3:36 pm Post subject: Re: Overloading on nothrow

Bob Bell wrote:

Quote:

the point. The question about the T::g() -- is the second question (sometimes
you don't want to know about the T::g() at all).
Once more: with certain Ts f<T> never throws (but you can't declare it to be
nothrow because with others it does). Overloading on nothrow allows us to
explicitly tell this to C++ type system (see below, please).

Quote:

I remain unconvinced. I haven't seen any serious discussion of the
problems for which overload on nothrow is a solution. What is the
problem?
The problem is the cooperation of templates and exceptions.

In particular, overloading on nothrow allows us to propagate the nothrowness
to upper levels.
--
With all respect, Sergey. http://cpp3.virtualave.net/
mailto : ders at skeptik.net

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Bob Bell
Guest

Posted: Wed Sep 03, 2003 5:25 am Post subject: Re: Overloading on nothrowC0=CC=21?=

"Sergey P. Derevyago" <non-existent (AT) iobox (DOT) com> wrote

Quote:

Bob Bell wrote:
Of course, the answer is I can't know that. Nothing about the
declaration of f<T>() tells me that T::g() is the discriminating
member. The only way I can tell is if I can look at the _definition_
of f<T>(), which I may not be able to see (e.g., if the f<T>() is an
exported template).
You can laugh but documentation is much handier in addressing these kinds of
issues Smile

And moreover you _must_ be able to see the documentation.

I wouldn't laugh, because I agree that documentation is important.
However, in the real world documentation is often inaccurate or
missing. The fact that overload on nothrow implies more reliance on
documentation is a strike against it, I'm afraid.

Quote:

Also, this situation is quite different from today's use of templates.
Yes, and today's situation w.r.t. templates is nightmare Sad

Overload on nothrow seems to make it more complex, not less.

Quote:

With today's templates, if I try to call f<T>(), and internally f<T>()
calls T::g(), and there is no T::g(), I get a compiler error. Either
it compiles, or it doesn't, and if it compiles, the function that gets
called is determined wholly by the interface of the available
f<T>()'s.
The sad truth is that today's f<>() is always marked as canthrow: "You can
have any exception specification as long as it's canthrow."

The happy truth is that today overloading is based entirely on the
interfaces of functions. Overload on nothrow would change that, and
create dependencies between implementations, which would be a step
backwards.

Up till now you've ignored what I consider the most important
questions. We can haggle about syntax and semantics ad nauseum, but
some day you'll have to give answers to these questions:

Why do we need this feature?

What real-world problem does it solve?

How often does this problem come up in real-world code?

What are the workarounds we are forced to use if we want the effect of
this feature today, if it's even possible?

What disadvantages do the workarounds have?

How does this feature interact with other language features
(overloading, specialization, name lookup, etc.)?

What are the disadvantages of this feature, and how do they compare
with the disadvantages of the workarounds?

As far as I know, any feature considered for standardization must have
pretty compelling answers to these and similar questions.

Bob

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Sergey P. Derevyago
Guest

Posted: Mon Sep 08, 2003 4:45 pm Post subject: Re: Overloading on nothrow

Bob Bell wrote:

Quote:

What's the point of overloading on nothrow if I can't call the nothrow
version?
You're looking from the wrong point.

Overloading on nothrow is defined _only_ for templates. Compiler generates
_only_ _one_ specialization of f<SomeType>(): it will be either nothrow or
not.

Quote:

In particular, overloading on nothrow allows us to propagate the nothrowness
to upper levels.

I don't think you're getting my point. What is the real-world reason
we need to make this change?
1. Suppose you have to write a function template:

2. And you call t.g() inside f():
3. And your implementation substantively depends on the fact whether t.g()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
throws. I.e. you have a bulk general case algorithm_1 (that has to cope with
^^^^^^^
exceptions) and an "optimal" algorithm_2 (which is free to be fast).
^^^^^^^^^^^^^^^^^^^^^^^^
--
With all respect, Sergey. http://cpp3.virtualave.net/
mailto : ders at skeptik.net

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Randy Maddox
Guest

Posted: Mon Sep 08, 2003 4:45 pm Post subject: Re: Overloading on nothrow

"Sergey P. Derevyago" <non-existent (AT) iobox (DOT) com> wrote

Quote:

mvitalo wrote:
It would be nice to have a container class where the methods are
overloaded to throw or not, for example.

Is there some overwhelming reason why std::nothrow could not be used
here? It seems to me that overloading on an additional parameter of
type std::nothrow, coupled with an explicit empty exception
specification on the nothrow function, would pretty much get you what
you want, without any other changes to the language. This would be
self-documenting in the code and enfoceable by the compiler. And it
is an approach already demonstrated to work in the standard library.
Why invent a new solution if an appropriate one already exists?

What problem am I missing that such an approach would not solve?

Randy.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Sergey P. Derevyago
Guest

Posted: Tue Sep 09, 2003 3:21 pm Post subject: Re: Overloading on nothrowD=21?=

[this is a repost]

Bob Bell wrote:

Quote:

What's the point of overloading on nothrow if I can't call the nothrow
version?
You're looking from the wrong point.

Overloading on nothrow is defined _only_ for templates. Compiler generates
_only_ _one_ specialization of f<SomeType>(): it will be either nothrow or
not.

Quote:

Sergey P. Derevyago
Guest

Posted: Tue Sep 09, 2003 3:21 pm Post subject: Re: Overloading on nothrowC0=CC=21?=

Randy Maddox wrote:

Quote:

Is there some overwhelming reason why std::nothrow could not be used
here?
[snip]
Why invent a new solution if an appropriate one already exists?

What problem am I missing that such an approach would not solve?
Overloading on nothrow is the second step (actually, the word "overloading"

isn't well-chosen and is rather confusing w.r.t. the concept).
The first step is statically checked nothrow specifications and blocks.
--
With all respect, Sergey. http://cpp3.virtualave.net/
mailto : ders at skeptik.net

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Display posts from previous:

	C++Talk.NET Forum Index -> C++ language, library and standards	All times are GMT Goto page 1, 2 Next
Page 1 of 2

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum