Re: A C++ Whishlist

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

Date: Tue, 09 Mar 2004 21:16:11 -0500

Pete Vidler wrote:

> Again, they are highly platform specific. Something like this is just
> not a reasonable thing to expect from the standard library.

I'm not at all convinced that the basics are platform dependent. I believe
they are very abstract and generic problems which can be addressed at a
platform independent level. The biggest reservation I would have is
regarding the complexity. But if you read the regular expression section
of the ECMA Script standard you will learn that complexity doesn't stop
people from inclusion in a standard.
 
>> I'm just learning about www.boost.org but it looks like a place something
>> along these lines might fit.
>
> There is a parsing framework (Spirit) as part of boost... but it won't
> do anything like what you are looking for without a huge effort on the
> part of the user.

I really don't know the degree of effort required. Nor do I know the
necessary complexity of the basic supporting components. Something tells
me a consolidated effort on the part of a few talented and knowledgeable
programmers could produce a fairly compact foundation for this. I am by no
means an expert in this area, but I have played around a bit, and
discovered there are certain repeating patterns which are applied
repeatedly/recursively to provide rather complex results.

>> There is something to be said for RT_M.
>
> Oh really -- and what is that?
http://www.research.att.com/~bs/glossary.html
RTFM - "Read The Manual" (The 'F' is silent). Usually a very good idea.

> Please explain the problem you've had
> with the C++ string classes as compared with the Java ones. I've already
> given a serious flaw in the Java classes (that they are clearly
> non-intuitive)...

My problem is not with the std::string per se. My problem is with the
number of non-standard string classes in use, and the evidence I've seen
suggesting learning to use them as they stand is non-trivial, Much less
trivial, it would appear, is learning to convert from one to the other in a
reliable efficient way. I suspect the std::string is lacking some
essential core functionality that implementers feel the need to provide by
creating their own string class.

To say Java's method of comparring strings is non-intuitive because '=='
doesn't work is nothing short of complaining that it isn't just like C++.

>>>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.
>
> So why do you need a better string class? What bothers you about the
> current one? The only example you gave was the Java string class -- you
> said: "in Java, a String is a String is a String", how is this not true
> of C++?

http://xml.apache.org/xerces-c/apiDocs/classXMLString.html
http://doc.trolltech.com/3.3/qstring.html
http://www.dinkumware.com/manuals/reader.aspx?b=p/&h=string2.html

> For me, C++ is all about choice. You can keep you structs entirely
> public, that's up to you. I can use my structs how I choose, that's up
> to me. You don't have to use my code, I don't have to use yours.

Then why have a standard at all?
 
> Actually, I think it's a lot more complicated than a "deprecation check"
> in the compiler. I suspect handling structs in an entirely different way
> will cause many headaches for compiler writers -- what happens if you
> try to derive a struct from a class? Or a class from a struct? Is it
> disallowed? Do you check for protected members?.

Languages change over time. There are many instances of such things, and
more significant things changing from version to version of a programming
language. I don't believe that simply preventing the use of a struct as a
class is nearly as problematic as you make it out to be.
 
>> 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.
>
> The simple separation of interface and implementation that header files
> supply is far more valuable (to me) than typing one line of extra code
> per method.
>
> If you have to learn how a system works through the code, it is always
> easier to have a summary (interface) in one file and the implementation
> in another. Digging through masses of code to see a method declaration
> is not fun (and don't talk to me about decent editors making that
> unnecessary -- I can and have had to write code in notepad before now).

Well there is javap. :-)

Compiled from "String.java"
public final class java.lang.String extends java.lang.Object implements
java.io.Serializable,java.lang.Comparable,java.lang.CharSequence{
    public static final java.util.Comparator CASE_INSENSITIVE_ORDER;
    public java.lang.String();
    public java.lang.String(java.lang.String);
    public java.lang.String(char[]);
...
    public java.lang.String(byte[], int, int, java.lang.String) throws
java.io.UnsupportedEncodingException;
    public java.lang.String(byte[], java.lang.String) throws
java.io.UnsupportedEncodingException;
    public java.lang.String(byte[], int, int);
    public java.lang.String(byte[]);
    public java.lang.String(java.lang.StringBuffer);
...
    public byte[] getBytes();
    public boolean equals(java.lang.Object);
    public boolean contentEquals(java.lang.StringBuffer);
    public boolean equalsIgnoreCase(java.lang.String);
    public int compareTo(java.lang.String);
    public int compareToIgnoreCase(java.lang.String);
   ...
    public static java.lang.String valueOf(float);
    public static java.lang.String valueOf(double);
    public native java.lang.String intern();
    public int compareTo(java.lang.Object);
    static {};
}

