Re: A C++ Whishlist
From: Pete Vidler (pvidler_at_mailblocks.com)
Date: 03/10/04
- Next message: Johannes Bauer: "Re: How do I force my program to dump core?"
- Previous message: Daniel LAUGT: "Re: Why static pure virtual method is not possible?"
- In reply to: Hattuari: "Re: A C++ Whishlist"
- Next in thread: Justin Dubs: "Re: A C++ Whishlist"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 10 Mar 2004 14:53:26 +0000
Hattuari wrote:
> 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.
If you are only talking about regular expression support, then you are
correct. This could easily be added to the language (and I suspect it
will be at the next revision of the standard)... of course, boost is the
place to go until compilers catch up.
However, I believe there are several regexp implementations freely
available on the net. It would not be difficult to just use one of them.
[snip]
> http://www.research.att.com/~bs/glossary.html
> RTFM - "Read The Manual" (The 'F' is silent). Usually a very good idea.
I *know* what RTFM means. And that link is *not* a manual. Instead I was
asking "what is to be said for" reading the manual. There was no issue
that required me to read a manual. I'll post a reply to Justin Dub's
post about this issue, and keep it out of this post.
[snip]
> 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.
And yet you stated your problem as a problem with the way strings work
in C++. std::string (or, more specifically std::basic_string) is not
lacking in features. What it lacks is *platform specific* features.
> 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++.
Is that not exactly what *you* were doing in your first post?
Complaining about C++ string handling not working like Java's?
My argument about '==' wasn't about the way it worked, but the
inconsistency it presented in the language. Specifically that all the
other == operators in Java (to the best of my knowledge) compare values
-- *only* string compares references and no other reference class is
allowed the operator at all.
My point was that std::string has none of these inconsistencies and
problems, so you should find it easier to use.
[snip]
>>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
What do they have to do with C++? C++ is a language and a library. The
language provides support for C-style strings (pointer to characters,
arrays, etc) and the library provides std::string. Changing either (as
you proposed) will not change these other libraries, nor will you be
able to provide their (platform specific) functionality in a standard
library.
>>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?
This is the key issue here: The standard *only* applies to the language
itself and the standard library. Even then it only specifies the
interface and some basic performance guarantees.
Choice in implementation is a separate issue.
And don't forget that it was the *lack* of a standard until '98 that
produced most of the initial string implementations. Writing a string or
linked list class was a classic method of learning C++.
[snip]
> 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.
Of course it will. You are talking about a change that will break every
program that uses structs (that's a *lot* of programs). And for what? A
miniscule, practically irrelevant change to the language that many
people will ignore.
I'll admit changing every "struct" to "class" is not that big an effort,
but it's still a breaking change. Why bother over such a small issue?
> Well there is javap. :-)
So you advocate disassembly to learn how a library works? (A quick
internet search seems to show that that's what javap does?)
[snip]
> 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.
Again, that's your choice. You are quite free to do exactly that.
Even using header files at all is your choice. You are free to go the
Java way and include everything in a ".hpp" or ".cpp" file.. just so
long as the other files include it. You might have a bit of a headache
with compile times, though.
> 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.
I put all default values in the headers. It's another matter of choice.
>>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
I don't see how that it even remotely relevant?
[snip]
> My argument is that much of this could be automated.
But you still haven't said how or why.
[snip]
>>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.
And by doing that you just lost every benefit that forced exception
handling gave you. IIRC "throws Exception" means the user of that method
must also catch "Exception".. which is equivalent to "catch( ... )" in C++?
>>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.
Once more: compiler modes -- nothing to do with the C++ language. Though
I'll admit I don't use exceptions as often as I could.
> That sounds like bad design to me, but 'throws Exception' works.
Throws Exception violates the entire concept that forced exception
handling was meant to deal with. The only difference between C++ and a
Java where people use "throws Exception" is that C++ does not get
littered with the resulting try/catch blocks that make code so much
nastier to read.
But all this is my opinion (of course). I don't want to get into some
kind of C++ vs Java holy war. Just pointing out some of the issues in
different approaches.
-- Pete
- Next message: Johannes Bauer: "Re: How do I force my program to dump core?"
- Previous message: Daniel LAUGT: "Re: Why static pure virtual method is not possible?"
- In reply to: Hattuari: "Re: A C++ Whishlist"
- Next in thread: Justin Dubs: "Re: A C++ Whishlist"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
