On Friday, 25 February 2022 at 04:09:51 UTC, meta wrote:
> I don't even think the global lock is the only issue, to begin with..
>
> And, no matter what, it's a double penalty in D because it is a Heap allocation, and that can pause all the threads if it requires more memory.. due to the use of a GC

You can throw pre-allocated exception.

> To counter that, one suggested the use of RC, or a value.. but even then, we still deal with exceptions!
>
> No matter what, I personally stopped using exception altogether in my C++ projects, and moving forward, in my new D projects too

You've already mentioned this. Would be more interesting to hear how you handle errors/exceptions, or propose a better alternative to exceptions that would be comfortable for most people.

> Also I don't think it is wise to design, or hold designs of, the language because you expect people to be lazy, we should have design philosophy based on HW and Software constrains, not based on lazyness/sloppyness of some developers.. we'll attract the wrong user base.. and even then it'll be hard to compete with sloppy dynamic languages out there... javascript... to name a few

Laziness is one of driving forces for automation.
Sloppynes is one of causes for good amount of bugs.

Not taking them into account, would only be harmfull.

> We should all handle our errors and maintain healthy codebases that are safe and make software great again!

Per my understanding if-checking of error codes or similar, was proven to be inefficient, or at least more inefficient than exceptions, for code which errors happen not so often to affect performance.

On Fri, Feb 25, 2022 at 10:37:55AM +0000, ShadoLight via Digitalmars-d wrote: [...]
> Not a comment about your point in general but, yeah, even though I agree with your point, in this specific example, you could have avoided all the gotos:
> 
> int some_func(some_type_t *some_args) {
> 	int ret = SOME_FUNC_ERR;
> 
> 	if ((ret = do_something(...)) != DO_SOMETHING_OK)
> 		return SOME_FUNC_ERR;
> 
> 	if ((ret = do_something_else(...)) != DO_SOMETHING_ELSE_OK)
> 		return SOME_FUNC_ERR;
> 
> 	if ((ret = do_yet_another(...)) != DO_YET_ANOTHER_OK)
> 		return SOME_FUNC_ERR;
> 
> 
> 	// ... ad nauseaum
> 
> 	return SOME_FUNC_OK;
> }
> 
> But, where I have found it unavoidable (in C) to use this 'goto' style
> (and which - I'm certain - is where your example originates from) is
> when you have some common cleanup to do at the end:

Yes, I omitted the cleanups, but yeah that's where the goto's come from. The thing is, sooner or later you're gonna hafta add cleanups. It seems to be an inevitable fact of life as the function grows more hairs from bugfixes, enhancements, and what-not.

And experience shows that it's better to just begin by writing the fully-general form from the beginning than to add it later, because what tends to happen is that some hapless guy comes along after the fact and goes "oh right I need to cleanup" and then rewrites some of the return's to gotos, but misses a few, thus introducing resource leak bugs.


[...]
> I have yet to find a way to avoid this in C. OTOH in C++/D/etc exceptions are just such a super convenient way to handle this case. In code where you are not concerned with the cost of exceptions or optimization I'll really miss them.

That's the thing about people with C/C++ mentality (myself included -- that's the background I come from). You find a case where a particular construct is less than optimal, and then you decide to forego that construct entirely, even where performance doesn't really matter and that construct could have helped your code be cleaner and more maintainable.

Exceptions seriously help a LOT with making cleaner APIs and in writing code faster.  Where it becomes a hindrance to runtime performance, `nothrow` is right there for you to use.


T

-- 
Real men don't take backups. They put their source on a public FTP-server and let the world mirror it. -- Linus Torvalds

On Friday, 25 February 2022 at 08:40:12 UTC, Ola Fosheim Grøstad wrote:
> ... The motivation for providing an alternative to exceptions in C++ is that not having an embedded-friendly standard library is problematic. It is harmful to their eco system.
> ..

The 'real' motivation is simple -> an increased awareness of the benefits of Rust within the C++ community.

That is, C++ now has a genuine competitor -> and C++ now needs to compete, or risk losing market share.

So I expect we'll see a noticable increase in ideas and innovation coming out of the C++ community, particuly in areas where Rust does it better.

D should also remain alert to what's going on ;-)

