This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: c++ "with" keyword


> So, you are saying that nobody should be able to understand a hardcopy
> printout of code on it's own. They should be required to examine it
> inside of a GUI infested enviornment?

As an old paper reader myself, I will say that it is hard to go back to
paper once you are used to a competent browser.

> Also, the clickie thingie will only work if it can parse the code, but
> if I'm trying to get someone elses code to run on my *other-brand*
> machine, and I have syntax errors, the GUI tools will probably not
> be able to get their info until the syntax errors are gone, but I can't
> get rid of the syntax errors if I can't figure out what the code is
> supposed to do, which requires the tools, which ...

Well again, it depends on the tools. GPS can operate with partial semantic
information just fine. GNAT has an option to force generation of semantic
information to the extent possible even if there are errors, and it works
very nicely in practice in this situation.

But remember that you are talking about your *own* code here. If you are
using a library, and are deathly afraid of having to change your code for
new versions (perhaps because you only read stuff on paper, and indeed
you don't understand the code you are working with), then you may decide
to write in a style without WITH (or its equivalents), or to keep all
variable names very short. But if you are happy to use an environment in
which the very unlikely case of WITH causing trouble could be easily fixed,
then you may find that it is worth using to make your code more readable.

And again, to play broken record, this entire discussion is about an issue
that can perfectly well be left moot (= undecided, arguable), since the
powerful argument against WITH that it is expressively unnecessary since
there are better ways of doing the same thing already. 

The burden for a language change is always severe, you damage a language
by adding a new feature (by making it more complex) so you have to be
super sure that it is buying a gain that is *more* than this cost.

In this case we have a proposed feature WITH that provides minimal gains
at best and in addition has possible negatives. There is no way that the
burden of a new feature is met in this case.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]