Thread: Idea for new language construct

RAII is of course the solution given what features the language present us at the moment.

But really no one came up with a good argument yet as to why function destructors are not a good idea. In my limited knowledge I don't see anything absurd in this addition to the language.

And if the best one can come up with is "you have RAII for that", then really most of the current language features would have to be removed since they too present coding alternatives. I just don't think that is a valid argument.

But the only variable or pointer that actually needs deleting after the program returns, is the one that is returned. Is deleting one variable worth the mess?

But even real world applications can't return multiple variables. All the other variables can be deleted just before return.

Originally Posted by jlou

And "you have RAII for that" is a valid argument because it is as good or better than the proposed alternative. Most of the current language features are improvements upon the alternatives.

RAII is not a language feature. It's a coding paradigm. auto_ptr, which is a language feature, is just one way RAII can be implemented. And not always the needed or best method.

What was presented here was a new language feature that could indeed ease coding since RAII needs to be implemented by the coder either through an existing library or coding it themselves. It also forces the user to learn about RAII, how to implement it, the different possible implementations, and why and what to choose to implement.

In an effort to simplify the language, RAII is not the answer (albeit I'm not arguing against the merits of this paradigm). It only further complicates it. And you ask that to any newcommer to the language. Especially someone coming from languages which offer garbage collectors.

So... no. I still can't seem to agree with it. "You don't need it because you have RAII" seems to me much like saying "You don't need new shoes because your torn old ones still have a sole"

>What was presented here was a new language feature that could indeed ease coding since
>RAII needs to be implemented by the coder either through an existing library or coding it themselves.
The new feature also needs to be implemented by the coder. As I understand it, the suggestion was equivalent to a finally clause that has to be added to every block you want cleanup done on, regardless of what happens in the block itself. All of the grunt work is still done by the programmer.

>It also forces the user to learn about RAII, how to implement it, the different possible
>implementations, and why and what to choose to implement.
As opposed to learning about the new feature, how to use it, when to use it, and the pitfalls that it might have?

>In an effort to simplify the language, RAII is not the answer
If you want a simpler language, Java is there. C++ is as simple as possible for the power it offers. The result is certainly not a simple language, as anyone who is reasonably proficient in it will tell you. But it's not designed to be simple. It's designed to be useful.

>And you ask that to any newcommer to the language. Especially someone coming from
>languages which offer garbage collectors.
Most newcomers are either new to programming in general, in which case they should be learning about memory management to become well rounded programmers anyway, or new to C++ from a friendlier language like Java and were "protected" from the "evil" fundamentals of memory management. In the latter case, the result is a weak programmer who deserves the good kick in the pants that learning C++ will provide. I don't see the problem.

>"You don't need it because you have RAII" seems to me much like saying "You don't need
>new shoes because your torn old ones still have a sole"
How about "You don't need it because we don't need another feature added to an already feature rich language. Hey, here's how you can simulate that functionality with RAII". Which was the point made from the start, though you seem to have misunderstood.

This is why Java is at the very foundations is the antithesis of C++. Memory management in Java is non-existent and Java is not efficient by any means. It gets the job done, but if we were still stuck in the days of slower processors, Java would not even be an alternative. Java is useful for cross platform, but because it is so cross-platform it is about equally as inefficient on all platforms.

In my estimation, Java was aimed at everything and really ended up hitting nothing.

Some of the posts in this thread are the very reason I despise CLI as well. It adds language constructs to C++ to make it compatible with CLI, yet adds zero functionality to C++ outside of the CLI runtime environment. This is ridiculous.

For those of you that have been coddled and babied by this or that garbage collector it's time to learn how to take your own trash out. Proper memory management IMO is one of the most important skills a programmer can posess and I'm against any language, paradigm, construct, or what have you that attempts to make this process automatic and as far from the programmer as possible.

We run Java on many apps at work and I'm telling you it is a disaster in the works. Access to certain areas are slow, everytime it fires off another program in another window it has to load another Java runtime which just begins to slow the system down more and more. Amazingly when you get rid of the Java program and all its associated windows, the computer begins to act like a fast computer again. You should see the memory handles, allocations, and so forth skyrocket when the Java app is fired up. It is my estimation that the Java runtime usually does not de-allocate memory until the app is finished. This is a very very very bad practice. Whenever an application is done with memory, by all means give it back to the system then not later or whenever the hell you feel like it. Don't be a memory and resource hog and everyone other app on the system will be your friend. I can't believe we are talking about hogging memory today. Back in the day this would have been unheard of. But now since we have more memory than we know what to do with, everyone finds new ways to abuse it.
Just because you want to abuse the memory in your system and use it incorrectly either through a runtime or something else, does not mean everyone else does.

C++ is fine the way it is if it is used properly. No C++ is not a simple language nor does it coddle or baby you. You can mis manage the hell out of memory and C++ will just sit there and let you do it....until the inevitable crash comes. But what we have today is the problem that the 'crash' never happens which leads people to believe their code is fine when it's not. The crash never happens A. because we do have so much memory it takes forever to run out, and B. XP is always sitting there watching whats going on and even though I don't like XP a whole lot, it's memory management is much better than 98 and for the most part saves you from yourself. Every app finally does run inside the 'fence' and very rarely gets out of the fence. I've crashed XP but only using Direct3D. I don't think I've ever brought XP to its knees just doing Win32, MFC, or console code.

Adding constructs to the language that are just as error prone or moreso than simply using what has already been provided in the language is ludicrous.

> For those of you that have been coddled and babied by this or that garbage collector it's time to learn how to take your own trash out.

No one suggested a garbage collector

> Adding constructs to the language that are just as error prone or moreso than simply using what has already been provided in the language is ludicrous.

Sure it is. So lets ditch the boost libraries and do a joint protest against the proposed changes to C++0x. Just to name two. Aren't they as error prone as anything else? All it takes is to use them badly or not understand their purpose and meaning.

> C++ is fine the way it is if it is used properly.

That opinion is not shared by the standards committee.

Originally Posted by Prelude

How about "You don't need it because we don't need another feature added to an already feature rich language. Hey, here's how you can simulate that functionality with RAII". Which was the point made from the start, though you seem to have misunderstood.

Oh I understood that point. However you didn't seem to understand that my argument is exactly that is not a valid argument.

It never was a good argument. The language never evolved that way. The language is still evolving and hopefully will always be be. And one of the main objectives behind the evolution of the language is to make it easier to use. Do I need to provide links to the objectives behind C++0x or even those behind C++98?

Do I think function destructors as proposed by Magos are a good idea? Personally I don't. Not the First-Last block no. I would rather much prefer a construct similar to what some compilers already offer (yes. Surprise. Some compilers do offer function destructors as one of their function attributes provided as an extension to the language). But even so I don't have a definite opinion. I simply don't have the technical knowledge to ascertain it's a good or bad idea.

But I don't see any merit in the "you already have RAII" argument either. It never stopped the standards committee to adopt new constructs despite the fact things could have stayed the same.

>The language never evolved that way.
You don't know much about C++'s evolution then. When faced with the need for a new feature, the first thing done has always been to find a viable alternative using existing features. Then an attempt was made to simulate the feature with a library. Only if neither of those could be done and the need for a feature was great, did they actually consider adding to the language. And keep in mind that the acceptance of new features is exceedingly strict, even if a proposal does get that far.

In this case, RAII is a viable alternative, so the proposal (however informal) stops there.

>It never stopped the standards committee to adopt new constructs despite the fact things could have stayed the same.
Could you list some of them? Most likely you're misunderstanding either the constructs or the intentions of the committee. By the way, we're talking about actual language features, not library additions.

Well, The most likely changes discussed in http://www.artima.com/cppsource/cpp0x.html show constructs that are without exception ways to improve and speed code despite there being alternatives. Since we are talking of actual languages features, of those discussed there I name using and auto. But could also possibly name the sequence constructor needed to support array-like initialization of sequence containers.

But I guess that you are going to give me reasons that in your opinion make these ok changes and not at all related to what I have been saying.

Originally Posted by anonytmouse

In C (and C++, not using RAII), the "goto cleanup" pattern is commonly used:

You do realize that this is utterly exception-unsafe, do you?

Originally Posted by Mario F.

But really no one came up with a good argument yet as to why function destructors are not a good idea. In my limited knowledge I don't see anything absurd in this addition to the language.

It is not absurd, as such. Other languages have added it with some success. It's just that it provides no improvement over the current situation.

And if the best one can come up with is "you have RAII for that", then really most of the current language features would have to be removed since they too present coding alternatives. I just don't think that is a valid argument.

Then you misunderstand the way the argument is presented, or perhaps the argument is presented poorly.
In other words, I challenge you to show me one feature of the C++ core language that
1) is not required for C compatibility (such as the struct/class duality),
2) can be simulated with the remaining language features without
2a) significantly increasing source code size or
2b) making the feature inherently more unsafe to use.
The using statement (i.e. using namespace xxx) does not count - I actually think it's useless and tends to lead newbies to bad practices.