> As for the workload -- the interface should be defined first. Then just
> copy and paste the method declarations to the header where you implement
> them. There's maybe a second or two of time spent on it per method. I'll
> grant that changes must be made in two places, but this is a small price
> to pay for what you get (a simple, easy to understand and maintain,
> interface).

I actually have more powerful tools at my disposal in most cases. Some of
what I am saying applies to new programmers. It really does make coding
more difficult, and there are some subtelties involved which can be fairly
confusing as well. I would favor moving declarations to the top of the
source file, rather than maintaining two different files.

The fact that I have to check both the header, and the implementation to
determine what defaults are given to arguments is disconcerting to me. I
*can't* simply look at the header and know the API.
 
> Then do so by writing these extensions, or this new library and try
> getting it added to boost. This is probably your best path to adding
> code to the standard library.

I do have a place to start. www.kdevelop.org
 
>> 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.
>
> And if you don't have access to the class -- how do you overload the
> operators then? There is a book called "The Design and Evolution of C++"
> that explains why much of C++ is the way it is. I suggest reading it.
>
> As for separating interface and implementation (in as far as using a
> header file goes), it serves several purposes:
>
> 1) If you are not using templates then you can distribute the
> implementation as a compiled library, preventing people from stealing
> too much of your code.
>
> 2) It helps you to write code that doesn't require users to know the
> implementation. From the perspective of a library user, it's much easier
> to treat a system as a black box with an interface rather than having to
> know implementation details.
>
> 3) It makes the system easier to understand and so maintain. People who
> maintain code are rarely the same people who wrote it.
>
> 4) Other stuff that I'm too tired to think of (damn that's lame) :)

My argument is that much of this could be automated.
>> If you wish to abstract an interface use an interface definition
>> language:
> [snip]
>
> Why would I need idl when I can just use plain C++? I thought the main
> use for IDL was cross-language interfaces such as com/activex components
> that must work with C,C++,VB and whatever else.
>
> [snip]
>> 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?
>
> Again, C++ is about choice. What if I *want* my exception to drop
> through to be someone elses problem? What if I *don't* want my code
> littered with try/catch blocks making it harder to understand? What if I
> don't want an ever increasing size of exception specification on each
> method as the project grows is complexity?

throws Exception.

> I *want* to have those as choices.. not forced on me by a compiler.
>
> Bottom line: You want those things then use Java, Managed C++ or C#. You
> want to choose these issues for yourself then use C++.

Perhaps haveing some compiler mode switches whould satisfy both parties. I
find many features in C++ seem to be unused because it's easier to ignore
them than to learn to use them correctly.

> As someone who was once forced (at uni) to dig through and understand a
> 6000 line Java program (of which nearly 1000 lines was a switch
> statement and with a great deal of try/catch/finally blocks) I can
> honestly say I prefer to have the choice.

That sounds like bad design to me, but 'throws Exception' works. 

-- 
.

Relevant Pages

  • Re: Features that can only be provided by the implementation?
    ... specific behaviors of standard CL functions allow but not mandated ... such as an interface to sockets.) ... Built-in Functions ... Getopt Parameter lists ...
    (comp.lang.lisp)
  • Re: C header files--Urgent
    ... an "impossible assignment" for you. ... compiler from unix to windows and compiler is written partially in c ... If they are standard header files then ...
    (comp.lang.c)
  • Re: HeathField Strange Ideas!
    ... interface that can be included in a program so to interface with the ... these keyboard events; X is an official standard, ... by quite a number of systems, and MS Windows is a de-facto standard, ... What the C standard deals with is *character streams* (or byte ...
    (comp.lang.c)
  • Re: Forth and Co - The Return of the Jedi
    ... complexity" of the ANSI standard is rarely visible to users, ... If someone has a problem with that and wants to use Standard Forth, ... Every one of the special compiler words has the ... And then you have one language and not two. ...
    (comp.lang.forth)
  • Re: TDBC documentation, examples, syntax?
    ... This standard is long, ... code, but ISO 9075 contains more than an interface, it defines an SQL ... What I see in the TDBC API is a distinct, ... layer API", this is what we see as we write Tcl programs. ...
    (comp.lang.tcl)