Re: A C++ Whishlist
From: Pete Vidler (pvidler_at_mailblocks.com)
Date: 03/10/04
- Next message: Mike Wahler: "Re: Having a pointer to a parent class ?"
- Previous message: David Harmon: "Re: A C++ Whishlist"
- In reply to: Hattuari: "Re: A C++ Whishlist"
- Next in thread: Hattuari: "Re: A C++ Whishlist"
- Reply: Hattuari: "Re: A C++ Whishlist"
- Reply: Justin Dubs: "Re: A C++ Whishlist"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 09 Mar 2004 23:59:42 +0000
Hattuari wrote:
[snip]
> 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.
Again, they are highly platform specific. Something like this is just
not a reasonable thing to expect from the standard library.
> 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.
> There is something to be said for RT_M.
Oh really -- and what is that? 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)...
>>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++?
> 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.
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.
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?.
> 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).
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).
[snip]
> 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.
I still don't see what you mean by 'automatic synchronization' of header
files, so I can't see how a 'standard library extension' could
accomplish this.
> You say 'the' standard library. But the entire purpose of my post was to
> suggest change.
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.
> 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) :)
> 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?
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++.
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.
-- Pete, that's it.. I'm off to bed.
- Next message: Mike Wahler: "Re: Having a pointer to a parent class ?"
- Previous message: David Harmon: "Re: A C++ Whishlist"
- In reply to: Hattuari: "Re: A C++ Whishlist"
- Next in thread: Hattuari: "Re: A C++ Whishlist"
- Reply: Hattuari: "Re: A C++ Whishlist"
- Reply: Justin Dubs: "Re: A C++ Whishlist"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
