On Monday, 12 January 2015 at 21:41:48 UTC, Andrei Alexandrescu wrote:
> I can't believe I agree with everything bearophile just said :o). -- Andrei

But we knew that already.
channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C
stackoverflow.com/questions/14923346/how-would-you-use-alexandrescus-expectedt-with-void-functions

On Monday, 12 January 2015 at 18:11:03 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 12 January 2015 at 17:57:10 UTC, H. S. Teoh via Digitalmars-d wrote:
>> Yeah, exceptions are supposed to be ... well, *exceptions*, rather than
>> the norm. :-) If you're using exceptions to do flow control, you're
>> doing something wrong.
>
> I'm sorry, but this is just a crappy excuse invented to defend C++ EH. It has no merits, except being an excuse for writing exceptionally convoluted code to save performance because real exceptions are slow.
>

No, Exception are a bail out mechanism. It is the, I have no idea what to do about this mechanism.

If you put aside performance concerns, exceptions for control flow also tend to make many code path implicit and makes for very unreadable/unmaintainable code.

On 1/12/2015 1:22 PM, Dicebot wrote:
> In server applications there is no such thing as a rare case though and this
> trade-off looks quite appealing.

Don't use exceptions for normal operations.

On 1/12/2015 1:46 PM, Martin Nowak wrote:
>> There's another downside to returning two values - extra code is generated,
>> and it consumes another register. It allocates very scarce resources to rare
>> cases - not a recipe for high performance.
>
> To defend that argument we'd first have to fix our own codegen.
> https://issues.dlang.org/show_bug.cgi?id=12442

That issue has nothing to do with exception handling vs error codes.


> It doesn't really consume the register, because the error value is only needed
> directly after the call for a possible early return. But of course returning
> tuples can be less efficient.

Yes, it does. Returning an int in EAX now becomes returning a pair [EAX,EDX].

On Monday, 12 January 2015 at 22:13:10 UTC, Walter Bright wrote:
> On 1/12/2015 1:22 PM, Dicebot wrote:
>> In server applications there is no such thing as a rare case though and this
>> trade-off looks quite appealing.
>
> Don't use exceptions for normal operations.

Which is equivalent to "don't use exceptions on servers" :) Yes, I know, this is why any alternative approach is worth interest.

On Monday, 12 January 2015 at 22:06:32 UTC, deadalnix wrote:
> No, Exception are a bail out mechanism. It is the, I have no idea what to do about this mechanism.

The way it is done in C++, yes.

> If you put aside performance concerns, exceptions for control flow also tend to make many code path implicit and makes for very unreadable/unmaintainable code.

But exceptions are control flow. There is no such thing as normalized control flow, all state changes implies "control flow". Think in terms of a state machine. You could just remove all variables and only have a big state machine (assuming finite dimensions). Every single state transition implies flow of control.

The control flow you see in the source code is just the programmer's "rendition" of control flow. Exceptions is a mechanism for getting cluttering resolution out of that rendition to make the code more readable and maintainable. The goal is to retain the meat of the computation and remove the noise.

Or to put it differently, there are many ways to write the same function. Good use of exceptions removes the clutter and leaves the things you care about visible. It's a mechanism, not a moral issue or a religion.

So there is nothing wrong with throwing HTTPStatus(409) or HTTPStatus(201), even though it returns state to the environment. If that means the code is more maintainable and more likely to be correct, then that is good use of the mechanism.

On Monday, 12 January 2015 at 22:17:57 UTC, Walter Bright wrote:
> Yes, it does. Returning an int in EAX now becomes returning a pair [EAX,EDX].

It is not that big of a deal, EDX is a trash register anyway if memory serve, but then, it become very bad when it do not fit in register anymore.

Ola Fosheim Grøstad:

> (Most of std::C++ is optional, templated and inefficient... There is no consistent culture. Though they got some thing right with unique_ptr and new language features recently.)

I don't agree. The basic ideas of STL by Alexander Stepanov are very good. Phobos contains related ideas, repackaged in ranges. Ranges are a little more fundamental, ma but in practice they are often good enough and they are often more handy. Rust has chosen a different way so far, but will improve with higher order generics later.

Bye,
bearophile

On Mon, Jan 12, 2015 at 11:17:24PM +0000, deadalnix via Digitalmars-d wrote:
> On Monday, 12 January 2015 at 22:17:57 UTC, Walter Bright wrote:
> >Yes, it does. Returning an int in EAX now becomes returning a pair [EAX,EDX].
> 
> It is not that big of a deal, EDX is a trash register anyway if memory serve, but then, it become very bad when it do not fit in register anymore.

On the contrary, it's an extremely big deal. Registers are a rare resource, and allocating them for maximal usefulness is a major issue in code optimization.


T

-- 
A mathematician is a device for turning coffee into theorems. -- P. Erdos

On Monday, 12 January 2015 at 23:18:52 UTC, bearophile wrote:
> I don't agree. The basic ideas of STL by Alexander Stepanov are very good. Phobos contains related ideas, repackaged in ranges. Ranges are a little more fundamental, ma but in practice they are often good enough and they are often more handy. Rust has chosen a different way so far, but will improve with higher order generics later.

I've tried to like STL for 17 years, and whenever speed and clear programming matters it is basically a good idea to throw it out. It goes like this: 1. code up prototype with STL, 2. write STL code and add the features I need, 3. being annoyed by the bloat and noise, 4. rewrite code with my own container for log2 efficiency and ease of use...

I wish Phobos would have stuck to the term "iterators" used in GoF since a "range" usually is something else... but digressions aside. Phobos is kinda like the "functional" parts of Python. The downside there is that you need to remember lots of verbs. A solution like list comprehensions is a lot easier on the programmer, if convenience is the goal.

But in system level programming efficiency is the goal. That means log2 sizes, operations that are optimized for log2 sizes, datastructures that are optimized for SIMD. Phobos "ranges" need a next_simd() to be efficient. Right?