Re: A C++ Whishlist

From: Hattuari (susudata_at_setidava.kushan.aa)
Date: 03/09/04 

Date: Tue, 09 Mar 2004 17:43:08 -0500

Pete Vidler wrote:

> Hattuari wrote:
> [snip]
>> I believe some things could go a long way to improve the language's
>> usability that do not involve modifying the language itself. I would
>> like to see an open standard library for supporting code completion,
>> syntax highlighting, code formatting, and edit-time error checking.
>
> I can't believe I'm posting replies to such daft posts today. Must have
> *way* too much time on my hands :).
>
> These are nothing to do with the language or the standard library. They
> are to do with your editor or IDE -- moreover they are highly platform
> specific. This will never happen.

Just because it's never been considered or attempted, doesn't mean it can't
be done. The suggestion comes as a result of a great deal of user-level
experience with more editors/IDEs than I could possibly name, on several
different platforms, I should add. I'm not talking about the full
implementation, I'm talking about the necessary building blocks.

I'm just learning about www.boost.org but it looks like a place something
along these lines might fit.

> The Java String class is useless. Last time I used it (3 years ago) it
> had an equality operator ('==', although Java doesn't actually support
> operator overloading) that compared addresses rather than values (in a
> language that doesn't acknowledge such a thing as an address)!
>
> You could do this:
>
> String a = "Hello!"
> String b = "Hello!"
>
> The expression "a == b" would return false. No such problems with C++.

There is something to be said for RT_M.

> This will never happen.

I didn't say it had to be like the Java String class. Java is a different
language. It is not reasonable to expect C++ to behave exactly like Java.

>> Deprecate, or seriously restrict struct so that it can only have public
>> members. It just adds complexity without functionality to have struct
>> defined as a class in which members are default public.
>
> A struct is just a class that defaults to public instead of private. Is
> it less complex to have a whole different mechanism for structs,
> complete with its own rules? No -- it's more complex that way. And you
> would destroy the vast majority of existing code.

Linguistically, having the ability to declare members as protected or
private in a struct is more complex. There are simply more variants
available. It would not require anything more than a deprecation check to
implement it in the compiler, so the argument that it adds complexity is
basically moot. Deprecation does not break existing code, and AFAIK, sane
programmers do not use data hiding in structs, so it should not break very
much existing code to remove the support all together.
 
> This will never happen.
>
>> I believe header files are nothing but a nuisance. It is not clear to me
>> they add anything to the capability of the language, but they clearly add
>> confusion. If nothing else, provide a standard library component that
>> will facilitate the automatic synchronization of header files.
>
> What confusion do they add? Notice that, at the compiler level, there is
> no such thing as a header file (there is only the translation unit).

They require the programmer to maintain redundant information, and also
require the programmer to look in two different places to gain complete
information about the current scope. To add complexity, without adding
functionality is to add to the possibility of becoming confused. It also
adds to the actual number of steps required to complete a task, and
therefore to the workload.

> They exist only up to the preprocessor level, so the standard library
> will have nothing to do with them.

Perhaps I should have said 'standard library extension'. Please understand
that I am suggesting doing things differently than they have been done in
the past.

> What do you mean by automatic synchronization anyway? Sounds like
> something a tool would do, not the standard library.

You say 'the' standard library. But the entire purpose of my post was to
suggest change.

> This will never happen.
>
>> I suspect namespaces and what is now done with header files could be
>> merged in such a way to encourage better use of namespaces, and provide
>> basically the same support as header files currently provide.
>
> Header files separate interface from implementation. Even with templates
> you can use the "export" keyword (except hardly any compilers support it
> -- not the fault of the language or library). Namespaces provide
> different, equally useful, functionality.

So far the only argument for the use of functions at the namespace level is
to support the overloading of binary operators. To me, that is something
that could well be folded into the class. I understand that header files
are intended to declare an interface separate from implementation, but I
don't see where it is actually useful.

If you wish to abstract an interface use an interface definition language:
http://www.w3.org/TR/2004/PR-DOM-Level-3-Core-20040205/idl-definitions.html
 
> This will (probably) never happen.
>
>> Make exception handling manditory as it is in Java. If you throw it, you
>> *must* catch it, or declare it to be thrown in the function declaration.
>
> Bad idea. It doesn't work for Java -- look through all the medium-large
> sized project source code you can get your hands on and see what a mess
> they are thanks to this -- and it wouldn't work for C++.

I have just about the entire xml.apache.org cvs on my harddrive, and that
says nothing for the dozens of other Java cvs images I have checked out and
worked with. It depends how things are handled. The fact that I can get
very good diagnostic information from exceptions at runtime aids
significantly in debugging. What's the point in throwing an exception if
it isn't handled?
  

-- 
.

Relevant Pages

  • Re: A C++ Whishlist
    ... > usability that do not involve modifying the language itself. ... It just adds complexity without functionality to have struct ... As for header files, apparently you don't comple very large applications. ... (No idea what those are, with regards to programming, at least.) ...
    (comp.lang.cpp)
  • Berlinski paper presented 1985 at Applied systems analysis
    ... Complexity, Language and Life: Mathematical Approaches, ... This paper explores the idea that life comprises a language-like ...
    (talk.origins)
  • Re: Programmers unpaid overtime.
    ... The cache solution's execution time formula is a function of the total ... The campaign is part of what I consider the deprivation of language by ... You can't, in other words, document, and management wonders why ... >> complexity with a few benchmarks. ...
    (comp.programming)
  • Re: Kolmogorov complexity and logical languages
    ... I have looked into the Kolmogorov thingie a bit. ... it is hard to say that one language is more complex than another. ... with linguistics. ... instead of the more abstract notion of complexity. ...
    (sci.lang)
  • Re: Responding to a challenge
    ... > Why do you think such complexity actually exists? ... I would think it noncontroversial that language itself serves the ... were to create an artificial dialect of English in which all verbs ... one an artificial dialect of English with regular pluralization. ...
    (sci.lang)