Under these criteria, try...finally falls short because it can, as I have shown, be simulated using local classes and their destructors without significant source or safety overhead.

In an effort to simplify the language, RAII is not the answer (albeit I'm not arguing against the merits of this paradigm). It only further complicates it.

On the contrary. Because RAII is not a language feature, it keeps the language simpler. Instead, RAII is implemented using existing language features, thus leveraging the user's existing expertise (sorry, just wanted to say that).

So lets ditch the boost libraries

The boost libraries are not a language feature. They're libraries - implemented on top of existing language features. Your argument makes no sense.

I would rather much prefer a construct similar to what some compilers already offer

Rename the sentinel in my post to function_destructor and you have the feature.

constructs that are without exception ways to improve and speed code despite there being alternatives.

Yes, that's the point: improve and speed code. try...finally does not do this.

I name using

The current alternative: nested typedefs. The example line would translate to this:

Code:

template <typename T> struct Vec { typedef std::vector<T, My_Alloc<T> > type; };

Vec<float>::type v;

The code might not be significantly longer, but it contains a readability impact every time you use it. And it is not equivalent: you cannot pass Vec as a template template parameter. (I'm not fully sure if you can do it with the using, but I assume you can.) Therefore, this new language feature provides something that is not possible without it.

and auto.

The use of auto is twofold; both uses have been presented in the "a few doubts" thread.
First, it can significantly reduce typing and simply detective work for complex types: an average Boost.Spirit rule has a full type that may be anywhere from 60 to 400 characters long. In other words, it is not practical to create a local variable of a Spirit rule type without type erasure in the form of spirit::rule. auto changes that.
The other use is something that is currently just about impossible to solve with existing features: local variables in templates that depend on a potentially non-traceable way on the template parameters, e.g. the result of an overloaded function called with a parameter of template parameter type. This simple case can be handled by boost::result_of (with significant compile-time overhead, I believe) - more complex cases require BOOST_TYPEOF, and this macro in turn requires libraries to register their types in order for it to work.

But could also possibly name the sequence constructor needed to support array-like initialization of sequence containers.

The sequence constructor makes static initialization of containers possible - this is not possible with the current language features.

As you see, none of these features are redundant: they all provide something that is currently not possible, or requires a significant of work to duplicate.