On Friday, 25 February 2022 at 21:03:21 UTC, forkit wrote:
> On Friday, 25 February 2022 at 08:40:12 UTC, Ola Fosheim Grøstad wrote:
>> ... The motivation for providing an alternative to exceptions in C++ is that not having an embedded-friendly standard library is problematic. It is harmful to their eco system.
>> ..
>
> The 'real' motivation is simple -> an increased awareness of the benefits of Rust within the C++ community.
>
> That is, C++ now has a genuine competitor -> and C++ now needs to compete, or risk losing market share.
>
> So I expect we'll see a noticable increase in ideas and innovation coming out of the C++ community, particuly in areas where Rust does it better.
>
> D should also remain alert to what's going on ;-)

In terms of ecosystem, Rust is where C++ was 30 years ago.

While its ideas might seem to be a risk to C++, specially since there is no way to fix unsafe by default in C++ without breaking backwards compatibility.

However until we get Metal rewritten in Rust, CUDA Rust, Tensorflow/Pytorch rewritten in Rust, LLVM/GCV rewritten in Rust, AUTOSAR and SYSCL move from C++ to Rust, Nintendo/Sony/Microsoft console SDK support for Rust, CERN, Fermilab, NASA moving away from Fortran/C++.....

There is no market share for Rust to take away from C++ on those domains.

Currently D has more to lose against Rust than C++, because it lacks such deep ingrained industry support, and trying to be just like Rust won't be differentiating factor.

On Saturday, 26 February 2022 at 08:48:58 UTC, Paulo Pinto wrote:
>
> In terms of ecosystem, Rust is where C++ was 30 years ago.
>

I think that's a little overstated - were you even around in 1992 ??

Microsoft released their first C++ compiler in 1992.

Anyway. It's curious that Microsoft has taken a very noticable interest in Rust:

https://docs.microsoft.com/en-us/windows/dev-environment/

On Saturday, 26 February 2022 at 10:20:00 UTC, forkit wrote:
> On Saturday, 26 February 2022 at 08:48:58 UTC, Paulo Pinto wrote:
>>
>> In terms of ecosystem, Rust is where C++ was 30 years ago.
>>
>

Here's a pretty good analysis of the Rust ecosystem.

https://joeprevite.com/rust-lang-ecosystem/

On Saturday, 26 February 2022 at 10:20:00 UTC, forkit wrote:
> On Saturday, 26 February 2022 at 08:48:58 UTC, Paulo Pinto wrote:
>>
>> In terms of ecosystem, Rust is where C++ was 30 years ago.
>>
>
> I think that's a little overstated - were you even around in 1992 ??
>
> Microsoft released their first C++ compiler in 1992.
>
> Anyway. It's curious that Microsoft has taken a very noticable interest in Rust:
>
> https://docs.microsoft.com/en-us/windows/dev-environment/

Given that my first coding platform was the Timex 2068 I guess I was.

Microsoft was the last C compiler vendor to adopt C++ with the release of Microsoft C/C++ 7.0.

I leave as exercise for the reader when everyone else released their offerings, including frameworks like Turbo Vision, AppFramework and Motif++.

Microsoft is only testing waters with Rust, until it comes up in Visual Studio, with comparable tooling to .NET and C++, for all kinds of Azure and Windows workloads, 99% of Microsoft shops won't bother.

On Saturday, 26 February 2022 at 13:48:52 UTC, Ola Fosheim Grøstad wrote:
>
> Maybe, but how many committed C++ programmers have switched to Rust?

so you don't compete in the market, by waiting till your competitor has taken your customers ;-)


> Yes, but it will probably come in the form of being "optional". Many of the improvements in C++ comes from compiler/tooling support/switches or things that can pass as library extensions (but really only makes sense with compiler support). I don't think we will see much in the shape of changes to the core language.
>
>
> D should form its own vision, and focus on that vision. Only then will real improvements be possible. Too many DIPs touch on things that have no significant impact. If it has no significant impact then it should not be a priority. Without a vision it difficult to assess what the priorities ought to be.

D seems to becoming more of a development environment for C code.

Seriously. If I want C, I can just use C.

So just where D is going to stand out (in relation to it's competitors) in this new world of 'more secure code', is not at all clear to me, and it's vision is even more obscure to me.


> For C++ you can say that the vision is to support existing fields where it is widely used better. They have many use cases to analyse. So that is a very different situation.
>
> I think what the priorities ought to be is more clear for C++ as it have many specific niche areas where it is heavily used.

This would be sign of impending doom for C++. i.e. It *also* needs to focus heavily on competing for new customers, now that many people and corporations see Rust as serious contender.

I remind you, that the info in this link is somewhat outdated ;-)

(i.e. the Rust ecosystem has grown further since this analysis).

https://joeprevite.com/rust-lang-ecosystem/