Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
C++ in 2005: Can It Become A Java Beater?

By Carnage4Life in Technology
Wed Mar 07, 2001 at 10:56:16 PM EST
Tags: Software (all tags)
Software

Recently in an interview with Linux World Bjarne Stroustrup described his concerns for the C++ language as well as a wish list of libraries he would like added to the standard when it is next up for review in 2005. The following article is an analysis of Bjarne's wishlist as it relates to C++ regaining the ground it has lost due to Java's emerging popularity on the server. I'll also discuss a few libraries I'd like to see added that were not discussed by Bjarne.

NOTE: Bjarne Stroustrup does not mention Java in this interview, Java vs. C++ is simply the direction I have decided to take the results of the interview so that there is something to compare the wishlist against.


Concurrency

Bjarne: I'd like to see a library supporting threads and a related library supporting concurrency without shared memory.

Multithreaded programming is very important because it allows for unique advantages including exploiting parallelism on machines with multiple processors, making programs appear faster by parallelizing disk bound I/O and allowing for better modularization of code.

Currently C++ developers who want to use threads in a standard compliant manner must use the PThreads library which uses the Mutual Exclusion model to handle concurrency. Mutual Exclusion primarily involves using Mutex variables and Condition variables to handle thread synchronization and access to shared data. The main problem with using PThreads in C++ is that the POSIX thread standard is not designed for object oriented programming and one constantly slams into limitations such as being unable to specifically thread objects which hamper design decisions.

There are a few alternatives to using PThreads if standards compliance is not important. RogueWave Software has what is probably the most popular C++ threads library called Threads.h++ 2.0. There are also The Adaptive Communication Environment ( ACE) and ZThread libraries which both contain a number of wrappers to both POSIX and Win32 threads and enable Object Oriented thread programming in C++. Some people have been known to eschew threads and instead use multiple processes and shared memory to achieve their goals.

One of the greatest boons of Java is that it provides a concurrency API which uses the Monitor model. In the monitor model, access to certain shared data is done only through certain synchronized functions and the object is locked while a synchronized function is executing which effectively regulates access to shared data. In the Monitor model there is no need for mutexes or condition variables, all that is needed are wait(), signal() and variations thereof.

Hopefully a thread library will be added that uses the Monitor model or even the more user-friendly Serializer model which differs from the Monitor model in that signalling of threads is done automatically and shared resources can be accessed from outside the Serializer even though concurrency is maintained.

Reflection

Bjarne: I'd like to see something like that supported through a library defining the interface to extended type information.

Currently both Java and C++ support Run-Time Type Identification (RTTI), which is a mechanism that allows one to determine the specific class of an Object and is rather useful when dealing with collections of various derived classes that are referenced via a pointer to a single base class.

Many feel that RTTI is an essential part of Object Oriented Programming, Doug Lea's Usenix paper on RTTI lists several situations where RTTI provides the best solution to certain problems. On the other hand there is also a certain camp of OO purists who argue that using RTTI is usually a sign of bad object oriented design, Scott Meyers is noted as having stated "Anytime you find yourself writing code of the form 'If the object is of type T1 do something and if it is of type T2 do something else,' slap yourself". Meyers is refering to the fact that with the judicious use of polymorphism and encapsulation, the type of an object shouldn't be an issue because each object can perform operations on itself based on an interface specified in a base class. Personally I believe that in the general case Meyers is right but there are certain situations (especially when modules are being written by different developers or interaction is done across different modules) where RTTI is preferrable to using proper OO.

Reflection is the logical next step to RTTI. Reflection enables one to discover the fields, methods and constructors of a class at runtime and manipulate them in various ways including invoking methods dynamically at runtime and creating new instances of these unknown objects. Reflection is primarily useful for developers who create tools such as debuggers, class browsers, interpreters, and a host of others that need to be able to extract information on arbitrary objects and execute code within these objects at runtime. I for one would like to see Reflection added to the C++ standard because it will make writing class browsers in various IDEs a whole lot easier.

Persistence

Bjarne: I'd like to see some support in the Standard Library, probably in connection with the extended type information, but I don't currently have any concrete suggestions.

Object Persistence also known as Serialization is the ability to read and write objects via a stream such as a file or network socket. Object Persistence is useful in situations where the state of an object must be retained across invokations of a program. Usually in such cases simply storing data in a flat file is insufficient yet using a Database Management System (DBMS) is overkill.

There are many subtleties that make a creating an object persistence library a non-trivial problem. Chief of which is the fact that a reflection library or other similar mechanism is needed to be able to dynamically obtain all the fields in a class and load or write them to or from a stream. Secondly, obtaining the fields in an object and persisting them to disk is a relatively easy task when the fields are made up of simple types (int, float, char, etc) but is problematic once the fields are actually objects which may also contain objects, ad infitum. Finally an object persistence format needs to be designed, in this regard I am torn between proposing the use of XML so as to create a human readable, extensible and easily validated format and a binary format to reduce bloat and increase speed of reads & writes.

Although object persistence is interesting I'm not sure it is something that needs to be explicitly addressed by being in the standard but instead should be allowed to be solved by C++ developers as they see fit.

Hash tables

Bjarne: Of course, some variant of the popular hash_map will be included.

This is a no-brainer. The current C++ standard has a sorted hashtable declared in <map> but does not have a facility for developers who want a hash table without the overhead of sorting. SGI's hash_map is commonly used and is expected to make into the standard at the soonest opportunity.

Constraints for template arguments

Bjarne: This can be simply, generally, and elegantly expressed in C++ as is.

Templates are a C++ language facility that enable generic programming via parameteric polymorphism. The principal idea behind generic programming is that many functions and procedures can be abstracted away from the particular data structures on which they operate and thus can operate on any type.

In practice, the fact that templates can work on any type of object can lead to unforeseen and hard to detect errors in a program. It turns out that although most people like the fact that template functions can work on many types without the data having to be related via inhertance (unlike Java), there is a clamor for a way to specialize these functions so that they only accept or deny a certain range of types.

The most common practice for constraining template arguments is to have a constraints() function that tries to assign an object of the template argument class to a specified base class's pointer. If the compilation fails then the template argument did not meet the requirements. Of course, if you are going to do this you might as well forego using templates and simply use pointers to the base class and polymorphism thus avoiding the cryptic compiler error messgaes usually associated with using templates as well as code bloat associated with templates. Bjarne Stroustrup has proposed adding constraints() to the standard. Here are links to code that shows how to use template argument constraints and constrain template arguments regarding built in types.

It should be noted that although Java™ currently doesn't support generic programming, there are extensions of Java that do such as Pizza and GenericJava. Also a proposal to add generic types to Java has been submitted to the Java Community Process and it seems generic programming has been is scheduled to be added to the Java standard soon, some people expect it to make it into version 1.4

Assertions

Bjarne: Many of the most useful assertions [a means of code verification and error handling] can be expressed as templates. Some such should be added to the Standard Library.

Assertions are a useful debugging technique where a predicate is evaluated and if false causes the program to terminate while printing the location of the failed assertion and the condition that caused it to fail. Assertions are usually used during development and removed from the code before the software actually ships.

Errors which the programmer never expects to happen (E.g. age < 0) are prime candidates for using assertions. Typical locations for assertions include; dealing with internal invariants within a function which are usually dealt with via nested if statements where the last else is a catchall that handles "can't happen" values, dealing with control-flow invariants such as the when the default case in a switch statement should never be reached , handling function preconditions (E.g. argv != NULL), handling function post conditions (E.g. x_squared = x * x then assert x_squared >= 0 ) or simply verifying that the state of class is valid (E.g. AVLTree.isbalanced() ).

Currently the only way to use assertions in a portable manner in C++ is to use the ANSI C assert MACRO located in assert.h. There is also the useful static_assert library available at the BOOST site which is probably what the assertion library that will be proposed to the standards commitee will be based on. Assertions are quite useful for debugging and there should be little difficulty in adding a more powerful version of assert to the Standard Library.

Regular expression matching

Bjarne: I'd like to see a pattern-matching library in the standard.

Regular Expressions are a powerful method of describing text patterns and are the major reason that Perl is now the hacker's language of choice for creating programs that search or process text. Until quite recently C++ programmers had to use the C library functions regcmp and regex located in libgen.h on *nix or the RegExp Object via COM on Windows if they wanted to do any sophisticated text processing with regular expression. With the advent of Dr. John Maddock's Regex++ this is no longer the case.

As for actually adding regexes to the standard, I think this is a case of unnecessarily bloating the standard. Java has done fine without having regexes in the standard and there are a slew of Java regex libraries including OROMatcher, pat, and GNU Regexp.

Garbage collection

Bjarne: I'd like to see the C++ standard explicitly acknowledge that it is an acceptable implementation technique for C++, specifying that "concealed pointers" can be ignored and what happens to destructors for collected garbage. (See section C.4.1 of The C++ Programming Language for details.)

I have covered this in a previous article on Garbage Collection and C++ and will thus simply provide an pared down version of that article with minor modifications:

Hans Boehm's site on garbage collection has a well written page that dissects the advantages and disadvantages of garbage collection in C++.

Basically the advantages of Garbage Collection are:
  • 30 to 40 percent faster development time.
  • Less restrictive interfaces and more reusable code.
  • Easier implementation of sophisticated data structures.
  • Eliminates some premature deallocation errors.
  • Uses equivalent or less CPU-time than a program that uses explicit memory deallocation.
While the disadvantages are
  • More interaction with the hard disk (virtual memory/paging) due to examining all pointers in the application.
  • May not work if programmers use various tricks and hacks while coding (e.g. casting pointers to ints and back)
  • May utilize more space than a program that uses explicit memory deallocation.
  • Unpredictable nature of collector runs may create unexpected latency and time lags in the system.
Reference counting although popular is not the only garbage collection algorithm and in fact is considered by language purists as unsatisfactory since it can't handle circular links. There are many more algorithms including Mark-Sweep Garbage Collection, Mark-Compact Garbage Collection, Copying Garbage Collection, Generational Garbage Collection,and Incremental and Concurrent Garbage Collection. Han's Boehm's site discusses mark-sweep garbage collection and not reference counting. This doesn't mean that Mark-Sweep doesn't have its problems (making two passes across memory and the space taken up by the marks is expensive) but these may be remedied by using Generational garbage collection.

Bjarne Stroustrup is very keen on having GC added to C++ but also wants to make sure that the principle of "Only pay for it if you use it" which has been the hallmark of C++ for years is preserved. In my opinion, the advantages of using garbage collection in C++ greatly outweigh any disadvantages.

GUI

Bjarne: It would be nice to have a standard GUI framework, but I don't see how that could be politically feasible.

Not worth discussing because it isn't going to happen for a variety of reasons:
  • The committee will never agree on a UI design model (MVC or UI delegate which will it be?)
  • Will require too much work for library writers.
  • More mature native toolkits will always be ahead of the game.


Platform-independent system facilities

Bjarne: I'd like to see the Standard Library provide a broader range of standard interfaces to common system resources (where available), such as directories and sockets.

Again I must rhapsodize over Java and the way that its Socket classes abstract away completely from the native socket calls. I am all for creating more standard interfaces to system calls beyond file I/O. Then one doesn't need to rewrite code when moving a program from *nix to Windows simply because it opens a socket or reads from a directory.

Conclusion

Wow, that was longer than I expected. I've decided to skip describing the libraries I'd like to see added (I would like an interface keyword) and just go straight to the question.

Do you think if these libraries are added to the C++ standard in 2005, that Java will begin to lose some of the ground it has gained to C++ or do you think that this is unlikely and if so why?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
What addition would you most like to see to the C++ standard?
o Assertions 5%
o Cross Platform GUI 10%
o Regular Expression Matching 9%
o Platform Independent System API 20%
o Object Persistence 5%
o Concurrency (Threading Library) 26%
o Reflection 4%
o Garbage Collection 17%

Votes: 73
Results | Other Polls

Related Links
o interview with Linux World
o PThreads library
o Mutex variables
o Condition variables
o RogueWave Software
o Threads.h+ + 2.0
o ACE
o ZThread
o shared memory
o RTTI
o Doug Lea's Usenix paper on RTTI
o Scott Meyers
o Reflection
o Object Persistence
o Serializat ion
o DBMS
o hash_map
o generic programming
o parameteri c polymorphism
o use template argument constraints
o constrain template arguments regarding built in types
o Pizza
o GenericJav a
o proposal to add generic types to Java has been submitted to the Java Community Process
o assert MACRO
o assert.h
o static_ass ert
o Regular Expressions
o Perl
o libgen.h
o RegExp Object
o Regex++
o OROMatcher
o pat
o GNU Regexp
o previous article on Garbage Collection and C++
o Hans Boehm's
o advantages and disadvantages of garbage collection in C++
o Reference counting
o Mark-Sweep Garbage Collection
o Mark-Compa ct Garbage Collection
o Copying Garbage Collection
o Generation al Garbage Collection
o Incrementa l
o Concurrent Garbage Collection
o Socket classes
o interface
o Also by Carnage4Life


Display: Sort:
C++ in 2005: Can It Become A Java Beater? | 189 comments (187 topical, 2 editorial, 0 hidden)
Maybe a little, but not much (3.75 / 8) (#1)
by fuzzrock on Wed Mar 07, 2001 at 06:07:32 PM EST

The biggest reason that I like Java over C++ is that Java is a more elegantly designed language. C++ tried too hard to retain similarity to C, and as a result (IMHO, of course) remained a difficult language to write good code in. Possible, of course, just like C, but Java is still easier. Adding more libraries will help some, but it won't make the basic structure of the language be OO. That's what I love about Java.

Eiffel? (4.20 / 5) (#4)
by scorbett on Wed Mar 07, 2001 at 07:19:17 PM EST

The biggest reason that I like Java over C++ is that Java is a more elegantly designed language. C++ tried too hard to retain similarity to C, and as a result (IMHO, of course) remained a difficult language to write good code in. Possible, of course, just like C, but Java is still easier. Adding more libraries will help some, but it won't make the basic structure of the language be OO. That's what I love about Java.

That's interesting, I think that Java's greatest weakness is the fact that it is too closely modelled after C++ in terms of syntax. Be honest, how many times have you been zapped by that stupid "if (x = 1)" when you should have put "if (x == 1)". I'll never understand why they decided to carry those odd C++ quirks forward into Java.

One OO language that I admire that really hasn't gotten a lot of attention is Eiffel, developed by Bertand Meyer. Clean syntax, native support for preconditions/postconditions/class invariants/loop invariants, it's every OO geek's dream. I think the reason Eiffel never really caught on is because it's so different from C++. Java took off (at least in part) because it's incredibly easy to make the jump from C++, the languages are almost identical, syntactically. And since there's so many C++ coders out there, it's only logical to try to cater to them.



[ Parent ]

C syntax (3.66 / 3) (#5)
by fuzzrock on Wed Mar 07, 2001 at 07:27:56 PM EST

Syntax carryover didn't bother me too much. I cut my teeth on C (not C++), so by the time I encountered Java I was well and truly used to it. I think they carried them over explicitly because they were trying to win over C/C++ programmers who were used to that kind of syntax - stuff like curly braces and == as an equality operator.

On a related note, I spent 2 hours a couple of days ago trying to figure out why my sprintf wasn't working in PHP. Turned out it was because I was using the C syntax of sprintf(target string, format string, args), as opposed to PHP's, which returns the new string.

I guess the moral of that is that if Java was going to copy C in a lot of ways, I'd just as soon they also copy the little quirks (like that), just because I'm used to them. The BIG quirks, like say... pointer notation... I'm real happy they dropped.

Be honest, how many times have you been zapped by that stupid "if (x = 1)" when you should have put "if (x == 1)".
You may have meant this rhetorically, but I'll answer anyway: not too many. I got used to it in C, so it hasn't gotten me in Java that I remember. Doesn't mean it hasn't happened, just that I don't remember.

[ Parent ]
if (1 == x) (none / 0) (#185)
by wsharlan on Wed Mar 21, 2001 at 01:46:43 PM EST

In C++ always type the constant first:
if (1==x) { ... }
A single = will not compile.

(Ignore a celebrity today.)
[ Parent ]
"if (x=1)" is not valid Java (3.00 / 3) (#20)
by eroberts00 on Wed Mar 07, 2001 at 10:04:47 PM EST

Java certainly carries over some C++ quirks, but not this particular one. The expression "if (x=1)" will not compile in Java. The compiler expects the expression in a if statement to evalute to a boolean, not an int as in your example.

[ Parent ]
Re: Eiffel? (3.66 / 3) (#41)
by dgph on Thu Mar 08, 2001 at 03:26:42 AM EST

Eiffel also has had Constrained Templates for ages (one of the items on Bjarne's wish list).

[ Parent ]
I beg to differ (4.33 / 6) (#16)
by cezarg on Wed Mar 07, 2001 at 08:52:06 PM EST

I actually don't share the urban legend of Java being an easier language to write good code in. There are elements of the language that make it easier for sloppy coders to mess up their job too.

For instance, Java does the array bounds handling itself and throws an exception when bounds are exceeded. So what lousy/lazy Java coders do is have a sweeping catch(Exception e) statement that... does nothing. They simply "shut out the problem". And don't say it doesn't happen because I know it does. More often than I would like to see.

Contrast the described problem with C++ where going beyond the bounds of an array will most likely crash an application forcing the bad programmer back to the debugger to look at what their code really does. In general I find that C/C++ coders have a much better grasp of what their programs really do than Java programmers.

[ Parent ]

No, sorry. (3.00 / 3) (#22)
by fuzzrock on Wed Mar 07, 2001 at 10:45:17 PM EST

Sure. It is possible to write bad java code. I would never say that's not true. And it's really easy to write exception code that does nothing. I've done it myself, in fact. But that's not the point.

As for "Urban Legend", I've written both C++ code and Java code. I like my Java code better. I think it's cleaner, it subscribes better to OO convention, and I can go back 6 months later and edit it. I look at my old C++ code, and whimper. Then I rewrite whatever I needed to do.

[ Parent ]

It all comes with experience (4.00 / 4) (#24)
by cezarg on Wed Mar 07, 2001 at 11:03:17 PM EST

My code keeps improving steadily as I write more and more of it. I also have to program both C++ and Java. I don't notice any significant amount of difference in the "cleanness" of my code according to the language. If anything C++ gives me a few tricks that I can pull to implement some very nice patterns that I still haven't found a solution for in Java. Yes, Java is a simpler language (hence its reputation for being "cleaner" and less "error-prone") but its simplicity comes from its incompleteness. Paramterized types are the prime example of that incompleteness.

[ Parent ]
agree to disagree? (4.00 / 5) (#25)
by fuzzrock on Wed Mar 07, 2001 at 11:11:13 PM EST

Well... Looks like we just disagree. Where you see "incompleteness", I see elegance, and being wary of featuritis (sp?). How about this: you program in C++, and you be happy, and I'll program in Java, and I'll be happy.

And incidentally, I'm happy to admit there are things Java does really badly. The most obvious one is speed - it's slow as hell. But if speed is not a factor, I'm much happier writing Java than C++. So there. : )

[ Parent ]

Java is slow as hell? (4.25 / 4) (#43)
by Blerik on Thu Mar 08, 2001 at 04:29:07 AM EST

I have heard this before, and it is true in some cases only, eg: using java bytecode on a JRE with sloppy/bad JIT compiler.

but...

Java on a good JIT compiler is quite fast.
native Java is very fast (see GCJ)
native Java on a 200 node LAN/WAN cluster is so fast a C++ coder is going to have to work hard to get faster code (see Manta)

--Blerik


[ Parent ]
what an interesting opinion (none / 0) (#103)
by zzzeek on Thu Mar 08, 2001 at 11:46:54 PM EST

You are literally arguing that C++ is a better language because C++ applications crash your machine more seriously than Java applications? Perhaps there can be a "training mode" for java, where a side effect of bluntly catching and discarding RuntimeException is the VM purposly locks up your machine, would that make it better? We can even add some scary beeps and maybe even electric shocks to the programmer. Do you honestly believe that design and form can be better learned (or even learned at all) through negative reinforcement and inconvenience rather than genuine interest in improvement?

In the meantime, those of us that already know how to write good code, or at least possess regular learning skills and interest in the subject matter, can forego the practice of habit reinforcement via usage of intentionally painful development platforms, and instead use a clean and efficient (not to mention inspiring) purely object oriented language, rather than an arcane and convoluted afterthought to C.



[ Parent ]
wake up and smell the coffee, mate (none / 0) (#149)
by cezarg on Sun Mar 11, 2001 at 02:20:03 AM EST

can forego the practice of habit reinforcement via usage of intentionally painful development platforms, and instead use a clean and efficient (not to mention inspiring) purely object oriented language, rather than an arcane and convoluted afterthought to C.

Why am I replying? From the quoted paragraph we can obviously tell that you already made up your mind on the subject matter. Good for you. But when you're done coding your next megacool applet take a second look around you and you'll see that Java is not the answer for everyone in every case. There are few java desktop applications for instance and those that do get shipped are ususally not usable for a variety of reasons. From my experience speed and lack of stability were the two leading ones.

As for a programmer being penalised I think it is not such a bad idea. Bugs are errors and if a programmer makes an error they should face the consequences. Such is life. Doctors, engineers and all kinds of people are held accountable for their errors. Can't see why it should be any different with programmers. I for one can't stand sloppy coders who just write crap that sometimes works by a touch of miracle and a little help from the oh so forgiving jre. As for the positive/negative reinforcement crap take that back to the highschool it came from. When your next paycheck depends on the quality of the stuff you ship you'll want your environment to smash little errors right in your face. Because from my experience customers are not terribly good at "positive reinforcement" especially when they pay big bucks for the stuff I ship.

[ Parent ]

OO vs multi paradigm (4.20 / 10) (#49)
by codemonkey_uk on Thu Mar 08, 2001 at 08:45:40 AM EST

Adding more libraries will help some, but it won't make the basic structure of the language be OO.
You seem to see this as a bad thing, but many developers consider it to be a good thing. C++ is a multi paradigm language, which can be used to develop OO code, but can also be used to develope procedural, generic, functional and spagetti code.

As a professional developer I don't want to have my hand held, I want to be free to do bad things, because if I can't do bad things then I am limited in the number of different good things I can do.

Some problems simply do not fit the OO model, and if your developing in a pure OO development enviroment, then you have to force a square peg into a round hole.
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

Co-op vs. individual (3.66 / 3) (#58)
by fuzzrock on Thu Mar 08, 2001 at 10:26:17 AM EST

When I'm writing code that nobody else in the world is going to see, I pretty much agree with you. I don't want to have my hand held so much, I want to be able to do things my own way. Frequently, the way I want to do things works with Java, but some of the time it doesn't. In those cases - get this - I DON'T USE JAVA.

But a lot of the time, I'm working in an environment when my code has to work with other peoples. In those cases I want THEIR hands to be held, I want to NOT have to look at their code, and I want the language to enforce that as much as possible. Java really strongly encourages well-encapsulated code. C/C++ doesn't very much. Allows for it in a vague sort of way, but it's still infuriating.

[ Parent ]

Yes! fascist parsers are for the other guys... (2.00 / 3) (#162)
by bobsquatch on Mon Mar 12, 2001 at 07:13:59 AM EST

s/java/Python/gi;
s/c\/c\+\+/Perl/i;
s/well-encapsulated/readable/;
s/peoples/people's/; # speling nazi :)

Hear, hear.

Perl's #1 problem is that your cow-orkers have to type use strict. Perl's #2 problem is that they never do. Perl's #3 problem is that they then complain about how Perl is a write-only language. (#4: strict isn't enough.)

Here's a ha-ha-only-serious solution, though:

# cd /usr/bin
# mv perl realperl
# cat > perl
#!/bin/sh
PROG=$1;shift
cat $PROG | sed -e '1d' | realperl -Mstrict - $@
^D
# chmod 755 perl

Yeah, it's a bit of a cludge to get around Perl's weird re-exec of the shebang line while compiling. Don't try this at home, it won't work. :)


[ Parent ]

I see you have a stalker (5.00 / 1) (#59)
by spiralx on Thu Mar 08, 2001 at 10:34:04 AM EST

It looks as though el_guapo is after you as well for you giving him a zero in the argument detailed in this diary.

Maybe having ratings stalkers is like a rite of passage here on k5? If you haven't been stalked by someone without a life, then you're not part of the cabal :)

You're doomed, I'm doomed, we're all doomed for ice cream. - Bob Aboey
[ Parent ]

cabal? (none / 0) (#130)
by fuzzrock on Fri Mar 09, 2001 at 11:37:00 AM EST

There is no K5 cabal.

[ Parent ]
A couple of points (4.50 / 8) (#2)
by spacejack on Wed Mar 07, 2001 at 06:31:31 PM EST

First, thanks for taking the time to write the article. :)

I'm a bit surprised that you didn't discuss standard library formats, which are my own pet peeve with C/C++ (someone mentioned this in another recent C++ article.. maybe you.. but I can't find it at the moment). Anyways, my own feeling would be that compilers should adopt an agreed upon library format, with the option to produce compiler-specific libaries in the cases where there are optimization benefits to be gained. Even with compiled languages like Java, it's incredibly useful to simply be able to replace a class file with little effort, regardless of the exact compiler being used. It's also one of the main reasons Microsoft has such a monopoly on Windows C/C++ compilers. (Both Borand and mingw are free, but the library incompatibilities are major drawbacks).

As far as garbage collection goes, I'd be against it. If you want that kind of hand-holding, I'd go with a different language. One of the main reasons I use C/C++ is the control you have over resource consumption (it's tough enough dealing with the unknowns, like swapping for example, that the OS is going to throw at you). Then again, as an option it might be okay.. but if having a gc is such an important issue, why not use Java instead?

We also shouldn't forget that C/C++ are primarily used in cases where you need to optimize for a particular platform without resorting to asm. The "newer" languages like Java etc. are good for optimizing in a design or general sense, but poor at optimizing for specific implementations.

C++ ABI is being worked on (4.60 / 5) (#19)
by Carnage4Life on Wed Mar 07, 2001 at 09:55:44 PM EST

I'm a bit surprised that you didn't discuss standard library formats, which are my own pet peeve with C/C++ (someone mentioned this in another recent C++ article.. maybe you.. but I can't find it at the moment). Anyways, my own feeling would be that compilers should adopt an agreed upon library format, with the option to produce compiler-specific libaries in the cases where there are optimization benefits to be gained. Even with compiled languages like Java, it's incredibly useful to simply be able to replace a class file with little effort, regardless of the exact compiler being used.

The newest draft standard for the C++ ABI is still being worked on. Problems in the draft and possible solutions are still being worked out, you can keep track of it here on the C++ ABI Open Issues page


[ Parent ]
GCC 3.0 will use this C++ ABI by default (5.00 / 2) (#123)
by Per Abrahamsen on Fri Mar 09, 2001 at 06:19:22 AM EST

Even though the ABI is only for IA64, most of it is processor neutral, and GCC will use it on all their platforms.

The promise the GCC C++ ABI will be stable from release 3.0. The reason it hasn't been stable before, is that the language has been in flux. GCC 3.0 is also the first GCC release to implement the language and libraries described in the final standard.


[ Parent ]
Stupid Question if anyone has the anster (none / 0) (#138)
by logistix on Fri Mar 09, 2001 at 08:54:25 PM EST

but reality.sgi.com seems to disagree with my firewall.

Does the ABI do anything to take care of changes to class structures and their respective binary format(ala COM)? If not a standard library format is pretty useless. You still can't use a centralized library unless it's locked down for life. Do a global search for mfc*.dll on a windows machine and you'll see what I mean.

I've been a big fan/user of C++ for a while, but doing COM really turned me off to it. You have to jump through hoop after hoop after hoop, when all you're really trying to do is actually take advantage of code reuse. Thats one of the promises OO made, and reusing source code doesn't cut it.

[ Parent ]
Java vs. C++ (4.16 / 6) (#3)
by eLuddite on Wed Mar 07, 2001 at 06:46:24 PM EST

C++ is clearly incredibly versatile and complete. It would be nice if people plumbed all of its OOP features instead of using it as C with classes but I'm only happy that there isnt any onus to master it before actually using it.

Do you think if these libraries are added to the C++ standard in 2005, that Java will begin to lose some of the ground it has gained to C++ or do you think that this is unlikely and if so why?

For Java to "lose some ground" to C++, wouldnt it have to compete with C++?

Not being a Java programmer, I just want to get a sense of how, exactly, Java threatens C++? I mean, I have never, not one time, seen shrink wrapped software written in Java. I'm under the impression that Java is being used much the way VB is used, as glue for multi-tier in-house custom apps. Java and C++ seem to occupy different problem domains.

(One other thing: The performance claims of Java advocates that it rivals and sometimes exceeds C++ performance is not not doing their cause any good. Java continues to be a slow, lumbering resource hog on the desktop.)

---
God hates human rights.

They Do Compete On The Server (4.33 / 3) (#14)
by Carnage4Life on Wed Mar 07, 2001 at 08:37:28 PM EST

For Java to "lose some ground" to C++, wouldnt it have to compete with C++?

On the desktop there is very little if any competition between Java and C++. On the other hand a lot of middleware that used to be written in C++ is now being written in Java. Also the number of applications using RMI and EJB is rising, these are applications that would have been written using C++ and DCOM or CORBA a few years ago.



[ Parent ]
Competing languages (3.50 / 2) (#81)
by inpHilltr8r on Thu Mar 08, 2001 at 02:32:21 PM EST

In the same way that cross-head screwdrivers compete with hammers?

[ Parent ]
expansion of c++ wont help... (3.00 / 5) (#6)
by rebelcool on Wed Mar 07, 2001 at 07:32:28 PM EST

c++ has enough complexity to it now with the various add-ons and illegible error messages you get with it. While c++ is still very very useful today, my language of choice has become java because its easier to get things done in, and corrects a few of the ambiguities that c++ suffers.

Mind you, i dont do kernel programming or low level stuff like that, i'm a server programmer and using java lets me find problems and security holes before they begin.

C++ needs to be replaced. Adding libraries and more things to it aren't going to fix it, just make it worse and harder to program in and debug. Sometimes its best just to start with a clean slate.

COG. Build your own community. Free, easy, powerful. Demo site

Replaced, but with what? (3.33 / 3) (#11)
by ucblockhead on Wed Mar 07, 2001 at 08:22:47 PM EST

I agree that it needs to be replaced, but I've yet to see a real competitor for what it is good for. (And I do have a problem with the title of this article. I don't see C++ as a "Java Beater", nor do I see Java as a "C++ Beater" as the languages are not designed with the same target in mind.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
you are correct sir (2.50 / 2) (#18)
by rebelcool on Wed Mar 07, 2001 at 09:05:31 PM EST

as far as I know, a good true replacement doesnt exist yet. It'll have to be something with the same low-level capabilities and optimizations that c++ allows, but with the OOP of java. Though I wonder if such a thing is really possible..whoever devises a way deserves a Turing award.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

objective-c (3.50 / 2) (#45)
by bluesharp on Thu Mar 08, 2001 at 05:30:14 AM EST

Objective-C comes awfully close to what you're looking for - a superset of C, as C++ is, but much more dynamically OOP. Oh, and gcc already compiles it. But you'll want the libraries from www.gnustep.org to do anything real.

[ Parent ]
kernel programming (2.50 / 4) (#29)
by crazycanuck on Wed Mar 07, 2001 at 11:59:16 PM EST

for kernel programming you'd use ASM and C, not C++.

[ Parent ]
see? (2.33 / 3) (#30)
by rebelcool on Thu Mar 08, 2001 at 12:21:23 AM EST

not my forte :)

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

modules in C++ (3.33 / 3) (#40)
by plastik55 on Thu Mar 08, 2001 at 02:30:33 AM EST

is is possible to develop loadable modules in C++ however. For some specialized purposes it may speed development for cases where you want to incorporate a lot of code into the module (i.e., when the module contains higher-level code than just talking to the hardware.)

Most of the time you want C though.
w00t!
[ Parent ]

Kernels in C++ (4.50 / 4) (#53)
by Pseudonym on Thu Mar 08, 2001 at 08:59:52 AM EST

for kernel programming you'd use ASM and C, not C++.

Only if you were hacking a kernel which was already written in ASM and C. On the other hand, there are plenty of kernels written in C++. Some that you might have heard of are Windows NT, Eros, BeOS and Chorus. (Chorus is used as the kernel layer of JavaOS, BTW.)


sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
[ Parent ]
No... (none / 0) (#82)
by inpHilltr8r on Thu Mar 08, 2001 at 02:35:02 PM EST

...you'd use asm and C.

Don't presume to speak for those of us that do write real-time, speed critical, embedded system code, and are quite happy to do so in C++ and as little assembler as we can get away with.

[ Parent ]
I couldn't disagree more (4.00 / 1) (#74)
by krlynch on Thu Mar 08, 2001 at 01:07:23 PM EST

I couldn't disagree more :-) I use both Java and C++ regularly, and there are things for which Java is a huge mess. For example, even if Java WAS fast, it is nearly impossible to do numerical computations with the language. Some parts of the Java standard libraries are very poorly designed, from an OO point of view. And the Swing UI library is hideously complex (although extremely powerful and flexible). And the lack of support for generic types makes lots of Java code extremely icky.

Which is not to say that C++ is perfect: the Standard Library does not include many things that it really needs (threading support, network stream support, among others). and the language itself is missing things it should have (a ^^ operator, and a typeof being my pet peeves, something like the restrict keyword in C99), not to mention being already hideously complicated (mostly, I think, as a result of supporting MI and C compatibility).

Both have their place, and I don't think that either will be going anyplace soon.

[ Parent ]

indeed (1.00 / 1) (#89)
by rebelcool on Thu Mar 08, 2001 at 05:55:05 PM EST

for server programming, java is my jesus.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

Give it some time (none / 0) (#171)
by Rhamadanth on Wed Mar 14, 2001 at 04:20:06 AM EST

I think that people are overlooking the relative youth of Java. C++ has had a lot more time to refine what parts of the language people have identified as important. All things considered, Java is doing pretty well.

I disagree on one point, though. I don't think C++ has any place in this world. There are several language that I can think of off the top of my head that could do a better job than it does, at half the complexity. But have a special place in my heart for hating C++, so I'm a bit biased that way.
-- The /bin/truth is out there.
[ Parent ]
C++ v. Perl (3.90 / 10) (#7)
by rusty on Wed Mar 07, 2001 at 07:47:16 PM EST

...or, Random Musings of a Perl Zealot...

What's interesting about this, to me, is how much of this is already in perl (or is rendered irrelevant by a different language design). For those of you interested in perl, here are my thoughts.

Concurrency

Ok, we start with the big miss. Threading in perl is still in a rather sorry state. It was added in 5.005, but a lot of people thought it sucked. It was pretty much rewritten in 5.6, which contains both models. The new 5.6 threading is a hack where the perl interpreter is actualy cloned for a new thread. The point of this mostly was to enable fork() on platforms that don't support process forking natively.

At present, threading is still considered "experimental", and may very well be rewritten yet again.

Reflection

Perl's got this, and it comes pretty much for free due to the basic design of OOPerl. Classes, in perl, are not new data types (except when they act like them sometimes :-)). They're just perl data types (array, hash or scalar) that know what package they belong to. So, if you wanted to do one thing if you have one class, and another if you don't, you'd just use ref() to find out which you're dealing with. Like:

package Person;

# Create the object
sub new {
   my $pkg = shift;
   my $class = ref($pkg) || $pkg;
   my $self = bless( {}, $class);

   # Initialize me
   $self->init();

   # That's it!
   return $self;
}

sub init {
   my $self = shift;

   # Initialize our normal properties...
   $self->{name};
   $self->{address};
   $self->{age};

   # That's all for now.
   return $self;
}

package Employee;

# We're a subclass of Person
@ISA = qw(Person);

# No need to add a new(), because it's part of Person
# so just overload init to add a salary property
sub init {
   my $self = shift;

   # Initialize our normal properties...
   $self->{name};
   $self->{address};
   $self->{age};

   # Add a salary property
   $self->{salary};

   return $self;
}

... and in some other place...

sub get_salary {
   my $self = shift;
   return 0 if (ref($self) ne 'Employee');
   return $self->{salary};
}

Now, this is even a dumb example, because you don't need to go to all that trouble of initializing properties anyway, since if you ask for one and it doesn't exist, perl will auto-vivify it for you. Which means that in fact, return $self->{salary} would work for either a Person or an Employee. But I'm trying to demonstrate ref() here, so the example is contrived to use it.

Persistence

There's world+dog ways of doing this in perl. Storable and Data::Dumper both do it fine. This is another feature of perl objects just being perl data types to begin with. With eval(), it's trivial make a text representation into a perl object. You can also use XML, but it's kind of the red-headed stepchild of the perl serialization world, because, as someone put it at the last YAPC, "XML solves problems other languages have." The overhead of using XML is only worth it if you absolutely have to, like you need to serialize data and make it usable by non-perl code.

Hashes

I don't think much needs to be said about this. The hash is the fundamental chi of perl. There is nothing a perl hash can't do, which can possibly be done with a hash.

Template contraints, Assertions

Ok, I'm not altogether clear on what either of these are, so I'm going to just skip them. If anyone can clarify, that'd be neat.

Regexps

'Nuff said.

Garbage Collection

Perl of course uses a straight refcount GC. This works for probably 99.9% of all needs, because perl is designed to be a once-through language. That is, it's irrelevant if your garbage collector is super-precise, since the vast majority of scripts will run through once and then destroy everything on exit.

This all changed a bit with the advent of mod_perl, and now the various GUI perl bindings (perl/TK, GTK/perl, etc). But mod_perl is where it really shows up. A mod_perl application is very long-running, since the interpreter never exits until you restart apache. This has brought a host of issues with memory allocation and garbage collection to light for the small fraction of us who make it our bread and butter.

See, perl never actually free's anything. The garbage collector will mark memory as available for use, when there are no more references to it, but it's not handed back to the OS. It's just held available for perl to use whenever it needs it again. For short-running programs, this is a plus, because it acts basically like a memory cache -- it's faster to allocate memory you already have available, than to malloc more from the OS.

But in mod_perl, this means that the amount of memory your apache process will use is always the largest amount they've ever needed so far. This means that basically, apache processes using mod_perl never get smaller, they can only grow. There are hacks to get around this, such as an Apache module that will kill off httpd's when they reach a certain memory use, but still, it's a hack. I'm fairly in favor of making it possible to actually free memory in perl, but I imagine there are serious difficulties with this, or it would've been done already.

The other issue is that it's much easier to create circular references that never get garbage collected in mod_perl, because you can't rely on the end-of-execution global DESTROY. This kind of bug is often very tricky to find and diagnose, and is not a familiar bug for most perl coders to begin with.

GUI

I think much like C++, perl will never include any kind of GUI facilities in the language itself. This is much better done with modules, as terminal interfaces and a whole lot of other things already are.

Platform Independence

Perl also really shines here. Files, sockets, all the standard things are platform independent in perl, if you use the supplied modules for such things. The IO:: classes are particularly nice to have for cross-platform code.

Conclusion

Perl is better than C++. ;-)

Just kidding. The two are very different language, intended for very different uses. Nevertheless, people who still think perl isn't a "real" language should really take another look at just how much you can do with it. OOPerl especially is just a joy to work with, the vast majority of the time.

____
Not the real rusty

Assertions (4.40 / 5) (#10)
by ucblockhead on Wed Mar 07, 2001 at 08:20:16 PM EST

Assertions are a wonderfully handy tool for debugging. Basically, in the C/C++ world, you compile either in "release" or "debug" mode. You then get a handy little macro that tests a condition and that only exists in debugging mode. For example:

void CheckName(char*Name)
{
    assert(cp);
    assert(strlen(cp) < 80);
    if( cp && 0 == strcmp(cp, "BorkBork") ) {
        DoStuff();
}

If you are compiled in "debug" mode, the assert() call will complain loudly in some useful way if cp is NULL. (In Visual Studio, for example, it'll go immediately into the debugger.) In "release" mode, the assert() is completely removed and the code runs as if it didn't exist at all. The idea is that you sprinkle your code with asserts() so that while you are testing, you discover unexpected conditions immediately and then when you are done testing, they are automatically stripped out, so you don't pay the performance penalty for all the code used just for testing.

Unfortunately, they are underused. Ideally, you'd throw them at the beginning of every function, asserting what are "expected" or "normal" values for parameters. When used like this, they can help catch all kinds of bugs that might otherwise get missed.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Assertions (4.00 / 2) (#52)
by Bad Harmony on Thu Mar 08, 2001 at 08:57:07 AM EST

Better yet, leave the assertions in the released software. They are not that costly and they are very helpful in catching and identifying bugs in deployed software.

I've always had trouble understanding the mindset that believes error detection features should be disabled in operational software.

5440' or Fight!
[ Parent ]

Unobstrusive assert()'s (4.00 / 2) (#54)
by slaytanic killer on Thu Mar 08, 2001 at 09:17:12 AM EST

But you'll want the asserts to shout to a logfile, or somewhere else unobstrusive. Most software is fault-tolerant enough that the effects of object corruption will just be annoying to the user, and give her enough time to save her work. When the user complains that the software gave her whiplash, tech support can request a copy of the log along with her description of events.

You'll just want to be sure that a stacktrace is sent to the logfile by default, so you know where in the code complained.

[ Parent ]
Why that's bad... (none / 0) (#67)
by ucblockhead on Thu Mar 08, 2001 at 11:58:18 AM EST

The reason that this is bad is because suddenly you have to worry about what assertions you have in there. When used properly, they are good not just for finding bugs, but for testing your own assumptions.

Also, assertions are generally used to detect programming errors, not errors that arise from user input. In theory, you should be testing enough during the debug phase that your assertions will never fail after release.

Assertions are just one kind of error detection, one specifically geared to the debug cycle.

A great example is a "reality check". If you've got a function that takes a string argument, and you know that the argument will "usually" be under fifteen characters (perhaps it is a name) put it in an assert. Such a reasonableness check will catch an error that throws random garbage at the function. But since names aren't inherently limited, and one out of a thousand might be more than fifteen characters, you don't want it in released software.

There are much better ways to handle errors for realise software in C++. Asserts are a debugging tool, and shouldn't appear in released software unless it is released only to programmaers.


-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Agree, and... (5.00 / 1) (#94)
by pete on Thu Mar 08, 2001 at 07:48:03 PM EST

I agree with you...I think we're saying the same thing, but I'll phrase it slightly differently.

First of all, assertions are extremely useful. I live in the Java world now, but when I was a C/C++ programmer, my code was filled with assertions. I often wish I could do the same thing in Java.

Assertions abort your program if they fail. You do not want this happening in production code. A previous post says something to the effect of "I don't understand stripping error handling from production code." That's not what happens at all. Your production code should be robust enough to handle any conceivable error in an intelligent way, not by aborting the program. Assertions are there to notify you during the development process that you've made an assumption that is wrong. Assertions should definitely be stripped automatically when you make a non-debug build. The MSVC library has a nice set of macros used for this.

Microsoft themselves badly misuse their assertion macros in code that they generate for things like ATL. Never use assertions alone to check for conditions that may really occur at runtime.

My opinions on the use of assertions were shaped largely by reading the great book Writing Solid Code.


--pete


[ Parent ]
Assertions (4.00 / 1) (#107)
by ucblockhead on Fri Mar 09, 2001 at 01:17:51 AM EST

It is ironic that Writing Solid Code is published by Microsoft Press, isn't it. I suffered from some of those ATL asserts today, in fact. It is kinda silly to assert at a point where you'd crash in release mode!

Visual Studio's assert capabilities are extremely good. You can indeed abort on assert, or you can merely log assertions, or write your own assertion handlers. Really cool stuff.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Perl and platform independence (4.75 / 4) (#12)
by pete on Wed Mar 07, 2001 at 08:31:59 PM EST

I love Perl. If I have my choice of using a language to do something (as I usually don't at the office), I use Perl.

Having said that, Perl does a pretty crappy job of really remaining platform independent with things like threads (which, yes, you already mentioned are not in a final state) and sockets. While learning Perl around a year ago, I decided to write a Junkbuster-like proxy server to get familiar with various parts of the language. I run Win2k, Linux, and FreeBSD at home, so I wanted it to run on all 3.

The Unix/Apache model of socket handling is: accept a connection, fork a process (ignore select() for now, I'll get to that), hand off the connection. The Windows model is: accept a connection, create a thread, hand off the connection. Perl's fork() was sufficiently broken under Win32 such that the socket was unusable in the new thread.

Of course, there's select(), which, if you're not familiar with it, allows you to poll a vector of sockets (or other file handles on Unix) to see what's going on; for example, if they've received any data. This allows you to conserve threads and/or processes by not having one for each connected client. The way Perl does select, it actually parses the C-language include files on your machine to get the proper constants and exports these into the Perl namespace. I ended up actually getting this to work...by hacking the Perl source code and building my own version!

Try to do the same thing in Java, and you'll see how platform-independent sockets and threads should be. That's one area where Java does a great job.


--pete


[ Parent ]
On Reflection (4.66 / 3) (#17)
by Carnage4Life on Wed Mar 07, 2001 at 08:55:54 PM EST

Your example using ref() deals more with RTTI (determining the class's type at runtime) than Reflection (invoking methods and accessing fields at runtime). Although from reading pages 295 - 297 of Programming Perl it looks like method calls can be specified with the actual method name being a variable. i.e.

$methodname = "get_salary";
$sal = $aPerson->$methodname();


is valid code.

Of course, full fledged Reflection should allow introspection (i.e. calls like Field [] getFields() ) which gives the ability to query the object directly for metadata such as its fields, methods, inheritance hierarchy, etc.



[ Parent ]
I see (4.00 / 2) (#31)
by rusty on Thu Mar 08, 2001 at 12:31:36 AM EST

Yeah, I see. Not being a C++er I'm not familiar with the jargon of your strange planet. ;-)

Yes, you're right. ref() is for determining what class an object belongs to. Determining what it inherits from is dead easy, since inheritance is simply determined by a package global array called @ISA. So say I get some object, and I want to know all the classes it inherits from. I'd do:

sub who_am_i {
   my $mystery_obj = shift;

   my $class = ref($mystery_obj);
   my $parents = $class.'::ISA';
   foreach my $parent (@{$parents}) {
      print "I'm descended from $parent!\n";
   }
}

I believe the dispatcher will look for methods in the current package, then in the parents in the order in which they appear in @ISA.

Finding out what properties an object has is just a matter of finding out what kind of thing it is, and getting each element. If your object is a hashref (which is the majority of them), you'd just do a foreach my $prop (keys %{$obj}) { ... }.

Methods, well that's a little trickier. There may be a way to do that, but I don't know what it is. If there's anyone around who knows more OO Perl than me, and has ever had to do this, please chime in. :-)

____
Not the real rusty
[ Parent ]

Reflecting on methods (4.00 / 2) (#47)
by kbob on Thu Mar 08, 2001 at 08:11:58 AM EST

Rusty said:
Methods, well that's a little trickier. There may be a way to do that, but I don't know what it is. If there's anyone around who knows more OO Perl than me, and has ever had to do this, please chime in. :-)
Finding a class's methods is easy. For each class, the compiler creates a hash called %ClassName::.

So, to print all the methods in class Foo, you do this.

foreach (keys %Foo::) {
print "$_\n";
}

K<bob>

[ Parent ]

Template constraints (3.00 / 1) (#35)
by tpv on Thu Mar 08, 2001 at 01:35:56 AM EST

The idea basically is:

You have a template in C++ that is templated by type (the usuall case) something like:
template <typename TYPE>
TYPE * duplicate( TYPE * )
That takes a pointer to an object, and makes a copy.

Now, your code might not really be able to duplicste all types, it might really only duplicated objects that inherit from "BaseClass".
There are three ways to express this:

  1. BaseClass * duplicate( BaseClass *) ;
    Kill the template == Bad!
    You changed your return type, so:
    Derived * foo = duplicate( bar ) ;
    won't work.

  2. template <typename TYPE>
    TYPE * duplicate( BaseClass * ) ;
    This fixes the return type, but it breaks a few things.
    • Your code now looks like:
      Derived * foo = duplicate<Derived>(bar) ;
    • You can do:
      bar = new BaseClass ;
      Derived * foo = duplicate<Derived>(bar) ;
      and end up trying to duplicate a "BaseClass" into a "Derived". That's bad.

  3. template <typename TYPE>
    TYPE * duplicate( TYPE * arg )
    {
      constrain<BaseClass>( arg ) ;
    ...

    This is ugly, and has some issues.
    It works, but it's not nice.

The best solution is to have something like:
template <typename TYPE : BaseClass>
TYPE * duplicate( TYPE * arg )
to specify that the template type must derive from BaseClass.


--
'I would therefore like to posit that computing's central challenge, viz. "How not to make a mess of it", has not been met.'
Edsger Dijkstra (1930-2002) EWD1304
[ Parent ]

An example of when not to use templates (4.00 / 3) (#37)
by Carnage4Life on Thu Mar 08, 2001 at 02:03:47 AM EST

The best solution is to have something like:
template <typename TYPE : BaseClass>
TYPE * duplicate( TYPE * arg )
If you are simply going to specify a base class in the template definition then there is no point in using templates when you can simply use pointers to BaseClass types in your algorithms.

Templates are useful for algorithms where the target types are not in the same inheritance hierarchy but using them instead of using good Object Oriented Design (i.e. subtype polymorphism ) is a poor practice. The ensuing code bloat caused by the fact that the compiler generates a new class for each instance of the template class that uses a new type plus the fact that template errors are usually hard to debug makes gratuitious use of templates unwise.

Also a more elegant solution to solving the problem you proposed was linked to in my article, but here it is again. Basically the goal is to stop incorrect code from compiling instead of risking a runtime error like some of your proposed solutions.


[ Parent ]
Oh go on then... Python :) (4.33 / 3) (#50)
by spiralx on Thu Mar 08, 2001 at 08:51:07 AM EST

Since you did the Perl thing, I'll do the Python thing :)

Concurrency

Well, Python does have the thread module, but it appears as though it's not amazingly great. It does work in Windows 95/NT, IRIX, Solaris 2.x and any OS that uses pthreads though. A better implentation is acheived through the threading module, which provides higher-level functions roughly modelled on Java's threading model.

Reflection

All Python namespaces are implented as dictionaries (hashes) called __dict__, so you can query them for available fields and methods at runtime. Python objects also have a __super__ attribute containing a list of superclasses.

Persistance

The default thing here is the pickle module which allows arbitrary values and objects to be serialised, and the shelve module allows you to use files as if they were Python dictionaries to store data in.

Hashes

Dictionaries are fundamental Python data types.

Assertions

Python has the assert keyword, which is activated if the global __debug__ keyword is true.

Regexps

Python has the comphresensive re module, which is about as complete as Perl's regexps, if not as conventient to use.

Garbage collection

Python also uses straight reference counting, but there is as of version 2.0 an optional garbage collector for cyclical references which can be accessed using the module gc. This is only a recent addition however.

Note that JPython (a version of Python written using Java rather than C) inherits all of Java's garbage collection routines automatically.

GUI

There's Tkinter, wxPython, PythonWin and several other GUI frameworks IIRC, several of which are cross-platform.

Platform independence

As with Perl, Python is pretty much 100% platform independent. Only the most obscure modules tend to be platform dependant - sound file modules for instance.

Conclusion

Python is better than Perl and C++.

Well maybe not, but it's their equal in terms of what can and can't be done with it. As with everything there's a time and a place for Python, and it's especially good for quickly doing development that can then be easily converted to C++ thanks to it's clean OO syntax.

You're doomed, I'm doomed, we're all doomed for ice cream. - Bob Aboey
[ Parent ]

And assertion (3.33 / 3) (#60)
by costas on Thu Mar 08, 2001 at 10:51:52 AM EST

Right on! and you forgot assertion as well (as of 2.1 I think).

Perl is good, perl is fine, but Perl isn't OOP. If you'd like all the above features in an OOP language, use Python. If you want native speed, go grab SWIG and write your bottlenecks in C/C++.

Oh, well, at least it works for me :-)...



memigo is a news weblog run by a robot. It ranks and recommends stories.
[ Parent ]

"perl isn't OOP"... (none / 0) (#144)
by rusty on Sat Mar 10, 2001 at 12:38:38 PM EST

I hear this a lot, as, I assume, do most of the people who work with object-oriented perl. And yet, no one has ever been able to explain to me why they think it's true. Damian Conway did a pretty good job at YAPC19100 explaining why OO-perl does support everything any object oriented language can. And yet the myth persists...

My only theory so far is that perl "isn't object oriented" because it doesn't force OO on you in all cases without exception. That is, you can write some code that is object oriented, and some that isn't. Hell, it's actually easy to write code that is either OO or not, depending on whether the caller wants it to be. So, basically, this is a put-up-or-shut-up: either admit that "Perl isn't OOP" is a euphemism for "Perl isn't limited solely to OOP", or prove that there is some OO thing that perl can't do. I'll accept either. :-)

____
Not the real rusty
[ Parent ]

*cough* Ruby *cough (5.00 / 1) (#142)
by naasking on Sat Mar 10, 2001 at 09:21:59 AM EST

Since we're getting into some language advocacy... Check out Ruby. ;-)

Especially, check out the (somewhat biased, yet still valid) language feature comparison.


[ Parent ]
Choose OCaml a really BIG language (none / 0) (#147)
by arturo on Sat Mar 10, 2001 at 11:13:06 PM EST

1) It is functional. Better than imperatives ones (von neumann CPU like thinking). 2) Strong typed -> debugging = (very little) -> 0 3) Automatic type inference. avoid bloated unnecessary declarations. 4) GC no comments. 5) High order funtions. 6) High level native types (lists, tuples ...) 7) Labeling, variants & polymorphic types 8) Extensible semantics 9) OO support 10) Imperative and mutable data support (sometimes helps) 11) Module support, funtors ... 12) A superb library 13) Easy C interface other libs GTK MYSQL O8i ..., your own libs. 14) Extensible semantics 14) Bytecode and native compiler. 15) Exelent implementation near to C C++ perfomance low memory requirements 16) Very easy to learn and not need to deal with implementation issues. In my opinion better than C C++ Java Python Perl Ruby ... Ocaml is really BIG. Let your your mind fly. Let the CPU boder with the tiny stuff.
Arturo Borquez
[ Parent ]
Garbage Collection (3.60 / 5) (#8)
by ucblockhead on Wed Mar 07, 2001 at 08:04:25 PM EST

While garbage collection would be nice, it would be even nicer to fix auto_ptr to the point where it could really be used. Specifically, fix auto_ptr so that it can be used with the STL containers and also add a standard reference counter template that worked with the containers. That'd remove a lot of the need for garbage collection.

The attraction smart pointers have had for me is taht they allow you to stop worrying about freeing pointers without getting the overhead of a garbage collector.


-----------------------
This is k5. We're all tools - duxup

garbage collection (3.50 / 2) (#15)
by Delirium on Wed Mar 07, 2001 at 08:47:53 PM EST

While in many of the simpler situations I'd agree that yes, manual memory management is more efficient, in the case of the majority of large complex programs a language-implemented garbage collector can simply do a better job than a bunch of manually-implemented hack-jobs (such as a ton of reference-counters; many of the automatic GC algorithms are much more efficient than reference-counting is). It's analogous to the old argument about manual optimization of register variables vs. compiler determination - once programs got to a certain size and once compiler technology advanced enough, the compiler could in nearly all resonably non-trivial cases do a better optimization job than the programmer. Same with programming in a higher-level language vs. manual ASM and with letting the compiler GC vs. manual memory management.

[ Parent ]
Not manual (3.00 / 1) (#23)
by ucblockhead on Wed Mar 07, 2001 at 10:50:07 PM EST

Bear in mind that I am not talking about manually implementing hacked together reference counting schemes (which is what we have to do now) but adding a good, usable reference counting scheme to the language so that coders can just use it, without thought.


-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Why that instead of GC? (4.00 / 2) (#42)
by Delirium on Thu Mar 08, 2001 at 04:06:09 AM EST

But why would that (having a language-based reference counting scheme which a programmer could manually use) be preferable to just letting the compiler garbage-collect? That way if reference-counting happens to be optimal it could do that, but if another GC algorithm is superior it would use that instead. Plus it saves some development time.

[ Parent ]
Both (none / 0) (#109)
by ucblockhead on Fri Mar 09, 2001 at 01:50:47 AM EST

Well, I'd rather have the option of having both, but if I'm working in a language designed for speed, I damn-well don't want a garbage collector jumping in at random times. I want to be able to control when and where things happen for efficiency's sake.

If I was willing to accept the loss of control, I'd not want to bother with C++ garbage collecting as there's a perfectly good language more suited to apps where efficiency and control are less important: Java.

In other words, I see little reason to make C++ look like Java for the simple reason that I already have Java available.


-----------------------
This is k5. We're all tools - duxup
[ Parent ]

depends on the application (5.00 / 1) (#63)
by rebelcool on Thu Mar 08, 2001 at 11:34:49 AM EST

for meat-critical applications (such as avionics systems, life support, nuclear plant controls) you do *not* want an asynchronous garbage collector because would you want processing to stop for a few seconds during landing or a nuclear meltdown?

While many (most) applications benefit from a GC, certainly not all.

COG. Build your own community. Free, easy, powerful. Demo site
[ Parent ]

perhaps (none / 0) (#85)
by Delirium on Thu Mar 08, 2001 at 04:10:49 PM EST

Well, there are garbage collection systems which don't have to pause to make GC passes (they in effect interlace the GC with the normal program operation). I'm not entirely knowledgeable about how exactly any of the particular algorithms work so can't give much more detail than that.

But yeah I agree that there will always be some situations where manually managing things is the better solution - after all many embedded systems are still hand-coded in assembly (or in very low-level C as a portable pseudo-asm).

[ Parent ]

Stroustrup makes me angry... (2.42 / 7) (#21)
by scriptkiddie on Wed Mar 07, 2001 at 10:22:11 PM EST

I'm currently reading his book on C++. If I hadn't gotten the book for free, I would have returned it - the design of the language makes very little sense.

I realize Stroustrup is a very experienced engineer and is very well-respected within the software community. But parts of his book make me very, very angry. For example, this explicit inclusion in the language of a kludge for handling unexpected exceptions - I can't think of any valid use for this whatsoever. Templates are really interesting, but using them feels like using some crazy macro preprocessor - a lot of the template code feels like a workaround for the fact that the language has no really transparent memory management. Then there are the whole sections of C++ that it seems nobody ever uses or has ever used.

The worst part is that C++ lacks many features I'd really like to see in a language. Java's Interfaces make perfect sense to me, and C++ multiple inheritance just can't accomplish the same semantics without more kludges and workarounds. The standard library objects aren't particularly useful, unlike Java's amazingly complete standard library. So most programs I look at invent their own code for data types like dates and strings, since the standard ones are so anemic.

But Java has a few very serious problems as well - most importantly, the lack of a decent GUI library. Swing doesn't count, it's slow even on the Athlon 950 I'm writing this from. And Swing's designers really had no idea about elegance.

So what's my dream programming language? Right now, I think it's Python. Of course, Python isn't strongly typed; that can make certain programming mistakes far too easy. But the very clear syntax, featureful yet learnable standard objects, and total cross-platformness make it very attractive. It doesn't hurt that I can write a Python program that will explore its own environment in real time, showing me the available objects and functions and letting me see how each object is called; this is marvellous for debugging.

The problem with Python is that it's roughly 500 times slower than C++ - no joke. But unlike Java, many of Python's libraries are actually written in C, so as long as you restrict yourself to algorithms already implemented in a native library Python can keep up nicely.

I guess my dream language would be a compiled version of Python, with the addition of strong typing and interfaces. Then the runtime library would contain an interpreted version of the same language, so incredibly useful stuff like RTTI and dynamic evaluation still work. And it would have a really good GUI library and application server. Never mind that the programming effort involved in making that would be in the tens of thousands of hours, it would still be really cool :).

Read Lipman then (3.50 / 2) (#26)
by cezarg on Wed Mar 07, 2001 at 11:11:54 PM EST

Stroustrup is considered too "heavy" as a C++ tutorial book. The guy is a propeller head but he's in a different league than 99.99% programmers out there. And his books are a reflection of that fact. C++ beginners are usually adivsed to pick up the "C++ Primer" by Lipman (spelling?) which serves as a very nice intro that eases you into the language semantics. Then you go on to read Stroustrup. This is the path that I took and was much happier than a friend of mine who "dived right into" Stroustrup's books. Oh, and avoid the efforts of Herbert Schildt. His books are nice and simple because they contain many glaring omissions and inacuracies in the name of "keeping things nice and easy".

[ Parent ]
Another good book (none / 0) (#157)
by dennis on Sun Mar 11, 2001 at 10:04:30 PM EST

I'm reading Accelerated C++: Practical Programming by Example by Koenig and Moo. Here's a review at Dr. Dobb's. This is the first book that made me want to learn c++. They start right out using the standard library, and cover an awful lot in a slim, concise book--they try to show how professionals actually use c++, instead of the common "here's c, here's the extra c++ features" approach.

[ Parent ]
Blame Brian Kernighan (3.00 / 2) (#27)
by br284 on Wed Mar 07, 2001 at 11:21:50 PM EST

I have him for lectures every Tues. and Thurs. and we're currently going over C++. It seems like every goofy thing within the language was the result of Kernighan's poking and prodding of Stroustrup to include some random function so that he could write funky awk-like programs.

I still find the fact that you can redefine the = operator to be a bit bizarre.

-Chris

[ Parent ]
Don't Blame Bad Code On The Language... (4.83 / 6) (#28)
by Carnage4Life on Wed Mar 07, 2001 at 11:49:03 PM EST

For example, this explicit inclusion in the language of a kludge for handling unexpected exceptions - I can't think of any valid use for this whatsoever.

What feature are you talking about?

Templates are really interesting, but using them feels like using some crazy macro preprocessor - a lot of the template code feels like a workaround for the fact that the language has no really transparent memory management

You've lost me with this statement. Template syntax can get hairy but this is due to the choices made in choosing the syntax (note that GenericJava and Pizza also use similar syntax) and has nothing to do with memory management. Also most people typedef hairy template definitions so using templates is rarely as ugly as it should be. E.g.
typedef map< long, const Message*> Messages_Map_t;
typedef pair<unsigned int, const char*> Username_N_Uid_t;
Then there are the whole sections of C++ that it seems nobody ever uses or has ever used.

Believe me, every feature in the C++ langauge is being used by somebody somewhere. Just because you haven't seen uses for them in programs you have looked at does not make them useless. I've never seen memmove or signal used in C code before but it doesn't mean they aren't, it simply means I haven't seen enough code.

Java's Interfaces make perfect sense to me, and C++ multiple inheritance just can't accomplish the same semantics without more kludges and workarounds.

What kludges and work arounds are you describing? An interface is simply a class where all its functions are pure virtual functions. Declaring a Java style interface is relatively easy, here's a good example.

The standard library objects aren't particularly useful, unlike Java's amazingly complete standard library. So most programs I look at invent their own code for data types like dates and strings, since the standard ones are so anemic.

I am yet to see a homegrown string class or set of data structures & algorithms that matches the STL. The only reason that there is a such a proliferation of homegrown strings and data structures is that for over a decade there wasn't a standard library and people had to create their own. Now one exists there is little reason to use homegrown data structures and strings in new C++ projects. As for dates, it is true that one has to use C date functions or create homegrown Date classes. As for all the other libraries that Java has over C++, it is clear from this article that Stroustrup is interested in changing that.

PS: As someone else has already pointed out. Stroustrup's book is a bad first C++ book and is more for use as a reference. I suggest getting Lippman's Essential C++ and C++ Primer.


[ Parent ]
unexpected, et. al. (none / 0) (#72)
by krlynch on Thu Mar 08, 2001 at 12:48:06 PM EST

For example, this explicit inclusion in the language of a kludge for handling unexpected exceptions - I can't think of any valid use for this whatsoever.
What feature are you talking about?

I suspect that he is alking about the std::unexpected() family...although I certainly don't understand the "kludge" comment. That the writer can't think of a valid use of the feature suggests only that he/she didn't read the book too carefully :-)

[ Parent ]

Stroustrup (3.60 / 5) (#73)
by MarkCC on Thu Mar 08, 2001 at 12:58:18 PM EST

This may perhaps not make me the worlds most popular person, but I feel obligated to point out that when it comes to programming language design, Stroustrup is a complete boob.

I've met the guy in person several times, and he's an extremely smart, extremely likable guy. The problem is, his background is not in programming languages or compilers, and despite his continuing work on C++, he's never bothered to learn much of anything about language design. (He in fact has stated that he doesn't believe that there is any need to study language design before designing a language.) And that ignorance has most definitely impacted the design of C++.

Every time that I've seen him, he's managed to make at least one major statement with absolutely no basis in reality. To give a very prominent example, in response to question about templates, template constraits, and the code bloat associated with them, he responded "There is *no* known solution to providing general constraints on parameterism, and it is impossible to define a mechanism for parametric type expansion that doesn't produce the kind of explosive growth seen by C++."

The problem with the first statement is that CLU, the very first programming language to allow the definition of parametric user defined data types did include a general mechanism for expressing type constraints. A CLU like mechanism can declaratively do anything that Stroustrup's constraint function method does.

The problem with the second statement is that both CLU and the ML family of languages have successfully been using parametric types without explosive code expansion. There's a fairly obvious trick called "boxing". Now, boxing has its problems, no doubt. But to claim that it's an unsolvable problem is nonsense when a solution exists.

But Stroustrup didn't know about either of those. He just made the statements without bothering to learn enough to know if they were true.

He's also quite fond of quoting the "Only pay for what you use" standard, and he genuinely believes that C++ conforms to it. Unfortunately, it doesn't. If you assume that compilers suck and absolutely never do any useful optimization at all, then C++ comes close to that - but in the real world, with the compilers that we use, there are an awful lot of features of C++ that absolutely create a significant performance cost whether you use them or not.

For example, the exception handling system. Exception handling means that stack frames must maintained in a very specific fashion, so that if some external code throws an exception, the stack can be properly unwound. Even if your code doesn't use exceptions, if it uses any externs, than it must be compiled as if it did. And that constraint on the structure of the stack prevents a ton of useful optimizations.

For another example, the implicit constructors for type conversion in C++ can produce an absolutely dramatic performance impact without it being at all obvious to even a highly skilled programmer. (I once implemented a system in C++, which was executing a particular loop incredibly slowly. It turned out that there was an implicit type conversion calling a constructor, which made my linear time algorithm shift to quadratic time. And the only way that I figured that out was to read the output from the compiler!)

It's a major frustration to many of us who've spent a lot of time doing work in language design and compiler implementation to hear Stroustrup being treated as an expert in the topic. And it's particularly frustrating to recognize how often he makes serious misstatements which are assumed to be true, because after all, he designed C++, so he must know what he's talking about.

[ Parent ]

I do not think so. (4.80 / 5) (#86)
by your_desired_username on Thu Mar 08, 2001 at 04:10:58 PM EST

There is *no* known solution to providing general constraints on parameterism,

In D and E, Stroustrup describes Clu's solution to constraints on parameterized types, and explains why it would be a bad idea for C++. (Essentially, Clu's constraint system assumes (a) the type system has a high degree of consistency, and (b) the type system was designed with constraints in mind. Neither was feasible for C++, as it inherited its fundamental types from C.) So I do not believe Stroustrup made that statement.

it is impossible to define a mechanism for parametric type expansion that doesn't produce the kind of explosive growth seen by C++

In D and E, and in TCPL (3rd edition) Stroustrup points out several solutions to the 'explosive growth' problem (In D and E, he refers specifically to ML as the source of one solution.) So I do not believe the 2nd part of your quote either.

Given that D and E refers to many papers on the design of ML, CLOS, and others, I also doubt the assertion that 'he's never bothered to learn much of anything about language design'.

I think the real problem here is that the majority of the language design community does not like backwards compatible languages. When one chooses to make language X++ backwards compatible with language X, one encounters the following kinds of problems:

(1) Language X was designed by people with a different notion of what constitutes 'good programming' So it contains operations that X++ might be better off without.

(2) Language X contains lots of well-known design mistakes. But backwards compatibility prevents one from fixing them.

(3) New features required by X++ require changes to to features inherited from X - but backwards compatibility prevents one from making such changes, leaving one with a less consistent (or less feature-rich) language.

C++ is littered with examples where backwards compatibility with C broke consistency, made easy language design problems hard, and prevented the use of good language design ideas discovered by good people working on languages like ML and Haskell.

Most of the language design community considers backwards compatibility (especially with C) to be the worst possible decision a language designer could make. But backwards compatibility with C has probably had a larger positive effect on C++'s popularity than all other C++ features combined - especially in the early days.

Stroustrup foresaw this, made C++ backwards compatible with C, and waded into the ugly swamp of language design problems that decision created - and he emerged with a language that many people use, and that many people love - while good clean languages like ML, Haskell, CAML, etc, languish in obscurity.

(The fact that most of the ld community strongly prefers functional languages, and C++ is nothing like a functional language, certainly helps fuel the fire as well. There - I've given you the comeback chance that the coiners of the term 'functional language' intended the supporters of such languages to have. )

(Yes, I know, it's bad form to throw gasoline and detegerent to troll who obviously intended to start a flamewar - but I've got low willpower.)



[ Parent ]
C++, Stroupstrup, and Language Design (4.00 / 4) (#127)
by MarkCC on Fri Mar 09, 2001 at 10:34:44 AM EST

I seriously considered whether I should bother replying to this, but I've decided that I probably should. I'll do my best to keep it short.

I am not lying about the things that I've heard Stroustrup say. Yes, he has learned from his mistakes. One cannot get up in front of a group of compiler and language design specialists, and make dreadfully wrong statements without getting called on it. But that doesn't mean that he's taken the time to really understand things; he's done enough token study to justify past decisions, and that's about all.

For example, his arguments in D&E and other places about some key issues of the C++ design make a token gesture to acknowledging things, without any deep understanding.

For example: he does talk about CLU. But his argument for why CLU style constraints wouldn't work in C++ aren't true. In fact, the "constraint" function method that he proposes is, essentially, a CLU style constraint on C++ templates expressed in a rather messy form.

(For those who haven't seen CLU, the way that it works is that when you define a parametric datatype, you declare a list of operations that must be implemented for anything used to instantiate that type. The constraint function mechanism proposed by Stroupstrup is a non-invokable function containing invocations of all of the operations that must be provided by any type that instantiates the template. The key difference between the CLU mechanism and the C++ mechanism is error messages: in C++, you get error messages pointing at lines in the expanded constraint function when the compiler compiles the fully expanded template; in CLU, the compiler signals the error at the code point where the parametric type is instantiated. If you've ever tried to debug a template error involving an improper template type parameter for a class in the STL that indirectly involves three or four layers of template instantiations, you'll appreciate why that early error detection is so valuable.)

Now, I won't argue that in a lot of matters, the academic language design community has their collective head up their ass. Nor will I argue the point that there have been a lot of unfair criticisms lobbed at C++ by purists who dislike C++ for silly, obscure theoretical reasons.

But I think if you sit down and actually read the C++ standard, and consider some of its fundamental flaws, and read Stroustrups justifications for those flaws, that a very large number of them are based on ignorance. And I think that's a shame.

I genuinely believe that if you started with one of the very early versions of C++ (when it was just C with classes), and carefully extended it, taking advantage of what the language design community learned in the last two decades, that you could design a truly beautiful language that maintained as much backwards compatibility with C as C++. Instead, we got a bloated monstronsity. And based on having listened to Stroustrup on several occasions, I think that a lot of the blame sits squarely at his feet.

[ Parent ]

Features (none / 0) (#83)
by inpHilltr8r on Thu Mar 08, 2001 at 02:53:36 PM EST

Templates are really interesting, but using them feels like using some crazy macro preprocessor
Templates can be thought of as type safe macros, but they're also a whole lot more than that.
Then there are the whole sections of C++ that it seems nobody ever uses or has ever used.
Like which? I've been using C++ for 13 years now, and I think the only feature I've never used is RTTI, and I'm sure you can find people who swear by it. If you name a feature, I'm sure I can give you an example, along with justification, and a source snippet.

[ Parent ]
Cross-pollination (4.50 / 10) (#32)
by vasi on Thu Mar 08, 2001 at 12:42:29 AM EST

I use both C++ and Java, and they're both just fine by my standards. But they also both have a bunch of features the other could use. Here's my (not quite complete) list of what I'd like to see moved from one language to the other. These would all have to be optional I suppose, so we don't break other code or other programmers :-). Hopefully some other k5'ers can point me to libraries which will let me do some of these things. Try not to mind the massive whinefest, and instead just tell me why I'm mistaken when I am. Remember, I'm just learning...

1. The speed thing: Well, ok, there's no way Java will be just as fast as C++ any time soon. Though it might be possible to compile Java to true machine-code (when needed), to get things done a bit faster.

2. Global functions and data: Yes, globals can be a Bad Idea. But no, typing Math.sin() over and over should not be necessary. It would be nice to be able to write a package of classless functions and data; effectively global, but because it's in a package it wouldn't pollute the global namespace.

3. Non-inlined funcs in Java: Why not? I don't always want to have to Javadoc everything to see just the definition of a class.

4. Machine independent sizes: This one is a no-brainer. There's no harm in creating a standard "int32" type...is there?

5. Java arrays: Begin able to both initialize an array with the = {1, 2, 3} syntax, *and* access the length member is very nice.

6. On-stack objects: If I want to create an object on the heap, that's great...but if I *know* I won't need an object after the current function is done, why do I have to dump it on the heap in Java?

7. Forward declarations: I want a compiler smart enough to do it for me. Why make the programmer worry so much? :-)

8. The preprocessor: Well, I wish I could just get rid of the C/C++ preprocessor--but unfortunately, that'll never happen. Oh well.

9. Import and packages: No dumping everything into "std" like C++ does; no need to actually recompile the source like with #includes.

10. Auto-initialization: It's good.

11. No pointers in Java: Fine by me, as long as they have modifiable references. Speaking of which, why *doesn't* C++ have modifiable references?

12. Deep cloning: Copy constructors make things very easy. Why does Java make deep cloning so difficult?

13. Destructors: Why have to free resources on your own in Java? Why not just have them freed when the object using them is out of scope? (See my issue with on-stack objects).

14. Default arguments: Just about the only reason for not using them is to reduce complexity. But it's an optional thing: if you mind the complexity, don't use them.

15. Goto: Why is there still a "goto" command in C++? Harmful...

16. Object: I like the idea of inheritence from object. If only because heterogeneous collections could be useful, with a reflection class.

17. Templates: A biggy. Java needs them; one more cast of an Object extracted from a Vector and I'll go nuts.

18. Garbage collection: I'd really really like it to be there; but only so I can turn it on and off. What would be really cool is selectively enabling it, so that where I'm dealing with some complicated structure I can turn it on, but where I'm confident that everything will be destroyed as it leaves scope, I can leave it off. Is this even possible? Does it make sense?

19. Threads: The portable version, please.

20. Nested class' automatic reference to surrounding class: It's yet another good thing in Java.

21. Pacakge vs. friends access: I'll go with package, at the risk of losing a little bit of functionality.

22. The super keyword: It's good. But explicit contructors are good too, and I'm hesitant to relegate them to the trash.

23. Virtual: I'd like C++ functions to be optionally automatically "virtual". Also, "abstract" makes more sense than "virtual void f() = 0", at least to me.

24. Interfaces and multiple inheritance: I like the MI concept; anything that can be done with interfaces can be done with MI pretty simply.

25. Exception specifications: "throws" should be part of a function's signature, and should be enforced as in Java.

26. Operator overloading: I like it; if you don't, don't use it, but let me use it if I like. Matrix algebra looking like C.times( A.plus(B).minus(D) ); is very ugly.

27. Const correctness: I *need* a way to do this in Java. And no, I don't want to create a "constMyClass" wrapper for every class I write. While I'm on the subject, a good way to pass by value (eg: by copy) rather than by reference would be nice in Java. Writing (MyClass)myObj.clone() is unwieldy, and won't work the way it's expected to because of the shallow clones.

28. Cross-platform: This is a toughie. I don't care as much about byte-code as about being able to compile my C++ on the MacOS, Windows, Linux, etc. A standard GUI would be hard, though *very* useful; but portable threads and sockets are doable.

29. Javadoc and headers: I much prefer the Javadoc way.

30. What else did I leave out?

Ok, rant's over now. Thanks for reading!

vasi

Wow, long list.... (5.00 / 3) (#33)
by Carnage4Life on Thu Mar 08, 2001 at 01:09:21 AM EST

1. The speed thing: Well, ok, there's no way Java will be just as fast as C++ any time soon. Though it might be possible to compile Java to true machine-code (when needed), to get things done a bit faster.

GNU has gcj which does exactly that.

9. Import and packages: No dumping everything into "std" like C++ does; no need to actually recompile the source like with #includes.

C++ has namespaces which work exactly like packages. As for not having to recompile the source when an object file changes in Java, this is due to the fact that Java uses dynamic class loading and creates a class file for each class. The prospects of C++ object code becoming dynamically loaded or dynamically linked (in the case of libraries) would require changes I am unsure anybody is ready to make.

11. No pointers in Java: Fine by me, as long as they have modifiable references. Speaking of which, why *doesn't* C++ have modifiable references?

C++ does have modifiable references. Unfortunately most C++ programmers have a C background and prefer to use pointers. Below is some code from Stroustrup's book.

int i = 1;
int& r = i; // r and i now refer to the same int
int x = r; // x = 1
r = 2; // i = 2


13. Destructors: Why have to free resources on your own in Java? Why not just have them freed when the object using them is out of scope? (See my issue with on-stack objects).

That's what the finalize() method is for.

16. Object: I like the idea of inheritence from object. If only because heterogeneous collections could be useful, with a reflection class.

All classes inheriting from Object is primarily a kludge to get around the fact that Java doesn't have templates. It isn't needed in C++.


[ Parent ]
Modifiable references (4.50 / 2) (#38)
by Khalad on Thu Mar 08, 2001 at 02:08:22 AM EST

C++ does have modifiable references.

Not the C++ that I know. By modifiable references the idea is that you can change what the reference variable refers to, as in something like:

  int  i, j;
  int &ref = i;

  ref &= j;
Here '&=' is overloaded as some kind of "reference assignment" operator.

What's the point? Well, this would be almost identical to using pointers, except

  1. You would use the reference syntax instead of pointer syntax. Most people prefer this.
  2. The reference would always be valid, which cannot be guaranteed with a pointer. You have to check for a null pointer presently when you use pointers this way (when passing as function parameters, for example).


You remind me why I still, deep in my bitter crusty broken heart, love K5. —rusty


[ Parent ]
Ummm (none / 0) (#137)
by Srin Tuar on Fri Mar 09, 2001 at 05:50:39 PM EST

3. References would always need storage space. (Currently auto storage references dont exist per se)

4. &= already has a meaning.

5. They would have to be checked for NULL.

6. Suddenly they become a redundant syntax for pointers.

[ Parent ]

Clarification (none / 0) (#140)
by Khalad on Fri Mar 09, 2001 at 11:04:46 PM EST

3. References would always need storage space. (Currently auto storage references dont exist per se)
You are partially correct. If you create an auto reference which refers directly to another variable at a visible scope the compiler should be able to optimize it away. But typically you use pointers as parameter types, return types, or mixed with pointer notation (e.g. 'field (*new Item)' as an initializer in a class constructor). In these cases, and in most others that cannot be optimized away, a reference variable is treated as an automatically-dereferenced pointer.
4. &= already has a meaning.
That is why I said it was overloaded.
5. They would have to be checked for NULL.
No, they wouldn't. How do you create a null reference? You can't dereference a null pointer and assign that to your reference variable. References have to be initialized when declared. There's no such thing as a null reference.
6. Suddenly they become a redundant syntax for pointers.
The difference is that you can't ever have a null reference. References are a slightly different beast from pointers: pointers can be null, references cannot. If you could modify a reference you could still not make it null.

What's the point? You can remove the ability to have null pointers in places they never belong. That way you don't have to do any unnecessary assertions. Better to have your conditions enforced at compile-time than at run-time.


You remind me why I still, deep in my bitter crusty broken heart, love K5. —rusty


[ Parent ]
namespace != package (none / 0) (#87)
by krlynch on Thu Mar 08, 2001 at 04:58:37 PM EST

C++ has namespaces which work exactly like packages.

Just a minor correction ... a namespace does NOT work exactly like a package. A package has all the properties of a namespace (with respect to name lookup), but adds additional access privileges. That is, while putting a class in a C++ namespace gives it no special privileges with respect to the members and functions of other classes in that namespace, putting a Java class in a Java package gives that class certain access privileges to the members and functions of other classes in that package that classes OUTSIDE the package don't have (I hope that made sense...that sentence was entirely too long).

For clarification, you'll need to go to the Jave language specification and tutorial, because I don't remember how all the rules apply.

[ Parent ]

Partly right... (none / 0) (#114)
by vasi on Fri Mar 09, 2001 at 02:40:59 AM EST

Here are the things I need to clarify a bit:

GNU has gcj which does exactly that.

But note that gcj will support AWT on X and GTK only, at least so far. Needs some more work.

C++ has namespaces which work exactly like packages.

A reply brought up the difference between namespaces and packages. Another, important difference is with the standard #includes. In Java, the standard java.* packages are separate. In C++, there's no easy way to say using std::functional;. You have to then use using on every name from functional you use, or on all of std::. Basically, C++ style includes pollute the standard namespace.

Finally, the finalize() method doesn't do what I want. For example, if I create some sort of myFileClass, which opens a file, I could close the file in its destructor. If I wait for the gc to call finalize() on it, that would leave the file open until the gc has to run. So in Java, I'm forced to write:

public void fun(Object arg) {

myFileClass mfc = new myFileClass("myFile");
doSomething(mfc);
myFileClass.close();

}


That's ugly code. I'd much prefer destruction on leaving scope, when it's applicable.

vasi

[ Parent ]

A few comments (3.50 / 2) (#46)
by Simon Kinahan on Thu Mar 08, 2001 at 06:48:46 AM EST

I mostly agree. A few thoughts, though ...

Speed: Doesn't matter much, does it ? Sure, if you're doing embedded missile control systems or something, speed matters, but you should be hand crafting assembler. If you're writing server side applications, a good JVM is 3/4 the speed of C++ anyway. The only place Java really falls down on speed is GUI stuff, and if C++ gets a portable GUI library, it will fail there too. The fundamental problem is not language speed, but presenting a common API to GUI systems on many platforms.

Global: I don't want globals, but it sounds like your actual problem is the wacky approach to primitive types in Java, where there's both a simple type, and a reference type, and a bunch of random methods scattered all over the place for every primitive type. A better solution would be to represent all primitive types as objects from the programmer's perspetive, but to special-case the storage of the common case of a primitive object assigned to a variable of primitive type. Then you can do (45.0).sin, rather than Math.sin(45.0). C# actually gets this more nearly right than Java, but Smalltalk was better.

Stack vs Heap: I don't want to have to think about whether I need by objects outside of my function, but that doesn't stop the compiler figuring it out for me. In the most common cases, a little compile time (or perhaps runtime in some nasty cases) analysis could be done to find the objects that never leave the function scope and store them on the stack.

Deep cloning: is impossibe in general. Even simple cloning is not always straightforward, depending on whether you rely on identity for the class concerned. Consider deep-cloning a node in a graph.

Templates: I'd like Java to have generic types, but not C++-style templates. I want to be able to constrain the type of template parameters, and I also want to be able to declare variables of type template<t> where t is unbound.

Garbage collection: Turning it on and off selectively is a bit icky. C# makes some efforts in this direction, but I'm not keen, as they allow you to write "unsafe" code with conventional C-style pointers. I'd prefer to see more compiler optimization of memory management, even if this required me to make some special declarations that the compiler could then check. I don't want the compiler to have to take it on trust that I got my deallocations right.

Multiple inheritance: Its useful for mixins (classes designed as plugins to other classes), but otherwise it more trouble that its worth. Look at C++'s appalling complicated inheritace semantics. Thats what MI does for you.

Operator overloading: I can see why you want it for numeric stuff, though to be honest Java has so many failings on that front I'd probably just use another language. For anything other than that, I'll shoot anyone who uses it.

Const: I've never understood why anyone would care enough about this to go to all the pain of getting the declarations right. As a matter of interest, then, why do you care ?


Simon

If you disagree, post, don't moderate
[ Parent ]
Multiple Inheritance (4.00 / 1) (#84)
by inpHilltr8r on Thu Mar 08, 2001 at 03:24:26 PM EST

I use multiple inheritance for a couple of reasons.

One is in compound POD types, which is probably evil, and wrong, but has no overheads, saves keystrokes, and makes the C coders on my project sweat more...;)

The other is to define abstract interfaces to otherwise unrelated classes. I used this to implement UI event handlers for application objects in a database package. Where a table, a row, and a query had completely different internal representations, each object could inherit an MAppleEventHandler (which consisted almost entirely of pure virtual functions) to present a uniform interface to the UI code.

The overhead in terms of the slightly increased cost of virtual function calls was minimal, and comparable to any scheme we could come up that didn't use MI. The syntax and semantics certainly weren't any more complex, and indeed, made the relevant areas of the code eminently more readable.

[ Parent ]
Speed (none / 0) (#113)
by inpHilltr8r on Fri Mar 09, 2001 at 02:33:16 AM EST

Speed: Doesn't matter much, does it ? Sure, if you're doing embedded missile control systems or something, speed matters, but you should be hand crafting assembler.
Strangely enough there exist many applications where java runs unacceptably slowly, and assembler takes too long to develop under.

Like, say, operating systems, client side applications, video games...

[ Parent ]

Stating the obvious (none / 0) (#121)
by Simon Kinahan on Fri Mar 09, 2001 at 04:47:20 AM EST

Of course there are, though I'm not at all sure that "client side applications" always run too slowly in Java. Modern machines with a 1.3 VM run swing apps quite satisfactorily.

There are other reasons to avoid writing OSes in Java other than speed. You'd need to write a lot of primitives in C, essentially a whole RTOS core, before writing the Java, so what would be the point ?

Simon

If you disagree, post, don't moderate
[ Parent ]
Interesting...(plus long bit on consts) (5.00 / 1) (#117)
by vasi on Fri Mar 09, 2001 at 03:43:19 AM EST

What's really interesting about your post is the thought of writing something like (45).sin(). It seems like an awfully good idea. A few issues would need to be dealt with though: First, who gets to decide which members are implemented by this standard int class? Can I add to this, if I need another global function? Also, some things like firstInt.max(secondInt) look pretty strange. I still think that class-less functions are just fine, as long as they're only available when import-ed.

Deep cloning is impossible only as much as serialization is impossible. For example, let's say you did want to deep-clone a Vertex in a Graph. Since the references to the attached edges are to external objects, they'd be marked as "external" or "uncloneable" or some such. Other things, such as the Vertex's position or the flow through it, could still be cloned into the new Vertex. Now, when you want to deep-clone a Graph, it's that much easier: Each time you need to duplicate a vertex, you can just call deepClone() and you'll know that everything that's not the responsibility of the Graph class will be cloned; the things which Graph *is* responsible for, like the conenctions between nodes, will be coded into Graph's deepClone() method.

I hope that made sense. I just had to do a really ugly implementation of that in order to deep-clone a tree, and I wish more of it was built in so I could concentrate on the hard parts.

As far as multiple inheritance is concerned, a compromise is needed. Banning it outright, or introducing all these complicated rules, are both not terrific solutions. I'd like it if MI was allowed, but only when there's no conflict between the names of the members of the base classes. *poof*, goodbye ugly semantics.

You're probably right about using another language for numerical calculations. But other languages don't always have built-in GUIs, or platform independence, or even objects, so I'd rather improve Java.

Last, we've got "const". Well, what I like about const is it lets me write a class and expose only what I need to; it's an encapsulation thing. For a longish example, let's say I want to do stuff with that Graph from before:

// In Graph.cp

void addVertex(Vertex& v) {
   v.setGraph(this);
   // implemenation...
}

Vertex& getVertex(int index) {
   // implementation...
}


// in Main.cp

int main(void) {
   Graph startGraph, endGraph;

   // do stuff...

   Vertex target = startGraph.getVertex(0);

   if (target.flow() > 100) {
      endGraph.addVertex(target);
   }

   // more stuff...
}


This implementation uses a back-reference from a Vertex to the containing Graph, not an unreasonable thing to want, so a Vertex *can't* be in two Graphs. When addVertex() changes the graphReference of the Vertex, we know something's happened which shouldn't happen. What's gone wrong?

So our situation involves three methods, addVertex(), getVertex(), and main(). Because a Vertex can't be in two Graphs, these methods have a responsibility to ensure that doesn't happen. Without consts, there's no way to ensure that responsibility is handled: the author of main() doesn't know whether he's allowed to do what he's doing, if he doesn't know the internal implementation of a Graph and a Vertex.

If instead we declare

const Vertex& getVertex(int index);

now addVertex() can't modify the Vertex it's passed, so the code won't compile. This tells the author of main() that he's not allowed to put a Vertex in two Graphs; it encapsulates the implementation of Graph and Vertex so the author of main() doesn't have to know about it to find out what (s)he's allowed to do.

That may have made no sense whatsoever. I can just say that I've found that the longer a Java project gets, the more I detest having to *remember* which code is responsible for maintaining the constancy of something that must remain constant. You can think of it as encapsulation (like me), or as type safety (like Marshall Cline; see http://users.utu.fi/sisasa/oasis/cppfaq/const-correctness.html).

vasi



[ Parent ]
Further comments (5.00 / 1) (#122)
by Simon Kinahan on Fri Mar 09, 2001 at 05:14:04 AM EST

If you make primitive types into classes, and primitives into objects, the problem of adding new methods is a little tricky. Smalltalk systems used to let you edit the system classes, but Java doesn't allow this. You could perhaps allow the primitive classes to be subclassed to permit additional functions, but then primitive literal constants would have to be interpreted differently depending on context, to sometimes be Integers, and sometimes be MyIntegers. There's nothing to stop this, but it might get a bit confusing.

I was not clear enough when I said deepCopy was impossible. What I should have said is that deepCopy depends on the semantics of the class in a way the compiler can't understand. You're quite right that you can implement a system just like the serializer and do deep copies that way, but for some classes this is inappropriate.

On const. I kind of see what you are getting at, but I don't grok your example. If you rep=turn a reference to a const vertex, that stops you changing it in any way, rather than merely stopping you from changing the graph it belongs to, right ? so if you need to have modifying functions on your graph, like addEdge(Node, Node), this does not work.

In Java, I tend to be very cautious about what I do and do not make mutable. Many of my classes only make their mutating methods accessibly to a limited set of users, as generally calling setSomething implies much more knowledge of the class than calling getSomething. Now you mention it, though, const would be useful in Java for things like collections, where you really want to return a collection object, but don't want to, as it would be mutable. Having said that, the modern collections library has an immutability wrapper built in.



Simon

If you disagree, post, don't moderate
[ Parent ]
And modifying system classes is useful, too... (4.00 / 1) (#126)
by hading on Fri Mar 09, 2001 at 10:25:13 AM EST

The ability to modify the built-in class library of a Smalltalk is pretty useful, too. Here's an example that came up recently for me. One should probably expect to find a Date class in Smalltalk, along with a method to count the days between two dates, e.g.

date1 countDaysTo: date2

I often need to be able to compute the number of weekdays between two dates. My particular Smalltalk environment has not built-in method for this. In some languages, to add it, you'd have to subclass the Date class to MyDate or something and add the desired method, which is rather awkward. In Smalltalk one can stick it right in the Date class, though, and do the natural thing of calling:

date1 countWeekdaysTo: date2

without any further ado, where date1 and date2 are still Dates and not some unnecessarily conjured subclasses. (On a tangent, my other favorite language has a different way out of this sort of dilemma. In Common Lisp, since methods are tied to generic functions rather than classes, one can simply define a generic function count-weekdays-to and specialize it to take date arguments, again the natural solution with this model of OOP.)

[ Parent ]

"modifiable references" (none / 0) (#48)
by kbob on Thu Mar 08, 2001 at 08:20:04 AM EST

vasi wrote:
11. No pointers in Java: Fine by me, as long as they have modifiable references. Speaking of which, why *doesn't* C++ have modifiable references?
C++ does have modifiable references. They're called pointers. (-:

K<bob>

[ Parent ]

C++ has modifiable references (none / 0) (#51)
by cezarg on Thu Mar 08, 2001 at 08:54:03 AM EST

They are called references :). There:

void bar(Foo& f)
{
//modify f
f->reset();
}

Or are you talking about something else and I'm completely out to lunch here?

[ Parent ]

Modifying the reference, not the referred value (4.00 / 1) (#79)
by bigdavex on Thu Mar 08, 2001 at 02:18:49 PM EST

I think they're talking about making a reference refer to different storage rather than changing the contents of the storage.

int foo = 1;
int bar = 2;
int& ref = foo;
. . .
ref = bar;

But IANACPPP, so I might be full of crap.

[ Parent ]

Yup, that's right (4.00 / 1) (#112)
by vasi on Fri Mar 09, 2001 at 02:17:44 AM EST

I want references that you can re-assign. Basically like pointers, just without all the problems pointers introduce:

- Pointer/array arithmetic problems. Running off the edge of an array shouldn't be possible. And something like this:
int i = 5; int *p = &i; i = *(int *)((int)p / 42);
should never have been made possible.

- Null pointers, which when they're dereferenced (usually) crash the program rather than at least throwing an exception.

- The weird syntax.

- The incredible difficulty of garbage collection when somebody can be storing something at a location which seems unreachable but is really known to the program as *(ptr + 365).

vasi

[ Parent ]

Weird Syntax? (none / 0) (#169)
by Rhamadanth on Wed Mar 14, 2001 at 03:53:35 AM EST

You like references in C++, and you're complaining about weird syntax?

Frankly, I think that C++ will continue to lose ground to Java as long as they maintain a ludicrously complex syntax. C, Objective-C, and to a lesser extent Java all have simplistic, minimal syntaxes.

I hate to admit it, but I'm a little bit of a lazy programmer. I know some people complain that C is too terse, but I think that the less rope you're given to hang yourself with, the better. Java's syntax is certainly more complicated than C's, but it's regular enough to not present problems. C++? I can't be bothered to keep track of it all. Templates, virtual functions, insane overloading, etc, etc.

People claim that C++ is better for large projects than C, but I don't buy it. Good design will conquer any problems you have with a large project. I happen to know that MDK2 was written entirely in ANSI C.

Given that you can really do anything in any language that you choose, why would I choose something like C++ if I didn't have to? Objective-C (while rarely used now) is a much clearer language, in my opinion. It's syntactic sugar. There's almost nothing to learn, and in five minutes, an experienced C programmer can be coding up classes with the best of them. Java is somewhat similar. And with judicious use of interfaces, I can mostly fake out the multiple inheritance that C++ followers seem to be so fond of.

In any case, my point is that you shouldn't be mentioning 'weird syntax' for pointers when you seem to be promoting such a massive mutant of a language. If you're gonna do something like that, at least pick something like APL or Ada or something. :)
-- The /bin/truth is out there.
[ Parent ]
OC (none / 0) (#183)
by use strict on Mon Mar 19, 2001 at 07:47:47 AM EST

As much as I hate to sound corny, objective c is the 'wave of the future', IMHO.

Objects are important nowadays, OC fills that, and (as you said) has the simple syntax of C. Although, I still can't get over the fact that OC still feels like Perl's OO implementation, which is decent, but far from satisfying anything OO pure.

To push this point further, your comment about MDK2 -- MDK2 (and as a MOF most/all of bioware's games) is not an outwardly extensible engine. Q3, HL, UT, Q2 (not quite sure here, but carmack is godlike and can do anything he wants anyways), etc, all use C++ and OO philosophy to accomplish the goals of 'true' modifications. Quake had QuakeC which filled the void extremely poorly, IMHO.

Inheritance is especially important in things like this.

[ Parent ]
Re: Cross Polination (none / 0) (#77)
by mikeyo on Thu Mar 08, 2001 at 01:36:51 PM EST

1. The speed thing: Well, ok, there's no way Java will be just as fast as C++ any time soon. Though it might be possible to compile Java to true machine-code (when needed), to get things done a bit faster.
Java actually can be compiled to true machine code [when needed], to get things done a bit faster, its call JIT == just in time compilation. For me at least, this hasn't been much of an issue. Most of the programs I have been writing were more database or bandwidth bound than processor bound.
3. Non-inlined funcs in Java: Why not? I don't always want to have to Javadoc everything to see just the definition of a class.
I would suggest createing an interface for every implementation, then the interface looks like the c++ header you are craving.
29. Javadoc and headers: I much prefer the Javadoc way.
so which is it?
17. Templates: A biggy. Java needs them; one more cast of an Object extracted from a Vector and I'll go nuts.
People have started on this with the <a href=http://www.cis.unisa.edu.au/~pizza/>Pizza and <a href=http://www.cis.unisa.edu.au/~pizza/gj/>GJ<a> projects. I don't know how far along they are though.
18. Garbage collection: I'd really really like it to be there; but only so I can turn it on and off.
Bjarne has always said that if garbage collection ever does make it into c++, it will be optional.

[ Parent ]
A few replies (none / 0) (#111)
by vasi on Fri Mar 09, 2001 at 02:07:55 AM EST

Java actually can be compiled to true machine code [when needed], to get things done a bit faster, its call JIT == just in time compilation.

Hey, now I know what "just in time compilers" are. Thanks :-)

3. Non-inlined funcs in Java...
29. Javadoc...

so which is it?

I wasn't making myself clear: I want the option to do either. I want to be able to create class definitions separately from the implementations (though a separate header file shouldn't be needed), or smush them together and have javadoc put it in order for me, depending on which I prefer or the situation I'm in. For example, when I'm writing a large, thousand lines or more, class I might want to refer to the definition quickly, without waiting to javadoc. When I'm writing something small, I won't have to and would rather not waste the space and time defining the class separately.

Bjarne has always said that if garbage collection ever does make it into c++, it will be optional.

When I said I wanted to be able to turn it on or off, I meant I wanted to do it very selectively. Not one project on, another off; more like one function or class at a time.

vasi

[ Parent ]

Re: Cross-pollination (5.00 / 1) (#80)
by mjg on Thu Mar 08, 2001 at 02:24:21 PM EST

4. Machine independent sizes: This one is a no-brainer. There's no harm in creating a standard "int32" type...is there?

Yes, efficiency. Almost all of the time, all you need is an int that is at least 32 bits rather than exactly 32 bits, unless you are doing something where you know you really need exactly 32 bits.

On an architecture that is 36 bits, for example, it's obviously more efficient to make the int 36 bits, rather than jumping through hoops to provide the programmer a 32 bit int when it usually doesn't matter.

[ Parent ]

point taken (none / 0) (#110)
by vasi on Fri Mar 09, 2001 at 01:57:02 AM EST

I never thought of that before, to be honest. If it'll make things more efficient, then I guess it'd make sense. I'll refine my suggestion: Let's have C(++) style "at least x bits" types, as well as types like int32 for when you need something exact.

Thanks!

vasi

[ Parent ]
Variable sized arrays (3.60 / 5) (#34)
by Eccles on Thu Mar 08, 2001 at 01:17:02 AM EST

In my view, the whole variable sized array thing is a bad idea. Why? Because stack overflows are so hard to catch.

In C++, if you need a variable length array, you do a new or use a vector. If the allocation fails, it either returns NULL or throws an exception, each of which can be handled.

A C99 variable-length array, however, if too large, overflows the stack. What happens then? Generally a core dump. Windows has structured exceptions for this, but if your stack is nearly overflowing from arrays on it, there's nothing you can do to clean it up.

Not much faith (1.66 / 3) (#36)
by pope nihil on Thu Mar 08, 2001 at 01:56:43 AM EST

I seriously doubt you'd be telling the designers of C99 anything they don't already know. There will obviously have to be failsafes built into it.


I voted.

[ Parent ]
Read the C99 standard on my site (4.50 / 2) (#39)
by Carnage4Life on Thu Mar 08, 2001 at 02:25:31 AM EST

I seriously doubt you'd be telling the designers of C99 anything they don't already know. There will obviously have to be failsafes built into it.

That does not sound like the C programming language I know. The one thing I have always hated about C and the way it is designed is that a lot of it depends on programmers being able to write excellent code. Insecure functions that enable people to smash the stack via overflows are littered all over ANSI C including strcpy, scanf, and gets with the expectation that good code won't smash the stack.

Expecting the standards committee to specify run-time error checking of stack space availability or some other failsafe is rather optimistic especially when this can be easily handled by the programmer (have a max size for variable length arrays in your programs). Also a cursory glance of the C99 standard does not seem to mention any such failsafes. Don't take my word for it, read it yourself.

Click here to read the C99 standard

[ Parent ]
not the C99 standard (none / 0) (#57)
by pfaffben on Thu Mar 08, 2001 at 10:24:41 AM EST

The document that you have linked to as "the C99 standard" is not the C99 standard at all. Instead, it's a draft from January 1999. It may not even be a legal copy, seeing as I never saw any permission to redistribute granted for the drafts.

To get the real standard, go to webstore.ansi.org. It's $18 for the PDF version.

[ Parent ]

Final Draft.... (none / 0) (#68)
by Carnage4Life on Thu Mar 08, 2001 at 12:00:02 PM EST

The document that you have linked to as "the C99 standard" is not the C99 standard at all.

It's the final draft of the standard or at least that's what Dr. Dobb's Journal said.

Instead, it's a draft from January 1999. It may not even be a legal copy, seeing as I never saw any permission to redistribute granted for the drafts.

The draft is available for download at the Danish UNIX System User Group website, either they are w4r3zing the drafts (and are being encouraged by Dr. Dobbs Journal) or it's OK to distribute the drafts.

Frankly I wasn't trying to explicitly mislead anyone or steal any money from ANSI, I was simply trying to point out that failsafes to handle runtime errors are not the kind of things that go into C programming language standards.


[ Parent ]
Politics of standardization (3.00 / 2) (#44)
by Simon Kinahan on Thu Mar 08, 2001 at 05:23:27 AM EST

I do not think it likely that any of the suggested facilities will get into the C++ standard. The different compiler vendors who have a say in the standardization process all already have libraries for these different facilities, and will spend their time bickering about which API to standardize on. The final result, if any, will either be bloated with features or watered down and useless. Microsoft, who probably sell more C++ compilers than all the others combined, will ignore the whole thing, since they have no interest at all in platform independence.

This is where Sun got it right with Java: they refused to let it go anywhere near a standards body until it was well established and useful. Thats not an excuse for their control-freakery, they could have been much more accomodating much earlier with licensing and source availability, but in itself lack of official standards was a big advantage.

Simon

If you disagree, post, don't moderate
I disagree (5.00 / 1) (#70)
by krlynch on Thu Mar 08, 2001 at 12:34:59 PM EST

Unsurprisingly, at least someone disagrees with you :-) I think that you are far too cynical in your outlook here: EVERY (and I do mean every!) vendor had their own string class, and vector class, etc. long before ISO C++ appeared. And those classes were added to the standard in such a way that almost no vendor supplied version was even close in functionality. I think it highly likely, especially if they are handed hte code for free with no restrictions (see, for example, www.boost.org, and www.oonumerics.org), and the user community says "give us the good stuff!", then the Standard will include it, and hte vendors will ship it. I consider it not only likely, but innevitable that most (but certainly not all) of these librarires will appear in the next version of the standard in one form or another

[ Parent ]

Garbage collection and concurrency (2.00 / 1) (#55)
by Haglund mdh on Thu Mar 08, 2001 at 09:32:41 AM EST

I like the idea of a new improved version of C++. For one thing, I like the ideas about concurrency and threads... but not that good with garbage collection IMHO.

Garbage Collection (3.00 / 1) (#75)
by mikeyo on Thu Mar 08, 2001 at 01:15:02 PM EST

Don't be worried about garbage collection. Bjarne has been talking about it for a long time, and he has always said that it would be optional. You wouldn't be forced to use it, but it would be available to you if you want to use it.

[ Parent ]
Could be done now... (none / 0) (#108)
by ucblockhead on Fri Mar 09, 2001 at 01:42:16 AM EST

You know, within the scope of the language, you could define a garbage collection system today. C++ lets you put all sorts of hooks into the allocation system. You can redefine new globally, or at the class level.

It wouldn't be all that hard to create a "garbage collected" class, or a "garbage collecting" template class and then do real garbage collecting. Stroustrup even said this in The Design and Evolution of C++. What I find interesting is that no one has felt the need to actually do it. You'd think if it were really a burning need, someone would have built a library to do it.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Garbage Collection (none / 0) (#161)
by Haglund mdh on Mon Mar 12, 2001 at 06:30:24 AM EST

Well, that sounds good to me, then. I think C++ would be improved with ome new features and stuff. It will be interesting to see this.

[ Parent ]
const (4.77 / 9) (#56)
by cezarg on Thu Mar 08, 2001 at 09:53:25 AM EST

Something most people tend to underappreciate in C++ is the const keyword that Java lacks. This is a serious limitation of java since it doesn't allow to define interfaces that make any guarantees about arguments passed to them. Constrast this with a C++ code:

class Circle
{
public:
void setBoundingRect(const Rect& rect);
const Rect& getBoundingRect() const;
};

Pretty simple stuff but it does wonders to the self documenting side of the code. Everyone who knows C++ knows that setBoundingRect will not modify rect and alsoe getBoundingRect will not modify the Circle object. Doing same thing with Java would require a hefty use of the clone function and some comments to clarify what is and isn't getting modified. Before you rush to point out yes, I'm aware of issues involved in shallow vs deep constness but the fact remains that what we have in C++ is better than no constness at all which is the case in Java.
Finally I noticed that Java programmers who don't have the C++ background don't notice the problem because they have never worked with const correct code. On the other hand C++ programmers who have been exposed to tightly const correct code find the lack of it a great limitation of Java.

Check the spec for the use of final keyword (2.00 / 2) (#148)
by Will Sargent on Sun Mar 11, 2001 at 01:56:29 AM EST

The final keyword can be used in arguments in the same way that const does. This helps you from accidentally scribbling over your references:

String mName;
public void setName(final String pName)
{
pName = mName;
}

will not compile, for example.
----
I'm pickle. I'm stealing your pregnant.
[ Parent ]
what about my classes? (none / 0) (#151)
by cezarg on Sun Mar 11, 2001 at 02:28:44 AM EST

What about the classes that I write? What you showed there is only half the story. The other half is const functions that I can declare in my classes and then when I pass const references/pointers to those objects I will only be able to invoke const functions on them. Hence a const correct application throughout makes it very easy to tell which methods modify the objects being passed and which don't. They even earned special names in the C++ world: non-const functions are called mutators and const functions are called inspectors. A fully const correct library is a very pleasing thing and interfaces are almost self documenting provided method names are chosen sensibly. As far as I know java does not have anything even similar to the concept of a const method. You'll welcome to correct me if I'm wrong though.

[ Parent ]
This has nothing to do with his example. (4.50 / 2) (#153)
by Carnage4Life on Sun Mar 11, 2001 at 04:20:10 AM EST

The final keyword can be used in arguments in the same way that const does. This helps you from accidentally scribbling over your references:

String mName;
public void setName(final String pName)
{
pName = mName;
}

will not compile, for example.


This is the third or fourth time a Java coder on K5 has misunderstood the difference between const and final. With const in C++, one can specifiy that an object cannot be modified by a function if it was passed in as a parameter or that a method should not modify the state of the object it operates on.

All your example does is stop the local variable pName from being reassigned which is usually useless since there are very few times (actually none that I've ever seen) when one wants to reassign a variable that was passed in as a parameter. Note that even if the variable was not final, reassigning it does nothing to the original object reference since pName is simply a copy of the original reference (pass by value semantics). In your Java example pName.modifyState() would work but in C++ if pName was const, it would not. That is a significant difference.


[ Parent ]
why I don't like C++ (2.55 / 9) (#61)
by fantastic-cat on Thu Mar 08, 2001 at 11:10:27 AM EST

OK this is a bit of a moan, basically a list of things I hated about C++ when I was learning it and things I think should be improved before people go crazy adding new libraries and stuff (I use it quite a lot and don't really have language preferences, right tool for the job type thing)

Also I think the Java vs C++ comparison is unhelpfull as aside from both being OO languages derived from the same syntactic roots typically implementations of each language aim for totally different things

anyway here's my moan:

Efficiency
There are efficiency problems with writing proper OO code as when creating small classes. All (to my knowledge) C++ compilers implement classes as structures and structures are objects which compilers find hard to hold in memory so loads of memory acceses operations get in the way. To make things worse, when the compiler is generating all these temporary objects on the stack, it doesn't register colour the stack, so the function's stack frame gets big.

Type unsafeness
C++ is described as a type safe language, yet it has implicit type conversion. These two things are oxymoronical. Whilst C++ couldn't prevent the type conversions which C contains, it could have prevented the implicit application of user defined type conversions.

This rule really bites when you declare a tree like heirarchy of classes. If each child has a constructor taking a parental type object, then any function taking one kind of child will take any other kind of child due to the implicit conversion.

Overloaded operator semantics
Overloaded operator functions do not have to obey even the rudimentary semantics of the original C operators. There's nothing to stop me defining operators such that 'a + b' modifies the values of 'a' or 'b'. Or that 'a + b = c' is meaningful. And where exactly are the sequence points in 'a && b'? It depends on the types of 'a' and 'b' and whether an overloaded '&&' operator has been defined for them (duh!).

Overloaded Modify Operators If you overload the '=' operator and the '+' operator, the compiler doesn't deduce the semantics of a '+=' operator, should you not have declared one. (Actually this is probably a hard thing to do, but hey I'm whinging anyway so there!)

reference types
The reference type is not needed. It is used in three situations, all of which are either bad or can be solved in better ways.

  • The copy constructor
  • Passing arguments by reference
  • Allowing functions to return lvalues

If anyone is interested I can tell you what I think about these at great length

Function-like Cast Syntax
What's the point of this? C already has a perfectly useful cast syntax. The function like syntax only works for types which are a single word. Is 'randomname(value)' a type conversion or not? With the C cast syntax, I can tell that it's doing a conversion. What if I mistype 'randomname'? If I used the C syntax for type conversion, I'd only avoid an error if I hit a different typename. With the functionlike syntax I avoid an error if I hit either a different type name or a valid function name.

OK so there is a reason for this but it all adds to general gramamr ambiguity which is clearly a bad thing

Constructor Member Initializer Lists
Between the type declaration of a constructor and the constructor body you can give a comma separated list of member constructions, introduced by a ':'. This is just ugly. Why is the list introduced by a colon, and yet comma separated? Why not colon separate the list too -- that might at least look better, and be easier to edit.

But the real problem is that you're restricted about the sort of expressions you can initialize the members with -- and this restriction percolates back to users of the constructor about whether it can construct a constant object.

Why can't I construct the member objects explicitly within the body of the constructor. Using a pointer to an object in a function-like context might be a good way of indicating construction into specified storage. The compiler can quite easily see whether you've not constructed all members within the body, and prepend the appropriate default constructors.

Inconsistant Function Declaration
The forms for constructor, destructor and conversion operator are exceptions to the normal function declaration rules. None of these have a return type specified (and should therefore default to 'int' by convention), however the constructor returns an object of the type being constructed, the destructor is a void function and the conversion returns an object of the target type. Presumably these exceptions were introduced to reduce typing, but why then prohibit the verbose forms?

Static Member Functions Are Not What You Think
The keywords 'static' and 'extern' have useful and consistent meanings in C. But for a member function, 'static' has a completely different meaning. It means the function is not object specific. How confusing. Why not allow qualifying the object 'void' just as you can qualify it 'const' or 'volatile' after the parameter list?

Inline is Not a Hint
The 'inline' keyword is always described as a hint to get the compiler to inline the function. But it does more than this, it changes the default linkage to 'static' rather than 'extern'.

The semantics of an 'inline extern' function are pretty useless. Every module which compiles the function will emit a body, if it can't inline it. Thus the linker gets multiple definitions of the same object. I think 'inline extern' should mean to attempt inlining, but if it fails don't emit a function body. That way a library can usefully export such functions, it would provide the single definition of the function required by the linker.

Member Functions Which Return the Object
If a member function returns '*this', there's no way to tell the compiler this in its prototype. Thus the compiler has to make a temporary object, which will be filled with a constructed copy of the object and then destroyed later. Where as the object is also available to the caller.

Compilers Disagree About Argument Conversion Costs
It seems no two compilers agree about the cost of promoting arguments from caller type to callee type. This is probably an artefact of the draft standard moving faster than the implementations.

The SGI CC compiler didn't think it could promote a non-const object to a const object for a const qualified member function. Microsoft VC++ thought that the cost of promoting an 'int' to an '__int64' (their 'long long') was the same as using a user conversion (although the standard does not specify a 'long long' type, costing its use the same as user conversions is stupid).

Perversion of Virtual Functions
I've never had a need to use virtual functions in C++ but I've seen books which advocate things like this :

  • Create a class of flying things.
  • Add an airplane instance.
  • Add a helicopter instance.
  • Now at runtime, we can add in a flying insect!
  • HUH?
OK I admit I don't really understand virtual functions can someone please explain them to me

virtual functions (3.66 / 6) (#65)
by _Quinn on Thu Mar 08, 2001 at 11:43:14 AM EST

   If I hand you off an object of class Foo, and you execute bar() on it, which bar() gets run? If the function is not virtual, Foo:bar() is run, no matter what the actuall type of the object is. If bar() were virtual, I could hand you off a subclass of Foo which overrode bar() and that subclass's foo() would execute. Virtual functions are necessary to implement the interface paradigm.

-_Quinn
Reality Maintenance Group, Silver City Construction Co., Ltd.
[ Parent ]
Efficiency (4.60 / 5) (#69)
by ucblockhead on Thu Mar 08, 2001 at 12:19:16 PM EST

There are efficiency problems with writing proper OO code as when creating small classes. All (to my knowledge) C++ compilers implement classes as structures and structures are objects which compilers find hard to hold in memory so loads of memory acceses operations get in the way. To make things worse, when the compiler is generating all these temporary objects on the stack, it doesn't register colour the stack, so the function's stack frame gets big.

I'm not sure I'm understanding you here. In terms of memory usage, it is hard to beat C++ in terms of efficiency. And by avoiding new, it is pretty easy to avoid lots of little heap allocations without avoiding small objects.

In terms of the stack, it is pretty damn efficient as the only thing on the stack is the actual data that belongs to the function and a pointer to the vtable if the class has virtual members.

C++ is described as a type safe language, yet it has implicit type conversion. These two things are oxymoronical. Whilst C++ couldn't prevent the type conversions which C contains, it could have prevented the implicit application of user defined type conversions.

It is fairly trivial to prevent implicit conversion of your objects if you don't want them to be implicitely converted. Really, you have to go out of your way to get your objects to implicitly convert, either with copy constructors or cast operators.

The forms for constructor, destructor and conversion operator are exceptions to the normal function declaration rules. None of these have a return type specified (and should therefore default to 'int' by convention),

This is not true. Constructors and destructors do not return 'int'. They do not return anything because they are never called directly, so a return value has no meaning.

If a member function returns '*this', there's no way to tell the compiler this in its prototype. Thus the compiler has to make a temporary object, which will be filled with a constructed copy of the object and then destroyed later. Where as the object is also available to the caller.
What you want is:

class Foobar
{
public:
  Foobar& GetIt() { return *this; }
};

If your return type is a reference, no temporary is created.


-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Efficiency (4.00 / 2) (#78)
by inpHilltr8r on Thu Mar 08, 2001 at 02:06:45 PM EST

There are efficiency problems with writing proper OO code as when creating small classes. All (to my knowledge) C++ compilers implement classes as structures and structures are objects which compilers find hard to hold in memory so loads of memory acceses operations get in the way.

Actually, if the structure fits in a register, and has been automatically allocated, compilers are usually happy to stuff them in a register.

We use gcc for the EE, which has registers that can fit a 4*float vector, and a vector class that fits in one of those registers, and very nice it is too.

For example:

VUVec4 QuaternionMultiply(VUVec4 a,VUVec4 b)
{
VUVec4 r = (b*a.W()) + (a*b.W()) + Cross(a,b);
r.SetW((a.W()*b.W()) - Dot3(a,b));
return r;
}

(Where VUVec4 is a class that encapsulates a four element floating point vector of the form x,y,z,w) Doesn't touch memory at all.

[ Parent ]

You seem unfamiliar with the language. (5.00 / 4) (#96)
by Sax Maniac on Thu Mar 08, 2001 at 08:04:23 PM EST

There are efficiency problems with writing proper OO code as when creating small classes.

Use the Pimple idiom, or the Flyweight Pattern. Problem solved.

C++ is described as a type safe language, yet it has implicit type conversion. These two things are oxymoronical. Whilst C++ couldn't prevent the type conversions which C contains, it could have prevented the implicit application of user defined type conversions.

Type conversions that do not lose information are legal and implicit. You would go nuts without them. Do you really want to cast a int to a double just so you can add them together? I don't think so.

This rule really bites when you declare a tree like heirarchy of classes. If each child has a constructor taking a parental type object, then any function taking one kind of child will take any other kind of child due to the implicit conversion.

If you don't want implicit conversion, learn and love the explicit keyword, and stay away from gratuitous constructors. You can use the Named Constructor idiom to help with this.

If you don't want implicit conversion between base classes, don't overuse public inhertiance (one of the most common C++ design errors). Learn composition, or in a bind, private inhertiance.

Overloaded operator functions do not have to obey even the rudimentary semantics of the original C operators. There's nothing to stop me defining operators such that 'a + b' modifies the values of 'a' or 'b'. Or that 'a + b = c' is meaningful. And where exactly are the sequence points in 'a && b'? It depends on the types of 'a' and 'b' and whether an overloaded '&&' operator has been defined for them (duh!).

You bring up a good point here, but there really is no way that the compiler could generically guarantee commutativity for any "+" operator. The tradeoff is worth it for things like complex numbers or vectors. Using operator overloading for anything else is bad, bad, style.

Overloaded Modify Operators If you overload the '=' operator and the '+' operator, the compiler doesn't deduce the semantics of a '+=' operator, should you not have declared one. (Actually this is probably a hard thing to do, but hey I'm whinging anyway so there!)

Again, that's impossible as guaranteeing the semantics of + are preserved.

The reference type is not needed. It is used in three situations, all of which are either bad or can be solved in better ways.

The copy constructor
Passing arguments by reference
Allowing functions to return lvalues

You've apparently never used polymorphism before. Reference types are critical for using polymorphic types. Since you admit you don't know what a virtual function is, I won't continue.

What's the point of this? C already has a perfectly useful cast syntax. The function like syntax only works for types which are a single word. Is 'randomname(value)' a type conversion or not? With the C cast syntax, I can tell that it's doing a conversion. What if I mistype 'randomname'? If I used the C syntax for type conversion, I'd only avoid an error if I hit a different typename. With the functionlike syntax I avoid an error if I hit either a different type name or a valid function name.

The point of this is to hit home that type conversion is construction.

But the real problem is that you're restricted about the sort of expressions you can initialize the members with -- and this restriction percolates back to users of the constructor about whether it can construct a constant object.

Completely untrue- you write a static function that return the value that you need initialized. Then your initialization function can be as complicated as need be.

Why can't I construct the member objects explicitly within the body of the constructor.

You really shouldn't worry about this, otherwise you're doing evil premature optimization. There is nothing that prevents a compiler doing in-place construction as an optimization if it can figure out how to do so. I have a compiler that regularly does this, and it's nice not to have to think about.

The forms for constructor, destructor and conversion operator are exceptions to the normal function declaration rules. None of these have a return type specified (and should therefore default to 'int' by convention), however the constructor returns an object of the type being constructed, the destructor is a void function and the conversion returns an object of the target type. Presumably these exceptions were introduced to reduce typing, but why then prohibit the verbose forms?

Because redundant information is information that can be wrong. If I had to write all ctors like this:

Type Type::Type() { ... }
Then that's one more thing to get out of sync. "Wait", you might say, "but Type::Type is redundant too". No, it isn't, you can write it this way:

class Type
{
Type() { ... }
}
But then you lose the benefit of separating the interface from the implemetnation, which is a real big deal in large systems. When used judiciously, it's a major win for compile time, efficiency, and decoupling.

The keywords 'static' and 'extern' have useful and consistent meanings in C.

Sorry, I couldn't help but laughing out loud here. static is already inconsistent in C:

1. At file scope, it means prevent external linkage to the variable or function in question.

2. In block scope, it means the value persists across function invocations, and is only initialized once.

But for a member function, 'static' has a completely different meaning. It means the function is not object specific. How confusing. Why not allow qualifying the object 'void' just as you can qualify it 'const' or 'volatile' after the parameter list?

I agree it's further overloading an overloaded work. However, overloading void would be just as bad! So, how do I write a class function then? Are you seriously suggesting this:


class Foo
{
void void aClassFunction(int) { ... }
}

...which would add more wackiness to the grammar. Please.

If a member function returns '*this', there's no way to tell the compiler this in its prototype. Thus the compiler has to make a temporary object, which will be filled with a constructed copy of the object and then destroyed later. Where as the object is also available to the caller.

This is proof why references are NOT useless.

It seems no two compilers agree about the cost of promoting arguments from caller type to callee type. This is probably an artefact of the draft standard moving faster than the implementations. The SGI CC compiler didn't think it could promote a non-const object to a const object for a const qualified member function. Microsoft VC++ thought that the cost of promoting an 'int' to an '__int64' (their 'long long') was the same as using a user conversion (although the standard does not specify a 'long long' type, costing its use the same as user conversions is stupid).

Microsoft, and compiler vendors, are otorious for shipping their compilers with non-standard extensions turned on. This is a marketing issue, as an attempt of producy differentiation and branding. However, if you use or rely on them, you get killed when Visual Foo Compiler 5.432 SP43 because passe.

OK I admit I don't really understand virtual functions can someone please explain them to me

If you haven't gotten this far, you've learned about 1/10 of the C++ language. You might want to take a class on OO theory in order to see what it's all about. But now, it looks like you're whining about things you don't understand.


Stop screwing around with printf and gdb and get a debugger that doesn't suck.
[ Parent ]

1/10? (none / 0) (#172)
by Rhamadanth on Wed Mar 14, 2001 at 04:28:14 AM EST

See? That's the problem right there. The original poster already knows C, but you get him into C++, and he only knows 1/10th of the language? That's *ridiculous*. C is the basis language. How the hell could you kludge on 10 times the original size of C, and tout the result as an efficient solution to anything?

Programmers don't want to spend time *learning* languages. The want to spend time *programming* languages. I'm convinced that is a large reason for C's popularity. (Don't try and bring ASM into this. While the grammar may be small, there's a lot more to know than the names of the instructions. In fact, that's the whole reason why we use higher level languages at all. But I'm explaining things to people that already understand. I hope. :)
-- The /bin/truth is out there.
[ Parent ]
1/10 (none / 0) (#187)
by Sax Maniac on Sat Mar 24, 2001 at 10:51:15 PM EST

Excuse me, but the original article, and the poster's rant was about C++, not C. C has nothing to do with this issue.

Lest you think I'm a C++ bigot, I regularly program in C and C++. Both are different tools suited to different jobs. The point is that C or C++ by itself is not inherently flawed; they have different levels of appropriateness to certain problems.

How the hell could you kludge on 10 times the original size of C, and tout the result as an efficient solution to anything?

There are a huge number applications in the world that are written in C++. Apparently, the language designers and a huge part of the software development community are on to something that escapes you. People would not use it were it not useful.

Your post smells like you are a C programmer who was forced to learn C++, and resent it.


Stop screwing around with printf and gdb and get a debugger that doesn't suck.
[ Parent ]

Virtual functions (4.25 / 4) (#98)
by kaatunut on Thu Mar 08, 2001 at 08:46:14 PM EST

#include <stdio.h>

class Monster {
   virtual void Speak() = 0;
};

class GreenMan : public Monster {
   virtual void Speak() { printf("green man\n"); }
};

class RedEyedBeast : public Monster {
   virtual void Speak() { printf("red-eyed beast\n"); }
};

int main() {
   Monster* monster[3];
   int k;

   monster[0]=new GreenMan;
   monster[1]=new RedEyedBeast;
   monster[2]=new GreenMan;
   for (k=0;k<3;++k) monster[k]->Speak();
}

--

To me the above example would have explained what's the deal.

-Kaatunut

--
there's hole up in the sky from where the angels fall to sire children that grow up too tall, there's hole down in the ground where all the dead men go down purgatory's highways that gun their souls
[ Parent ]

why I don't like guys who don like C++ ;) (none / 0) (#167)
by transcend on Tue Mar 13, 2001 at 03:27:16 PM EST

Efficiency
...C++ compilers implement classes as structures and structures are objects which compilers find hard to hold in memory...

How structures are harder to hold especialy on stack than something else? I thought it just increasing stack pointer by size of structure, array or whatever else.

Type unsafeness
C++ is described as a type safe language, yet it has implicit type conversion

Implicit type conversion? You mean, when there is constructor with single parameter presented? This is good thing makes code look better usualy, but if you don't like it, there is good news for you: keyword 'explicit'.

Overloaded operator semantics
There's nothing to stop me defining operators such that 'a + b' modifies the values of 'a' or 'b'

There is nothing to stop you from shooting yourself in foot. Don't blame others if that blows your leg. (Stroustrup said something like that)

reference types
The reference type is not needed

References prevents from checking whthere some function returned NULL, if it not supposed to. It seems there is far to few programmers that know such thing as exceptions for errors and prefer to return NULL, but forgets to check wheter function succeded.

Function-like Cast Syntax
What's the point of this?

Readability. static_cast is easier to notice that some random type name.

Constructor Member Initializer ListsThis is just ugly
This is just normal rules of punctuation. From webster: colon(n) - 2: a punctuation mark : used chiefly to direct attention to matter (as a list, explanation, or quotation) that follows

Inline is Not a Hint
You make compiler hint: I won't need that function, just place code instead. Then you complain: where is my function?! Why would you want to give a hint, and then do an opposite. This mean you are liar. Compilers do not like liars.

Member Functions Which Return the Object
If a member function returns '*this', there's no way to tell the compiler this in its prototype

Use reference. See, they are usefull.

Perversion of Virtual Functions
I've never had a need to use virtual functions in C++

Go code real life large scale project. Or learn OOP.

[ Parent ]

So why not just fix java (3.00 / 4) (#62)
by Bob Abooey on Thu Mar 08, 2001 at 11:32:12 AM EST

It seems to me that the simple approach here is to fix java. This made me think of that old commercial for BMW's, they showed some car dealer who kept saying that his car "Can do this just like a BMW..." the point being, just buy a BMW and get the real thing.

I'm not going to point out all of the flaws of c++, many here have already done so. I am going to point out the flaw in the industry that says we need to have 30 different programming languages instead of 3 or 4 great ones. So we waste hour upon hour of talking about how c++ is too slow or java doesn't support c style pointers, etc... and now we are going to try to build java type functionality into c++... great.... why? Sometimes it seems that the IT industry is the most fragmented and totally screwed up industry on earth, we never let any technology mature, we always hop on the latest hype, we expect our IT workers to retrain themselves every 6 months for the latest thing... it's nonsense.

Look at the real engineers of the world, the people who build bridges and buildings for a living... maybe we should take a lesson from them, they have tried and true technology that they use and it doesn't change every 3 months just because it can... then again, maybe that's why bridges actually work and last for years.


-------
Comments on politics from a man whose life seems to revolve around his lunch menu just do not hold weight. - Casioitan
because java is a commercial package (none / 0) (#64)
by cezarg on Thu Mar 08, 2001 at 11:43:08 AM EST

Some of us (myself included) don't find it very comforting that java is controlled by a single organization regardless of how prudent that company appears to be. I'd much rather use a language that is standardised so that different vendors can and do provide implementations. Similar sort of reasoning to that of the open source/Free software advocates.

[ Parent ]
Java has an available specification; C++ does not. (none / 0) (#186)
by wsharlan on Wed Mar 21, 2001 at 02:03:59 PM EST

Java does have a clear specification (unlike say Visual Basic or Perl). You can get the spec from the Sun website. IBM, SGI, and others have independent implementations. You can use Java without using a single byte of code from Sun.

I would rather have Sun's "community process" control the specification than ANSI/ISO. The latter does not allow me to download a specification of C++ from the internet (only obsolete draft copies). I can't buy the C++ spec in a bookstore. No, I must send them a check for a dead-tree version by post. Anyway, by the time the spec was actually finalized, I would have moved on to another language.

If there is a good way to standardize a language, I haven't seen it yet.


(Ignore a celebrity today.)
[ Parent ]

Computer Industry Woes (5.00 / 1) (#88)
by felscher on Thu Mar 08, 2001 at 05:08:28 PM EST

Actually, If you were to investigate the engineering industry, you would find that it indeed does change every few months. New building compounds, and tools are created pretty often.

For the most part, you have to use the language that does what you need. I'm not going to use C++ to build a simple website, just like I'm not going to use Cold Fusion to handle my accounting system.

Java and C++ are major competitors right now. Eventually though, something will come along to replace both of them.

Besides, we should all celebrate the diversity of the industry,new languages, new tools. I know I wouldn't want to use C++ for the rest of my career. I love getting to try something different every 3 months.

Kris
People say that intellectualism is dead in this country. There's only one response to that...duh
[ Parent ]

One true language? (4.00 / 1) (#95)
by mvw on Thu Mar 08, 2001 at 07:55:36 PM EST

C++ is the result of a lot of design decisions. All of them explained in great detail in The Design and Evolution of C++ by the way.

One of the main principles was, that C++ should be downwards compatible to C to large degree, keeping the unique value of C as a language both suited for low level and high level programming, plus adding new concepts for getting huge programs written, that way it started as C with classes.

So I really fail to see any other successful approach of extending C in that direction. Objective C was not, and Java certainly is no real C language anymore, having abandoned pointers. Now for the fun part a Knuth citation from 1974:

But I think it's an amusing coincidence that the present programming revolution is being led by another Dutchman (although he doesn't have extremist views corresponding to Brouwer's); and I do consider assignment statements and pointer variables to be among computer science's "most valuable treasures!'.

No this was not Guido van Rossum of Python, it was Edsgar Dijkstra, the GOTO banisher :-) The rest is interesting as well:

At the present time I think we are on the verge of discovering at last what programming languages should really be like. I look forward to seeing many responsible experi- ments with language design during the next few years; and my dream is that by 1984 we will see a consensus developing for a really good programming language (or, more likely, a coherent family of languages). Further- more, I'm guessing that people will become so disenchanted with the languages they are now using--even COBOL and FORTRAN-- that this new language, UTOPXA 84, will have a chance to take over.

So much about ever reappearing debates..


Regards, Marc
[ Parent ]

They've been around a lot longer (5.00 / 2) (#102)
by partingshot on Thu Mar 08, 2001 at 11:09:59 PM EST

> Look at the real engineers of the world

You mean the ones that have practiced for
~3000 years?

Software is very young. You can't expect
it to be like civil engineering overnight.


> they have tried and true technology

My girlfriend is a civil engineer.
Yes they do have 'tried & true'.
You would expect that after thousands of
years. However, she is always talking about
some new technology. They do evolve too.

It would get pretty boring otherwise.

[ Parent ]
SL additions will not make C++ more popular. (4.40 / 5) (#66)
by your_desired_username on Thu Mar 08, 2001 at 11:55:45 AM EST

Let us suppose that programmers want a pure object-oriented language, which is both elegant and flexible, simple yet powerful, and, most importantly, has an extensive standard library that meets those needs which are shared by most programs. What languages fulfill this want better than Java?

Eiffel
Smalltalk
Modula-3
Oberon

Stop. There are plenty of others, but those are enough to make to my point. (C++ is not there because it does not believe that object-oriented purity is necessarily good, nor does pretend that simple languages are good. Its goals are entirely different.) Now, how many applications, libraries, middleware, toys, etc, can you name that were written in one of the above languages? If you are a supporter of one those languages, you can probably list a dozen - which no-one else has ever heard of. The defenders of each of those useful and interesting languages will curse me to burn eternally in a lake of fire for saying this, but the most popular of the languages I listed are niche languages, and the rest are academic curiosities.

Why is Java so much more widely used? Advertising. Sun has spent, and continues to spend, hundreds of millions of dollars advertising Java. Everyone, even bigwigs who have no clue what a programming language is, has heard of Java, and has been told how c00l it is, and how well it can slice bread, take out the trash, etc. It has 'mindshare'.

What does this have to do with a feature wish list for C++200[56789]? Many C++ advocates, Carnage4Life included, seem to think that right features will make C++ more popular than Java. I think history has proven them wrong. Many of the features Carnage4Life mentions will make C++ a better language - but I will be surprised if any of them raise C++ above the popularity of Java. IMO, there is only one feature that has ever made a big difference in a language's popularity - and that is compatibility with an already popular language, which C++ already has.

This not to say that I think Java is more worthy than C++ (my feelings tend in the opposite direction, though I think there is little overlap in the core competencies of the 2 languages), nor does it mean that members of the C++ community should abandon the notion of improving and expanding C++'s standard libraries. Just don't expect that adding such things as threads, gui, and gc to the SL will make C++ 'beat' Java.

(btw, I could have written a rant about how language wars are bad, and C++ and Java actually serve very different needs, and should therefor co-exist... but the sad fact is that the languages I listed above are unpopular in part due to the popularity of C - even though they filled needs that C did not.)

The point of Java (4.80 / 5) (#76)
by slaytanic killer on Thu Mar 08, 2001 at 01:30:26 PM EST

Why is it that Java has turned out to be a successful language? Is it really just marketing? Here is a small list of what Java programmers see in it:

. Documentation. Copious, free. Not only of the core APIs, but Sun also provides Javadoc, a sort of lightweight Literate Programming method which allows you to create pretty HTML documentation from your sourcecode. In a crunch, just stop by O'Reilly.

. Design patterns. Java is clearly not designed to give a lot of design/implementation tools (other than libraries) to the experienced programmer, but to improve the quality of the average programmer's code. Why do people like Windows/Macs? Because you don't get confused by all the options a Unix machine affords you. The design is regular; you can point to the Java API sourcecode and say, "This is an Adapter pattern. This is an Observer pattern. This is a Memento pattern." You're forced to code properly, unlike C++.

. APIs that serve as a Swiss Army knife. Do you want to program server-side programs? Sure, there's servlets. Client-side? Swing. Components? Beans. Thin-client delivery? Applets. Fast, platform-specific code? JNI. If there's something missing, you can likely code it on your own, and at some point it might get a standard API & delivery implementation of its own.

. Cross-platform stability. Overrated? No. Most programmers are average. That means they don't want to search for the package x that works best on platform y. What does this mean? Programming can be an average activity. One can find art in it if they want, perhaps create beautiful objects, but the end result in many cases is to make something work. By defining a VM, the environment can be controlled to make coding less unpredictable. Costs decrease because heterogenous environments can be tamed.

. Lock-in. The reason AOL does so well is because the value of a network is the square of its nodes. MSN can't break in so easily because they have a hard time offering what people can get from a larger army of users. Same with Java. It looks like C, so more developers can use it. It has a huge amount of easy-to-find forums and sourcecode. The marketing is to inflate this amount in peoples' eyes, with enough substance along with the cardboard props to suffice.

Do I think Java is impressive in all ways? Far from it. Other languages I like more for their particular advantages. And the Java language itself is mediocre. Just a delivery vehicle. But it ain't all hype; in Java's case, hype exaggerates real substance.

[ Parent ]
Too bad not only PHBs fall for Java.. (4.33 / 3) (#92)
by mvw on Thu Mar 08, 2001 at 06:48:34 PM EST

Why is Java so much more widely used? Advertising. Sun has spent, and continues to spend, hundreds of millions of dollars advertising Java. Everyone, even bigwigs who have no clue what a programming language is, has heard of Java, and has been told how c00l it is, and how well it can slice bread, take out the trash, etc. It has 'mindshare'.

Unfortunately it is not only clueless managers who fall for Java. My concerns regarding Java are

  1. loss of efficiency
  2. loss of control
of course assembler would be a better choice in this regards, but I consider C as the best abstract assembler and C++ as the best present enhancement of C in terms of support for writing large programms without sacrificing those qualities.

So I was deeply shocked, when a colleague, a former Forth wizard and commercial game developer, turned out to favour Java instead of C++ for a new GUI application. This yielded a patt, and the manager's vote in favour of Java ("hey Java is known to allow for faster development than C++") gave the decision for Java. Argh.

The other crazy argument was that Moore's law has leveraged computers to be fast enough for Java. This might be ok for an web applet, but not for an application that might need shovel a lot of data around and probably needs advanced computational graphics routines for displaying certain information. All those valuable cycles burned for nothing.

At least I have encountered the first quality application written in Java that does not suck, JBuilder 4 is a really nice application (on 700MHz Athlon :-)

On the other hand I recommend to read Structured Programming with go to Statements, an article by Donald E. Knuth from 1974, where he fears that the radical ban of GOTO statements in the then upcoming Algol/Pascal like languages will result in wasted efficiency - perhaps we will indeed laugh about some of our present fears in a decade or two. :)
Regards, Marc
[ Parent ]

whooaaa! not so fast there. (2.33 / 3) (#101)
by partingshot on Thu Mar 08, 2001 at 11:04:17 PM EST

> Why is Java so much more widely used

where did you here that? All of the
advertisements seem to indicate that it is,
but I don't think so. Do a search on "most
popular programming language".

All of the news that I can find indicate that
C/C++ continue to be the most popular languages
for implementing new projects.

COBOL still wins though for kloc/day!

I also just read that there are more C++ jobs
advertised than for any other language.
Java is a lot of hype. It's good for network
programming, but I don't ever see an interpreted
language replacing a compiled one for serious
development.

[ Parent ]
Interpreted? (2.00 / 1) (#105)
by kubalaa on Thu Mar 08, 2001 at 11:50:32 PM EST

Java's not, you know. It's compiled, just not for a physical processor. Come to think of it I can't think of any popular interpreted languages; even perl and PHP squeeze in an invisible compilation step.

[ Parent ]
Machine code is interpreted... (none / 0) (#120)
by your_desired_username on Fri Mar 09, 2001 at 04:38:50 AM EST

by a processor.

There is no clear dividing line between compiliation and interpretation. Code can be translated (a) before it is delieverd. (b) when it is loaded by the OS. (c) when the function to translated is first entered... etc, etc. These are all implementation choices; there are lisp and java implementations that compile directly to machine code, there are C interpreters.

[ Parent ]
true.... (slightly OT) (none / 0) (#182)
by use strict on Mon Mar 19, 2001 at 07:18:18 AM EST

but if I would have to go for a definition of compilation in regards to langauges, I would have to say that would be breaking it down to a machine readable form. (note 'readable', not 'interpreted')

Java's bytecode is run by a JRE, and while I know very little of the language, IIRC there is no way to manipulate the existing code in that form. I may be wrong, and apologize if I am.

It's this foundation that really seperates 'compiled' from 'interpreted', IMHO.

ie, perl (of course :), certain versions of BASIC, CL, etc, all have methods to modify or alter existing code during runtime. A good reason that most of these languages are found useful today (mainly WRT CL and BASIC), is the fact that this is possible, especially WRT perl being used for anything but text processing and/or hack value.

Of course you can write self-modifying code in any language, but that's not a true language facility.

Java is more than just a new language, which is one of the major reasons that I think it's become so intriguing. The concepts of bytecode, true virtual 'machines' and 'write once, run anywhere' used to only exist in makefiles and IL's like LISP. Intrigue in geeks leads to experimentation.... Most of you know the 'hacker ethic' so I'm not going to get all ESR on you guys here.

<random direction>
I really think that .NET will change that though, and level the 'bytecode' field in a lot of ways that I would wish more of us would spend time reading about. .NET is truly a good thing, if portability is insured. (which is my only concern, really)
</random>

Basically, the point is, is that Java is a new toy. Everyone played with a hammer as a kid, even if they didn't know what it was good for. For more examples, check out some of the stuff on CPAN that is being released (and people are being paid for it!). We all wrote 'hello world', and the big deal now is that the corporations are advertising languages and so the people who aren't playing with the toys are becoming interested in them in a slightly voyeuristic sense...

You can see this at any ISP or dev shop with a non-clued boss. He's not familiar with Bay Networks, but he sure as hell knows who 3COM and CISC are. He wants to see these powering his network, even though the baystack might be a better choice.

And programmers are unable to say no. This, I think, is coded into our brains in the zygote phase. We can say "it might be a long time", but never no. No, it is impossible.

Sysadmins on the other hand.... :)


[ Parent ]
I am guessing 70% of C/C++ users use no C++ (3.50 / 2) (#118)
by your_desired_username on Fri Mar 09, 2001 at 04:19:17 AM EST

Every survey I have seen lumps C and C++ users together in one ball.. C/C++ users. I think most of them use C, and little or no C++.

As for 'more C++ jobs' ... that was a year ago. In Salt Lake City, there are more ads for java jobs than all other languages combined. About 1/2 of the tech jobs advertised in SLC are actually located in silicon valley.

In the last 3 months, the company I work for has hired 6 programmers using ads for C++ programmers. Guess what. All of us are programming in C.

[ Parent ]
Compiler quality? (none / 0) (#71)
by lunarn on Thu Mar 08, 2001 at 12:41:37 PM EST

Thank you for posting another interesting article Carnage4Life. Reading this discussion reminded me of a few C++ details I have not used in a while, maybe I should read Meyers book again.


Obviously 2005 is still some way off, so my immediate concern is how well the different compilers and standard library implementations complies with the current standard. I have come to understand that this was/has been a problem for some time. Would anyone care to comment (or point me in the direction of information) on the current state of C++ compilers/libraries.

Thank You
Arnar

Document code? Why do you think they call it "code?"
C++ extension proposals strangely familiar. (4.00 / 1) (#90)
by bertok on Thu Mar 08, 2001 at 06:08:03 PM EST

I've got my hands on the Visual Studio.NET C++ IDE beta, and Microsoft's "Managed Extensions to C++" has many of the features people have been requesting, including:
  • Pure Interfaces
  • Garbage Collection
  • The finally keyword
  • Serialization
  • A Java-like standard library
  • A single executable will run on multiple CPU architectures. (But only under Windows)
  • Binary imports for faster compiles.
  • Standardized RPC. (DCOM)



--
"If you would be a real seeker after truth, it is necessary that at least
once in your life you doubt, as far as possible, all things."

C++ Standard GUI Lib (4.00 / 3) (#91)
by mvw on Thu Mar 08, 2001 at 06:11:23 PM EST

You write:

Bjarne: It would be nice to have a standard GUI framework, but I don't see how that could be politically feasible.

Not worth discussing because it isn't going to happen for a variety of reasons:

The committee will never agree on a UI design model (MVC or UI delegate which will it be?)
Will require too much work for library writers.
More mature native toolkits will always be ahead of the game.

I am a C++ guy working on a Java project, and while I opted to originally develop the project with qt, I must admit that being confronted again with a Java effort, that the Java graphics libraries have improved quite a lot since Java 1.0.x days. It has a nice 2D library and its Swing widgets are usable to solve a large class of GUI problems rather easily (ok, one hits a wall after a while, but perhaps most people will feel happy with the existing widgets) - IMHO it is still ahead of qt.

If qt would be BSD or LGPL license on all platforms, what it is not and probably won't be, than this would be still a nice candidate for a C++ standard gui lib. The only serious free cross-platform effort at present, the GTK+ lib, is a C library, so we are stuck with that one.

I strongly believe that it would be worth to learn a lot from the Java GUI lib design and start a new free cross platform C++ effort immediatley.

I can't accept that is not possible.

Regards,
Marc
Regards, Marc

There is gtk--... (none / 0) (#106)
by leviramsey on Fri Mar 09, 2001 at 12:31:46 AM EST

GTK-- is a C++ wrapper of GTK+...

[ Parent ]
... and Inti (none / 0) (#129)
by mvw on Fri Mar 09, 2001 at 11:20:09 AM EST

The GTK-- effort is controversial enough, that Havoc Pennington is working on his own C++ bindings: Inti.

IMHO this not a sign of healthy competition in this case, but either the result of bad personal conflicts or inherent flaws. It is my feeling that a pure C++ approach, like what qt does, would be a better idea.


Regards, Marc
[ Parent ]

Gtk-- v. Inti (3.00 / 1) (#132)
by murrayc on Fri Mar 09, 2001 at 12:26:34 PM EST

On the contrary, it is clearly Inti that is controversial. Gtk-- is established, and endorsed by GTK+. Inti is a newer project which seeks to restrict developers to certain techniques. Also, GUI is only a small part of the Inti remit, and until recently it was not intended to give C++ access to Gnome technologies too.

It also seems as if Inti was created simply because RedHat did not have corporate control over the existing libraries. While I have great respect for Havoc, I suspect that he is not completely free to do as he chooses regarding this issue.

Time will tell. Developers have a choice, and the differences will not be so great that developers can't change their mind and recode for the other library.

[ Parent ]
Re: Gtk-- v. Inti (none / 0) (#134)
by gleef on Fri Mar 09, 2001 at 03:44:31 PM EST

I don't know of any controversy with either, but I haven't been paying much attention. Gtk-- intends to offer C++ bindings for GTK+ and GNOME stuff, pretty straightforward stuff.

Inti, on the other hand, doesn't look like it is thinking in terms of competing with Gtk--. From reading its site (http://sources.redhat.com/inti/), it looks more like they have in mind making an all-in-one "really easy to rapid develop" C++ toolkit to compete with Qt (and VB and C#). If I'm right, expect them to do push for the following after they get base functionality working:

  • Win32 (via Cygwin) support
  • A flashy IDE
  • ORBit/Bonobo bindings
  • libgnomeui bindings


[ Parent ]
Gtk-- v. Inti (none / 0) (#136)
by murrayc on Fri Mar 09, 2001 at 05:30:32 PM EST

Only the fourth one (libgnomeui bindings) has been announced by Havoc, and that was only a brief message that contradicts several of his previous statements that it wouldn't be done by Inti.

With or without these wish-list items, don't hold your breath.

[ Parent ]
GTK--/Inti (none / 0) (#166)
by mvw on Mon Mar 12, 2001 at 09:00:29 PM EST

At some point I stumbled over a nomozilla like farewell rant of one of the GTK-- developpers. A bit later I found Inti. To me it looked there was a serious enough controversy going on to spawn a second effort .


Regards, Marc
[ Parent ]

WxWindows (none / 0) (#125)
by drewcifer on Fri Mar 09, 2001 at 09:42:20 AM EST

Have a look at WxWindows (http://www.wxwindows.org/). It's cross-platform, and pretty nice looking.

[ Parent ]
This has almost everything... (none / 0) (#141)
by naasking on Sat Mar 10, 2001 at 09:14:05 AM EST

Check out ZooLib. It has just about everything that was discussed in this article. Threading, platform-indpendent networking, platform-independent GUI, limited GC support and hooks for platform dependent code if you really need it. The only significant feature that isn't there is reflection. This library is distributed under the MIT license. From the main page:

ZooLib is a cross-platform application framework. It allows you to write a single set of C++ sources and compile them to native executables to run on MacOS (including native Carbon executables), Windows (including 95, 98, ME, NT4 and 2000), BeOS or POSIX variants with XWindows such as Linux.

I've heard that it's a very good library and enforces good programming style.


[ Parent ]
C++ needs subtractions, not additions (3.50 / 2) (#93)
by starling on Thu Mar 08, 2001 at 07:40:27 PM EST

Seriously. The language is already too big and won't be improved by adding even more features. What would be useful is a subset of C++ which only incorporates the most useful parts of the language - third party libraries can be used to provide anything extra that might be wanted for a particular project.

We could call it (C++)--, or maybe just C for short.

Just the right size (4.00 / 1) (#100)
by partingshot on Thu Mar 08, 2001 at 10:47:24 PM EST

> The language is already too big

Whats the problem? Its still a lot
smaller than java. Plus,
you don't have to use all of it.
As you learn more you can use more.
Your compiler should be smart enough
not to link in any unused code.

[ Parent ]
Overly general... (none / 0) (#115)
by inpHilltr8r on Fri Mar 09, 2001 at 02:53:40 AM EST

...so what would you remove?

[ Parent ]
What to remove from C++ (4.00 / 1) (#131)
by starling on Fri Mar 09, 2001 at 12:25:46 PM EST

Everything that has been bolted on to C to make it "object oriented". I have nothing against object orientation, but if you want an OO language then adding things to a mid-level procedural language like C is not the right way to go about it.

The syntax is already overloaded (pun used with malice aforethought) to the point of creaking at the seams. For example, just how many different meanings of the keyword "static" are really needed? How about all the different variations on a type cast?

The situation with C++ reminds me of the early days of astronomy, when in order to keep the Earth at the centre of the universe planetary orbits were modelled using epicycles. When that didn't work out they added epi-epicycles and so on, but the real problem was that they were using a flawed assumption. In this case the flawed assumption is that C is a good base from which to build an OO language.

To summarise, what I'm saying is that C++ shouldn't really exist in its current form. Throw out everything that isn't focussed on making "a better C than C" and if you want an OO language use one that was designed as such from the start.

[ Parent ]

No nice (true hacker) C++ community site (4.33 / 3) (#97)
by mvw on Thu Mar 08, 2001 at 08:11:26 PM EST

Another interesting passage from the Stroustrup interview was:

So what can the C++ community do now? Make successes and successful techniques known. Articles and conference talks are possible venues, but for most busy programmers, a simple description on a Webpage is a more realistic option. Providing high-quality code to open source sites is probably the single most effective way of showing people what C++ can do (current examples are the SGI STL and Boost.org). Somehow, we have to create a widely known "portal" to C++-related information.

This is actually quite a dog. What C++ web site is there, that could deserve the title as focus of the C++ community?

And what has C++?

All of the above mentioned sites serve as well established focal points of their developer community. We have nothing comparable. I used Stroustrup's home at Bell labs quite often, sometimes Dinkumwares C++ library reference and once the download page of the ISO C++ standard at ANSI :-).

But else?

Look what boring or blatantly commercial stuff hides behind the present www.cplusplus.* sites. Best site right now, that comes close to a community site, is probably the cited Boost site, where some interesting libraries are gathered (like the graph theoretic one).


Regards, Marc

C and C++ have newsgroups (none / 0) (#99)
by pfaffben on Thu Mar 08, 2001 at 10:16:28 PM EST

The focal point of the C community is comp.lang.c, comp.lang.c.moderated, and comp.std.c. I suspect that something similar is true for C++, but I am only a regular in the C newsgroups, not C++.

[ Parent ]
Newgroups (4.00 / 1) (#165)
by mvw on Mon Mar 12, 2001 at 08:45:30 PM EST

I must admit that I no longer really use news groups (with one exception).

I read comp.lang.c++ in the early nineties - sometimes funny (anyone remembers the discussion between Stroustrup and Eiffel's Betrand Meyer? :) - but most of the time too huge to be useful.

At some point I stopped using news groups and switched over to mailing lists and web logs.

News groups don't play an important role anymore in my perceiption.


Regards, Marc
[ Parent ]
www.boost.org (none / 0) (#119)
by your_desired_username on Fri Mar 09, 2001 at 04:23:30 AM EST



[ Parent ]
I'll start one (none / 0) (#158)
by exa on Mon Mar 12, 2001 at 02:20:33 AM EST

I caught on a little late, but as a person who registered cxxhackers.org a few months ago, I want to start up a site. Perhaps using wiki wiki web. Anyway, a community site is a good idea and I wanted to have some kind of a site with links to people, software and docs.

Any suggestions welcome,

__
exa a.k.a Eray Ozkural
There is no perfect circle.

[ Parent ]
At this point, I stopped reading... (3.00 / 4) (#104)
by f5426 on Thu Mar 08, 2001 at 11:50:18 PM EST

(I broke my unspoken rule, and created this k5 account just for this post, because I was just too upset :-) )

> I for one would like to see Reflection added to the C++ standard because it will make writing class browsers in various IDEs a whole lot easier.

It is hard to be much wronger than that. Reflection don't buy you anything for writing an IDE. Just think about it a couple of seconds: do you think the IDE code is *linked* with the program it browses ? Of course not.

'Reflexion/rtti' apis are usefull to implement a higher level genericty, where the program starts to think/act about itself (and get a lot of power from this, as everything that is self-referent, cf the Godel, Escher, Bach). This concept is totally alien to C++.

I developped a lot with C++, and it is definitely not my favorite langage. Let's give you an example of real use of 'rtti' with a langage that supports it naturally. This langage is Objective-C, but most dynamic langages support analog constructs

// This instance method returns a class object that can be used to instantiate a controller for this instance
- (Class)controllerClass
{   return NSClassFromString( [NSString stringWithFormat:@"%@Controller", NSClassFromString( [self class] )] );
}

If this is implemented on a 'Something' object, it'll return the 'SomethingController' class. If invoked on a subclass of Something named Foo, it'll return a FooController class. Having an object, you can get its controller via: [[[anObject controllerClass] alloc] init]. If such class does not exist, it'll return a nil object.

What is called rtti on C++ is only a way to 'safely' downcast pointers. Vital to work-around C++ flaws, but incredibely limited.




'Reflexion' (why does java and C++ always have to put pompous names on most trivial features ?) have an big number of uses. For instance, transparent network distribution is done in objective-C by having instances of a proxy class that traps undefined messages, marshall the arguments, send data throught the network to another address space where the invocation is rebuilt and executed on the remote instance. Thoses steps needs 'reflexion' so the distribution code can work with any class and any methods, in particular those that were not present at compile time.

doSomething is a method defined on a class named 'Server'. anObject is really an instance of the NSProxy class, that know how to communicate with the original object. For every purpose, this proxy acts like if it is a real local Server instance.

[anObject doSomething];

When this message is sent, the proxy instance receives a 'forwardInvocation:' (this is a feature of the run-time), with an NSInvocation object as the argument. This object contains everything you need about the message (ie: the receiver, the selector [the method name, if you prefer], the arguments, etc, etc.). The proxy class encode this NSInvocation object content, send it to the server, where a 'listener' object will invoke it on the real Server instance. It'll then pass the return value back, and return it from the 'forwardInvocation:' method. Et voila, transparent network messaging. Works with any class.

This features are also used to implement 'bridges', which are ways to mix-and match different langages. In NeXT/Apple implementation, you mix Objective-C with java without any special construct (ie: methods invocations are passed back and forth between the two worlds). You can also seamlessly subclass Objective-C Classes in java. Those things are possible because of 'reflexion' APIs.



There is also what is called higher order messaging (okay, this is yet-another pompous name). This is a way to extend the sematic of the langage.

For instance, you can define a method 'executeInThread' at the NSObject level (ie: that will be defined for every class) that would return an object whose sole purpose would be to catch the next forwardInvocation, fork a thread, and, in the thread, perform the invocation on the original object, while returning to the caller. Bam. You have a new construct, that can be used like:

// This will 'doSomething' in a separate thread on 'anObject'
[[anObject performInThread] doSomething:42];

Of course, it is totally independant of what is the class of anObject is, and would work for any kind of messages.


> Reflection is primarily useful for developers who create tools such as debuggers, class browsers, interpreters, and a host of others that need to be able to extract information on arbitrary objects and execute code within these objects at runtime

You are obviously a C++ coder and lack a good grasp on concepts linked to dynamicity. Look at squeak (www.squeak.org), Objective-C (www.gnustep.org, http://developer.apple.com/techpubs/macosx/macosx.html) or tom (http://www.gerbil.org/tom/)... I don't know python, but it looks it have all this too. Dylan had great conceptual ideas (multimethods, singletons), but it hardly exists anymore.

Don't read me wrong. I used C++ a lot. I know C++ pretty well, having fight with probably every corner of it (From pesky templates-don't-match-with-inheritance, to placement new operators, via smart pointers, braindead operator overloading, mutliple virtual inheritance or dynamic_cast<>). My conlusion is that C++ is a bloated monster that should be buried in the backyard. Each revision adds more bloat. Each bloat add more problems.

About the question asked in the title, I hope that C++ will not regain what it lost against java. C++ is a brillant implementation langage, given the condition that:
1/ The problem is 'static' (ie: low-level enough not to require dynamicity)
2/ The developer is brillant (ie: in C++, good is often not enough)
3/ All the code is made with the same paradigms (ie: you don't have to mix and match code that heavily uses templates with code that heavily uses multiple inheritance)

Java don't have those requirement. An average coder can be a acceptable java coder in a few weeks, while he could never be a decent C++ coder.

Cheers,

--fred


C++ is a Waste of time for most applications. (3.33 / 3) (#116)
by lazerus on Fri Mar 09, 2001 at 03:01:12 AM EST

Unfortunately what you're forgetting is that computers can be bought, programmers must be rented. I don't care how "brilliant" the developers you are talking about are, the fact is that 90% of real-world systems do not need to be written in languages like C or C++, and to do so is a huge waste of time - sure the program will be faster, but it will cost more to develop, and be harder to maintain. The best current solution is neither C++ or Java. Write speed critical parts in C++ and the rest of the app in Python. I could turn around and say that C and C++ programmers are actually too lazy to write Assembly, and Assembly programmers are brilliant developers whereas C++ programmers are not - that logic parallels yours - and you can't deny how ridiculous that logic is. Writing 90% of applicatons in Assembly today would be a silly thing to propose, as is the proposition of writing those apps in C++.

[ Parent ]
Almost agree (3.00 / 1) (#124)
by hading on Fri Mar 09, 2001 at 09:24:16 AM EST

I almost agree, although I would replace "Write the speed critical parts in C++" with "Write the speed criticial parts in a language suitable for optimizing the speed" and "Write the rest of the app in Python" with "Write the rest of the app in a language suitable for writing the rest of the app". I find that combining C and Common Lisp or Smalltalk can be nice, for example.



[ Parent ]
No silver bullet (3.00 / 4) (#128)
by f5426 on Fri Mar 09, 2001 at 10:43:56 AM EST

(I now recall why I wanted to never post on kuro5hin)

I don't see the connection between your post and mine. Did you really intended to reply to me ? It looks like you read only the last line and hit reply, so you could do a little python advocacy.

I never ever proposed to write all the world programs in C or C++. Never. Maybe you missed the part saying "C++ is a bloated monster that should be buried in the backyard" ?


Quite the opposite. When I say the C++ is a brillant implementation langage, I mean 'brillant' for problem wher it applies. I even said it was appropriate (not required, appropriate) where:

"The problem is 'static' (ie: low-level enough not to require dynamicity) "

The key here is 'low-level'. C++ is a good langage if you have to implement an Monte Carlo Option Pricing scheme. Or a rasterisation library. It have absolutely nothing to do when dealing with user interface. And the lack of dynamicity/self-reference coupled with name mangling, fragile base classes and over-use of templates, makes it a pain to integrate with C++ code.

> The best current solution is neither C++ or Java. Write speed critical parts in C++ and the rest of the app in Python.

Nope. What you propose is a good solution in some case, but there is no silver bullet. Pretending there is one only shows your lack of experience. Are you going to put python in a SQL engine ? Are you going to write all of it in C/C++ ? Hint: when you says 'The best current solution...' without specifying the kind of problem it applies to, you are about to say something wrong...

> I could turn around and say that C and C++ programmers are actually too lazy to write Assembly, and Assembly programmers are brilliant developers whereas C++ programmers are not - that logic parallels yours - and you can't deny how ridiculous that logic is

You didn't understood what I said, or deliberatly mis-read it. I basically said the, in addition of all its problems, C++ is hard. My experience in recruiting and integrating developers in a 'hard core' team is that it takes about 12 months to become a good C++ developer (against 2 or 3 weeks to make an ObjC or java developer), if the person already knows C. Furthermore, there are people that are never going to be able to write decent C++. This was in the last part of the post, where I addressed the 'C++ vs Java' part of the question.

About this 'silver bullet' you talk about (ie: low-level in C/C++, high level in python), my favorite one, *for*the*program*I*am*on*those*years is Objective-C. ObjC is an hybrid langage, which allow you to use a single language to span a large spectrum of the application. For thing higher level than what ObjC can do, embeeding a langage into the application works really nice. I use lua for that (lua is the langage in which, for instance, the Grim Fandango or Baldur Gate's logic were written)

Cheers,

--fred


[ Parent ]
Aha... (3.00 / 2) (#133)
by leviramsey on Fri Mar 09, 2001 at 03:40:51 PM EST

it takes about 12 months to become a good C++ developer (against 2 or 3 weeks to make an ObjC or java developer), if the person already knows C.

There's the rub... the biggest problem C++ has faced is that there are too many C programmers coding in it (by which I mean, coding in C, except they use cout<< and some basic classes). This is a product of the perception that C++ is C with extra stuff thrown in. That may have been true years ago, but it's decidedly not in this day and age.

By the same token, the worst Java coders, in my experience, are the ones who expect it to be an enhancement to C++ (by enhancement, I mean extension).



[ Parent ]
For my edification... (4.33 / 3) (#135)
by slaytanic killer on Fri Mar 09, 2001 at 04:04:42 PM EST

It is hard to be much wronger than that. Reflection don't buy you anything for writing an IDE. Just think about it a couple of seconds: do you think the IDE code is *linked* with the program it browses ? Of course not.
Java Beans are classes which are generally meant to be manipulated and linked into using some sort of visual editor. Beans depend on the Introspection API, and underneath the hood of Introspection is the Reflection API. Therefore by this logic, writing an IDE which browses Beans (which are after all classes) is helped by Reflection.

Perhaps I do not see deeply into what you are saying.. But if you are dealing with a Bean that comes with no sourcecode, how else within Java do you see its properties and get/set methods? Other than decompiling bytecode? After all, good IDE's have some provision for dealing with stuff that comes with no sourcecode and aren't compiled specially.

Is this a situation similar to the old Japanese saying, "Beware the artisan who boasts twenty years of experience, when he in fact had only one year twenty times"?

[ Parent ]
Re: For my edification... (3.00 / 1) (#156)
by f5426 on Sun Mar 11, 2001 at 05:07:05 PM EST

I wrote a nice, articulated reply to you post, and posted it. It never found its way to kuro5hin, so I guess mozilla did something creative there. Again, but in a hurry...

In a nutshell, you have a point, mostly because my original sentence is badly written.

"Reflection don't buy you anything for writing an IDE" is untrue, in the general case, and you are right to point the example of a visual editor.

Anyway, I hope that the context make it clear that I really wanted to say "Reflection don't buy you anything for writing an IDE *class*browser*"

> Perhaps I do not see deeply into what you are saying.. But if you are dealing with a Bean that comes with no sourcecode, how else within Java do you see its properties and get/set methods? Other than decompiling bytecode?

Parsing the file class. The file class contains a lot of information, and byte code is only one of them. There is no need of decompiling bytecode to get the simple info a class browser needs (There is a section named the constant pool in a file class, and a few other sections, that are often references to this constant pool. There are sections containing all the fields of the objects, other all the methods, and other all the interfaces)

Anyway, I want to point that the real original sentence should have read "Reflection don't buy you anything for writing a IDE class browser for *C++*". (No one would load C++ classes in a runnning program. C++ don't even support dynamic loading).

> Is this a situation similar to the old Japanese saying, "Beware the artisan who boasts twenty years of experience, when he in fact had only one year twenty times"?

That's harsh. Fortunately, you used the interrogative form :-)

Cheers,

--fred


[ Parent ]
Edified (none / 0) (#163)
by slaytanic killer on Mon Mar 12, 2001 at 08:51:20 AM EST

No, I thought about quite a bit from your exchange with Carnage4Life and going through the VMspec and API source. Disagreements are fine, as long as I come to learn the other person's perspectives and emerge twice as strong as I was previously. ;)

As I see it, Reflection allows one not to depend on both the API and .class format remaining stable, and has smaller (less errer-prone) semantics; but no doubt making a dedicated .class file parser is faster and scales upward to many files better. Depends on the particular problem space. Perhaps Reflection gives a validating layer, but that's probably not true and redundant anyway.

[ Parent ]
Re: Edified (none / 0) (#164)
by f5426 on Mon Mar 12, 2001 at 04:41:19 PM EST

> Disagreements are fine, as long as I come to learn the other person's perspectives

Yep. It can also be very frustrating.

> As I see it, Reflection allows one not to depend on both the API and .class format remaining stable, and has smaller (less errer-prone) semantics; but no doubt making a dedicated .class file parser is faster and scales upward to many files better. Depends on the particular problem space. Perhaps Reflection gives a validating layer, but that's probably not true and redundant anyway.

As you say, it depends on the problem space. First, let's make it clear that we are talking about making a class browser. Reflection have many more interesting uses (which was my original point).

Now, it depends on the langages.

At one extreme, a smalltalk class-browser would necessarly depend on a reflection-like API (smalltalk have not even the concept of a class file).

At another extreme, C++ would get only little benefit from a reflection API (for the purpose of a class-browser), because you can't expect beeing able to load random code in your address space.

Java is somewhere in the middle. I would push the class file solution because:
* it scales better (as you pointed)
* it have more information in it (for instance, the class file entries can record the location of the various definitions in the source file)
* it doesn't force load/unload when a class changes
* it is possible to have several version of the same class at the same time.
* it can't have side-effects

In one word, the class file solution seems more natural to me. I may be wrong, as usual. We could imagine an IDE implemented in a huge special purpose VM that would support multiple versions, practically infinite number of loaded classes, etc, etc. Of course, as in this case the implementors have access to the VM they don't even need any reflection API. The could do all kind of tricks, like adding method to classes on the fly, renaming classes, etc, etc.

Cheers,

--fred



[ Parent ]
You Don't Know Java Or Have Never Used An IDE (4.00 / 2) (#139)
by Carnage4Life on Fri Mar 09, 2001 at 09:28:57 PM EST

It is hard to be much wronger than that. Reflection don't buy you anything for writing an IDE. Just think about it a couple of seconds: do you think the IDE code is *linked* with the program it browses ? Of course not.

Looks like you haven't used a modern Java IDE. Visual J++, Forte, JBuilder, and many others allow you to browse the functions and members of classes in your classpath while coding. They do this via Reflection. If C++ had reflection, the same thing could be done to the standard library and any other linked in libraries.

I developped a lot with C++, and it is definitely not my favorite langage. Let's give you an example of real use of 'rtti' with a langage that supports it naturally. This langage is Objective-C, but most dynamic langages support analog constructs

// This instance method returns a class object that can be used to instantiate a controller for this instance
- (Class)controllerClass
{
return NSClassFromString( [NSString stringWithFormat:@"%@Controller", NSClassFromString( [self class] )] );
}

If you had bothered to read the article you would have realized that Reflection and RTTI are not the same thing. The function you described can be implemented in Java and is an example of using reflection while it cannot in C++ because C++ does not have reflection. My entire article was about wishlist libraries that Stroustrup would like to see added to C++, reflection (i.e. the ability to do what your function describes) is one of them.

> Reflection is primarily useful for developers who create tools such as debuggers, class browsers, interpreters, and a host of others that need to be able to extract information on arbitrary objects and execute code within these objects at runtime

You are obviously a C++ coder and lack a good grasp on concepts linked to dynamicity.


You have obviously never used Java or seen the true ability power of reflection. With reflection I have written an API that allows me to turn on debugging in various classes at runtime without having to recompile code like I would with #ifdefs and C/C++. With reflection many TAs at my school write autograders that can be used to grade student projects without the student's code being forced to comply with a specific format (i.e. methods don't need to have specific names, checks to see that only permitted libraries were used is easily done, logic errors can be located easier and reported to students, etc).

Quite frankly it seems to me that you simply know the esoteric and academic uses of reflection and have never explored its possibilities in a real-world setting.

Look at squeak (www.squeak.org),

I go to Georgia Tech, a majority of Squeak development is done there. Most of us hate it because it is constantly in beta and is primarily an academic curiosity with little practical usage.


[ Parent ]
I know java and use IDEs since Think-C (3.00 / 1) (#145)
by f5426 on Sat Mar 10, 2001 at 05:44:20 PM EST

which, IIRC, means about 1987.

I don't want to start a flame war here. I don't really care you distruss my knowledge and experience.

> Looks like you haven't used a modern Java IDE. Visual J++, Forte, JBuilder, and many others allow you to browse the functions and members of classes in your classpath while coding.

Let's take one of the ~200 volumes of Computer Litterature I have in my bedroom (This book and a few others are in my bookshelf because I spent several weeks studiying the possibility of creating a commercial embedeed java VM. So, please, don't tell me I know shit)

Tim Lindholm * Frank Yellin

The Java Virtual Machine Specification
First Edition, First Printing, 1996, ISBN-0-201-63452-X

Chapter 4, page 83 throught 137

Title: "The class File Format"

Do you actually beleive that you need the slighest reflection to implement an IDE that understand classfiles ?

> They do this via Reflection

I know that sun own site says, in the reflection FAQ that 'The Reflection API is intended for use by tools such as debuggers, class browsers, object inspectors, and interpreters.'

I also know that the reflection API 'enables Java code to discover information about the fields, methods and constructors of loaded classes'

The key here is loaded. Draw your own conclusion.

Btw, I used one of the first version of Visual J++ on NT3.51. IIRC, the reflexion API was not present, yet it had no problem browsing classes in my classpath. Strange, isn't it ?

> You have obviously never used Java or seen the true ability power of reflection
[crunch]
> Quite frankly it seems to me that you simply know the esoteric and academic uses of reflection and have never explored its possibilities in a real-world setting.

Rotfl.

Quite frankly, in my first post, I said, half-humoristically, that 'you could not be much wronger than you were'. I now see that I was wrong, and take notice that you have astonishing resources in the area of 'wrongness'. :-)

The reality, is that you consider what you don't know to be 'academic' and 'esoteric'.

If you knew me a little better, you'll know that I never 'make things' and am very prompt in publically admitting my (technical) errors.

Oh, about the three or four 'academic' (still laughing my ass off) examples I gave (if I remember correctly, too lazy to check the original post) were taken from a few years experiences in NeXTstep/OPENSTEP/Rhapsody/Mac OS X

-> Getting the controller from the class name. I use it all the time. NeXTstep InterfaceBuilder used it to get the editor class name associated with an object. And very common idion in the NeXT world.

-> Marshalling the arguments and passing the on the wire. NeXT/Apple Portable Distributed Objects works just like that.

-> Making a cross-langage run-time bridge. Well, I just described the OPENSTEP java bridge. There are other objc bindings usung the same tricks.

-> HOM. I admit that this one is a little more esoteric, but I actually use it from time to time. I know people that use it extensivelly. Of course, I don't care if you beleive me or not.

Cheers,

--fred


[ Parent ]
Poor choice of words on my part... (4.00 / 1) (#146)
by Carnage4Life on Sat Mar 10, 2001 at 07:19:57 PM EST

I don't really care you distruss my knowledge and experience.

Neither do I. I noticed that I may have used a poor choice of words in my reply to your post.

Do you actually beleive that you need the slighest reflection to implement an IDE that understand classfiles ?

You don't need reflection to understand classfiles. But which do you think is easier; Writing a Java byte code parser or simply using calls like getFields(), getMethods() and getConstructors() to discover the particulars of a class at runtime?

Btw, I used one of the first version of Visual J++ on NT3.51. IIRC, the reflexion API was not present, yet it had no problem browsing classes in my classpath. Strange, isn't it ?

Again, I state that it is not absolutely necessary to use reflection to obtain information at runtime in Java, it is just a lot easier. Also I must admit I am not a hundred per cent on which IDEs use byte code parsing versus reflection to browse information on classes.

The reality, is that you consider what you don't know to be 'academic' and 'esoteric'.

You must be quite full of yourself aand your NeXT experiences. I'm still not sure what the purpose of listing what your beliefs of what the only uses of Reflection were except as to show you as being unimaginative or unwilling to learn new things. As for not knowing about the things you listed...

-> Getting the controller from the class name. I use it all the time. NeXTstep InterfaceBuilder used it to get the editor class name associated with an object. And very common idion in the NeXT world.

Creating a new instance of a class from its name is a done in most if not all Java JDBC applications as a way to launch the database driver. Instantiating an object from its metadata (Class object) is also something I'm familiar with since I used it on this research project.

-> Marshalling the arguments and passing the on the wire. NeXT/Apple Portable Distributed Objects works just like that.

Method invokations on remote objects, huh? You mean like is done in RMI, DCOM and CORBA which I have used and described in a previous K5 article

-> Making a cross-langage run-time bridge. Well, I just described the OPENSTEP java bridge. There are other objc bindings usung the same tricks.

I am familiar with language bridges such as JAva COm Bridge, but have never looked at the source to see if they use Reflection or RTTI nor is it readily obvious why Reflection would be used unless it is just specific to the case you described.

-> HOM. I admit that this one is a little more esoteric, but I actually use it from time to time. I know people that use it extensivelly.

I'm not even sure I understand what you described here.

Of course, I don't care if you beleive me or not.

I have no reason to doubt that you've used NeXT before. Although I do doubt your familiarity with Java.

Your original post seemed to have been a long complaint about how Reflection should be left to the languages you like instead of creeping into other languages as well, I disagree with this.


[ Parent ]
Let's settle this (3.00 / 1) (#154)
by f5426 on Sun Mar 11, 2001 at 01:28:02 PM EST

> You don't need reflection to understand classfiles. But which do you think is easier; Writing a Java byte code parser or simply using calls like getFields(), getMethods() and getConstructors() to discover the particulars of a class at runtime?

Reading a class file != making a byte code parser. Class, Superclass, Interfaces, Fields and Methods are readily avalaible from the class file, while byte code is buried into Code Attributes (the javac compiler don't have to decompile bytecode from existing .class files when compiling !)

I think you overestimate the work to extract info from a class file, while you overestimate the advantage of reflection for a class browser. In particular in C++, which was the point of your article. C++ don't have an ABI. C++ don't support dynamic loading. C++ code can crash the whole application, or freeze it. Given those three point, I doubt that any C++ IDEs are going to load compiled code in their address space just to implement a class browser.

> You must be quite full of yourself

I am not sure I fully understandf this idiom, but, if it means what I think it does, then I think you could have avoided that.

> I'm still not sure what the purpose of listing

Don't systematically mis-read me, it start becoming boring. I listed those thing in response to you *very* inflamatory comment, which I re-quote here:

"You have obviously never [...] seen the true ability power of reflection. [...] it seems to me that you [...] have never explored its possibilities in a real-world setting. "

So I re-list the examples (that you qualified as 'academic' and 'esoteric'), then you point that those are real-world use of reflection ! Of course, that's the point !

> as to show you as being unimaginative or unwilling to learn new things.

How insulting. I hope you feel better.

> > HOM. I admit that this one is a little more esoteric, but I actually use it from time to time. I know people that use it extensivelly.

> I'm not even sure I understand what you described here.

A nice simple real-world documented example of HOM is NSUndoManager, as documented at http://developer.apple.com/techpubs/macosx/Cocoa/Reference/Foundation/ObjC_classic/Classes/NSUndoManager.html
(In particular the paragraph named 'Invocation-Based Undo').

> Although I do doubt your familiarity with Java.

Thank you, I was expecting something like that. Note that, when describing my examples, I was _not_ pointing about things that java don't do. I was pointing to what I beleive are the most usefull uses of reflection-like APIs (ie: things that C++ can't do, and that would have been better candidate than the (wrong) it'll make class browser in C++ IDE easier).

> Your original post seemed to have been a long complaint about how Reflection should be left to the languages you like instead of creeping into other languages as well, I disagree with this.

I don't see how you could ever read it like that. Anyway, I apoligies for beeing such a poor writer. My original post was a complaint about how Reflection is a very important part of any (dynamic) Object Oriented langage, and that describing it as a "usefull tool for writing class browsers in IDE" was terribly limiting. Of course I am pleased if it creeps into other langages (as it makes my design habits portable). For instance, I would love to see categories or real message passing in java (or C++, but that seems unlikely)

Now, in a broader sense, I'm getting quite bored by the kind of individual you are. You continuously mis-read me while making inflamatorry remarks. Let's review them.

"You Don't Know Java Or Have Never Used An IDE"
"You have obviously never used Java"
"You have obviously never seen the true ability power of reflection"
"you simply know the esoteric and academic uses of reflection"
"You have never explored its possibilities in a real-world setting. "
"You must be quite full of yourself aand your NeXT experiences"
"to show you as being unimaginative or unwilling to learn new things"
"I do doubt your familiarity with Java"

All this because I have been upset by your (wrong) sentence that claimed (parapharsed) "the impact of reflection would making C++ class browser in IDE easier to code". This is the main point. You were wrong. Talking about wether *java* IDE uses reflection is theorical at best.

I admit having crossed the line a couple of time (saying "You [...] lack a good grasp on concepts linked to dynamicity" and "You consider what you don't know to be 'academic' and 'esoteric'. "), but it seems hardly comparable to you attitude.

That said, you don't seems to be the kind of guy I like to interact with, because I tend to avoid insulting people.

Cheers,

--fred


[ Parent ]
RE: Let's settle this (none / 0) (#155)
by Carnage4Life on Sun Mar 11, 2001 at 02:23:59 PM EST

I think you overestimate the work to extract info from a class file, while you overestimate the advantage of reflection for a class browser.

Maybe.

In particular in C++, which was the point of your article. C++ don't have an ABI. C++ don't support dynamic loading. C++ code can crash the whole application, or freeze it. Given those three point, I doubt that any C++ IDEs are going to load compiled code in their address space just to implement a class browser.

The entire purpose of the original article was to imagine what the situation would be like by 2005. Considering that the C++ ABI is currently being worked on it is highly conceivable that it will be completed and supported by numerous compilers by then. Once the ABi is completed, attempts can be made to support dynamic loading. As for C++ code being able to crash or freeze the whole application (I assume you mean if there are memory corrupting errors such as array out of bounds error or faulty pointer arithmetic), I must agree that would be a problem with dynamically loading classes since you can't simply wrap the code in

try{
/* dynamically load class */
}catch(Exception e){
/* handle errors caused by dynamically loaded class */
}

like can be done in Java.

A nice simple real-world documented example of HOM is NSUndoManager, as documented at http://developer.apple.com/techpubs/macosx/Cocoa/Reference/Foundation/ObjC_classic/Classes/NSUndoManager.html
(In particular the paragraph named 'Invocation-Based Undo').


Thanks for the link.

Anyway, I apoligies for beeing such a poor writer. My original post was a complaint about how Reflection is a very important part of any (dynamic) Object Oriented langage, and that describing it as a "usefull tool for writing class browsers in IDE" was terribly limiting.

Your original post read like it was an unprovoked attack. Secondly I do agree that writing class browsers is a rather limiting way of describing the power of reflection and that's why I also stated "and a host of others that need to be able to extract information on arbitrary objects and execute code within these objects at runtime". Although looking back at that sentence it does look like I'm claiming that class browsers and the like are the main uses of Reflection which isn't true. That's what I get for reading Sun's FAQ instead of just using examples from my experience. :)

I admit having crossed the line a couple of time (saying "You [...] lack a good grasp on concepts linked to dynamicity" and "You consider what you don't know to be 'academic' and 'esoteric'. "), but it seems hardly comparable to you attitude.

We both seem to have misunderstood each other and made statements in haste which in hindsight would have been better left unsaid. I apologise for my inflammatory remarks and did not mean to insult you or your experience.


[ Parent ]
I'm surprised... (4.00 / 2) (#143)
by naasking on Sat Mar 10, 2001 at 09:27:43 AM EST

...that no one has mentioned ZooLib. It has alot of the things people are looking for(except reflection). It supports quite a range of platforms as well. I'm not a C++ programmer, so I don't know how good it is, but I've heard it's an excellent library, almost on par with the BeOS C++ api. To me, that should be reason enough to check it out considering how much praise BeOS has gotten for it's elegant api.


It's not what C++ hasn't got (1.00 / 2) (#150)
by Friendless on Sun Mar 11, 2001 at 02:27:46 AM EST

I think the benefit of Java over C++ is not that it has got all those things (mostly), but that there is so much stuff it hasn't got which allow bad code to be produced, such as #define, typedef, and backwards compatibility with C. There is just too much antiquated stuff in C++, and too many undisciplined programmers, to keep the language alive. It is like an old man staggering under the burden of his years. Java is similarly gathering cruft, but thanks to a dominant class library, not as fast.

Nonsense (2.00 / 1) (#152)
by cezarg on Sun Mar 11, 2001 at 02:32:31 AM EST

There is a good reason for every feature in C++. As for it being old and tired tell that to KDE developers. I guess that they will laugh in your face. You're not a programmer really, are you?

[ Parent ]
What I'm working on, rather than waiting for 2005 (4.00 / 1) (#159)
by exa on Mon Mar 12, 2001 at 02:53:49 AM EST

I'm doing a small portability layer, assertion/logging and a graph library. The portability layer covers threading/sockets/filesystem etc. Why am I doing that? Because I looked at what exists. and didn't like it much. Too clumsy coding out there in free software portability libs. C++ really needs a working, abstract and efficient portability layer.

Second this assertion/logging a la nana. Again lots of available code but nothing I'd use on a regular basis. So, I'm applying the 'zero overhead' principle to this area. Someday :/
Plan: tie these services to iostream well, and extend gnu nana to the C++ realm (means don't use any <stdio>)

Third, I'm writing a graph lib which is way more important for me. Unfortunately, this has already evolved into something that is very different from standard lib approach.

All these might as well be pushing C++'s limits too hard. C++ isn't the cure for every problem out there. Of course, C++ is hardly comparable to Java. I saw a lot of non programmers jump on the Java bandwagon, and they are still non programmers. Blah. Java is a special purpose prog. lang. You can't write any serious software with it. Only lame web applets. Tried to write a data clustering algorithm with it and it blew up in my face, 100 times slower than C++. Automagically turned my bit grinding Athlon to an old C-64. I occasionally experience revelations during which I promise to dedicate the rest of my life to destroying Java. ( and in a sense, I'm doing it :> )

In the long term however both C++ and Java *must* go away. They are both flawed designs which are based on the most flawed language ever: C. I don't advocate any specific language, but for what it's worth more symbolic and declarative programming languages should take over. And OO? Well, if OO was the silver bullet than we would have these mindless 'software engineering' people (which is of course the shameful hunchback of computer science) solve all the hard software problems. Which they couldn't

Thanks,

__
exa a.k.a Eray Ozkural
There is no perfect circle.

I've got a professor that'll disagree with you... (none / 0) (#170)
by Rhamadanth on Wed Mar 14, 2001 at 03:59:58 AM EST

I took an Object Oriented languages class at my University this year.

His assertion is that a good design will overcome any problems with the language. There are certain limitations that you won't be able to get past, but if your program is 100 times slower in Java than it is in C++, you're doing it wrong. Heck, if your java is 10 times slower than your C++ you're doing something wrong.

The best use for Java is as a multithreaded programming language. The built in multithreading stuff is great.
-- The /bin/truth is out there.
[ Parent ]
Your superb professor (none / 0) (#174)
by exa on Wed Mar 14, 2001 at 04:40:00 PM EST

You really think so wisecrack? The performance penalties in Java are so limiting that you'll never be able to do the kind of programming you do with regular C/C++. Two things I did, and twice it failed for me: 3d rendering and graph clustering.

I'm not doing anything wrong, I translated the code exactly from C++ for the latter project (the usual adjacency list graph code) and saw that it was 10-100 times slower for the very same shit.

Of course, it won't matter for your OO-mentor-professor. He *never* gets into real life and writes code. All he does is rant about one facet of a huge thing called programming.

Ask _any_ CS grad here who works on large scale problems. Ask them why they would not use Java for their code. And ask them why FORTRAN is still in currency.

Ha ha. There are even idiots out there who use a java implementation of MPI to do HPC. I pity them.
I read a paper that _showed_ that the MPI/Java implementation was 20 times slower than the one in C/C++.

The reason I got 100 fold slowdown was because I was using printf debugging (you know, your pretty fucked language just can't run a decent debugger, that's why). Whenever you do any kind of I/O the processing blows a few times more. The memory allocation is another problem. In an interesting way, the program used many megabytes of memory for even small graphs. Anyway, if you haven't written any advanced algorithms, you'll never understand what I'm talkin' about. Forget it.

__
exa a.k.a Eray Ozkural
There is no perfect circle.

[ Parent ]
My, oh my (none / 0) (#175)
by Rhamadanth on Thu Mar 15, 2001 at 12:05:47 AM EST

Such anger! It's okay, calm down.

I'm not wisecracking, either. And he's not the kind of professor that looks at theoretical results and declares things to be true. On one of our assignments on Parallel Bacterial Mesh computations, he was able to get a significant speedup, just by applying some careful design and forethought.

Moreover, I happen to know that my professor does Smalltalk and Java programming commercially. I don't think you should speak of things that you don't know about.

I can't deny that C++ is going to be faster at some things than Java, but maybe part of your problem is that you've decided to directly port the code, instead of taking a look at Java and realizing that it doesn't do things at all the same as C++, and programs should be designed differently. A lot of things have overhead in Java...you have to work to eliminate repeated use of those things.

It's interesting that you think you can make the assumption that I haven't done anything complex in my career. What exactly do you know about me, anyway?

Maybe you're having the same problem when you program Java. You're making too many assumptions without any underlying knowledge. That's gonna bite you in the ass every time.

-- The /bin/truth is out there.
[ Parent ]
talking FORTRAN and talking Java (none / 0) (#176)
by exa on Thu Mar 15, 2001 at 03:48:29 AM EST

I'm angry to Java because I think it stole about two months of my precious life. Unfortunately, there weren't other means to code the thing I wanted...

When this Java hype came around, I read all of their manuals. I learnt everything that could be learnt, and started coding this 3d renderer. After I saw that the performance wass awful both in speed and memory, I decided not to write anything in Java until they fixed it. In 2000, I tried out the 1.3 stuff from both IBM and blackdown on my shiny debian box for the grad. data mining course. And I saw that they had not moved an inch. Only, there is more OO bloat in the base library. And that's it.

Remember. There is no shrink wrapped software written in Java. Only lame terrible web _applets_. Gosh, some people even use that beast for servers. On my debian box, there are thousands of (really) software packages installed. The percentage of Java programs is miniscule, or better said: insignificant.

How do you implement an efficient graph type in Java? You can point out those graph codes that draw _really-small_ graphs which would be turtle-speed when compared to some smoking piece of c code. But then the Java codes will be nowhere near the kind of codes we have to do, hard operations on very large graphs. With 10^7 or more edges. The algorithms require a very tight grip on the memory, and each traversal is meant to burn your cpu. That kind of coding is clearly not for Java.

BTW, your professor is on the wrong route. People mainly use C/C++ and FORTRAN on ASCI class supercomputers. And there is something they know. Just read a couple of CFD or LP papers.

Regards,

__
exa a.k.a Eray Ozkural
There is no perfect circle.

[ Parent ]
Now we're getting somewhere (none / 0) (#178)
by Rhamadanth on Thu Mar 15, 2001 at 07:02:46 PM EST

Okay, now that you seem much more calm, I think we can have a discussion. Great. :)

Believe it or not, I mostly agree with you. I *do* think that a 100x slowdown is a little bit wrong, but you admit that it's because of debug statements thrown in. I/O shouldn't be that bad, but it is.

I personally like Java as a language. From my point of view as a programmer, I really like the way the language is designed. Its performance leaves something to be desired, but on a multiprocessor box, it's pretty decent. Taking advantage of multithreading really helps.

If you've read some of my other messages, you'll see that I'm really an ObjC/C proponent (Smalltalk, too...but I realize its limitations in the real world.)

For the mathematical programming that we did, solving problems on bacterial meshes (basically a grid-graph), we got pretty decent performance. When we multi-threaded it, it got better. When my prof went in and showed us how to *really* do it, it was pretty great. It may be that whatever graph work you were doing was basically undoable properly in Java, but it might have been okay if someone that had a different outlook on it tinkered with it. I don't know. (On a sort of related note, my Dad took on a programming project that involved Java. He literally got a 100-fold increase in performance because the people that did it before decided to create a new instance of a certain object every time a certain method needed to be run, instead of doing things with class methods. The program was bloated with literally millions of instances of objects. I'm not saying that you'd do a bone-head thing like that, but it's little oversights that make the big differences, sometimes.)

Give Java some time, too. I know that it's got a lot of lame hang-ups right now, but so does C++, and C++ is a lot older.

As for my professor, he's done a lot of stuff, and ended up working with Java. From a research perspective, apparently, it's very interesting. Especially if you're trying to frameworks around parallel processing...it's one of the things that Java happens to do very well.

Me, I'll stick with C when I need performance, and Java when I want to code up something really fast that needs a GUI. I'll leave C++ alone until they clean up the damn grammar.


-- The /bin/truth is out there.
[ Parent ]
The problem is with Java!! (none / 0) (#181)
by exa on Fri Mar 16, 2001 at 01:05:45 PM EST

No language that allocates every damn object on the heap and then does garbage allocation, and favors multiple inheritance and actually does method dispatch on 90% of the code you write... can be used for real scientific computing.

Easy multithreading is one thing, performance is another. Much of the code in Java is "thread-safe" which means that it's too slow to handle for a single processor program, and nowhere fast as a tuned multi-threaded code in an SMP, which also means that it is the worst choice for _any_ NUMA architecture, especially Beowulf. Message passing has got to be fast, no other way, and the very fact that it's so much slower than C makes it the worst choice for any sort of large scale computation.

Which also means that the research that presupposes OO/Java is meant for parallel programming, may be a dead-end. In parallel programming you can afford only the highest amount of flexibility and minimum overhead for basic parallel operations. No design patterns or anything... You need bit-raping, net-flooding monsters that roam int and double arrays.

Which in turn implies that high performance computing applications written in Java will be beneficial only for pedagogical purposes, and will never exceed the scope of 5-computers-in-a-lab toy applications.

I don't favor C/C++ or FORTRAN, but those are the only portable languages that give us decent performance; which means that our papers have a chance to be published. I would personally prefer to get rid of them all and develop with a functional parallel language.

BTW, I do think that Objective/C is a pretty cool language and has much better potential than Java. I would like to see some parallel programming libraries, and who knows it might be a good choice for parallel programming. If someone could just short-circuit the method call syntax to a distributed object implementation... I don't know, might be very nice. I think something along the lines of Charm++, but fully integrated with the language. Yes, that would be really neat.

Also check out Cilk at MIT (I suppose). That's what parallel programming needs, easy and fast message passing.

Thanks,


__
exa a.k.a Eray Ozkural
There is no perfect circle.

[ Parent ]
Reflection/Persistence requires compiler support.. (none / 0) (#160)
by exa on Mon Mar 12, 2001 at 03:00:29 AM EST

I reckon that proper reflection and persistence would require compiler support. Do you think there is a way to do it without extending the compiler (using standard RTTI)?

AFAIK, you can't do that with g++. I see this in the typeinfo header:

class type_info {
private:
// assigning type_info is not supported. made private.
type_info& operator= (const type_info&);
type_info (const type_info&);
...


__
exa a.k.a Eray Ozkural
There is no perfect circle.

Another Feature Wish: Bounds Checking. (5.00 / 1) (#168)
by meldroc on Tue Mar 13, 2001 at 11:22:17 PM EST

One of the most common causes of crashes, security holes and other nasty, hard-to-find bugs comes from accessing out-of-bounds data through buffer overruns and other actions that aren't illegal, but should be. For example, the code

int a[10];
a[11] = 42; // Out of bounds!

is perfectly compilable (though you may get a warning). When it is run, Bad Things happen, because the behavior of accessing beyond the bounds of an array is undefined.

C++ has the ability to make a class similar to a vector class where all accesses are checked to ensure they are in bounds by overloading the subscript operators to check bounds before returning a value, and throwing an out-of-bounds exception if needed. Bounds-checked versions of vector, list and other STL data structures should be added to the standard library.

I'm not saying C++ should be modified so all accesses are bounds checked, I can see reasons to forgo bounds checking. But the capability should be there for those who wish to use it. This would do much to eliminate many bugs and security problems prevelant today.

Bah. (3.00 / 1) (#177)
by pb on Thu Mar 15, 2001 at 06:33:25 PM EST

Static bounds checking is trivial, bothersome, and useless; I turned it off in Turbo Pascal, but the compiler would still whine whenever I created a dynamic array behind its back...

However, that bounds checker would never detect code like this (translated to C)

int a[10];
int x = 11;
a[x] = 5; // Out of bounds!

Maybe a smarter compiler could catch that, but in general the out-of-bounds errors that need catching are run-time errors; for debugging purposes, it might be more useful to use one variable to index the array, and simply assert that it can never be larger than the size of the array.

Most of the security problems, however, come from using fixed-length arrays in the first place. I wrote routines in C to dynamically resize my arrays as needed, especially for input from a file handle; that worked pretty well for me. YMMV.
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
He is talking about C++ not C. (none / 0) (#179)
by Carnage4Life on Thu Mar 15, 2001 at 10:08:44 PM EST

Your example has nothing to do with his post. You are describing statically checking array bounds via the compiler while he is talking about creating a standardized vector-like class with an overloaded [] operator that either resizes itself when an out of bounds access occurs or throws an exception.

Such a class would be trivial to implement (Heck, I could knock it out in 15 - 30 minutes) but currently does not exist in the Standard Template Library.

[ Parent ]
Already done. (none / 0) (#189)
by eMotion on Tue Apr 03, 2001 at 04:10:01 PM EST

Many (not sure if all or not) of the applicable containers already have this capability.

vector::at()
const_reference at(size_type pos) const;
reference at(size_type pos);
The member function returns a reference to the element of the controlled sequence at position pos. If that position is invalid, the function throws an object of class out_of_range.

I believe std::string and deque have the same functionality, but I'm not sure about the other STL containers.

So, to assign to a std::vector and use bounds checking, it would look something like this:

using namespace std;
vector<int> vec;
try
{
vec.at(10) = 1;
}
catch(out_of_range)
{
cout << "oops!" << endl;
}



[ Parent ]
Some numbers (none / 0) (#173)
by mvw on Wed Mar 14, 2001 at 09:04:47 AM EST

Sheez, the Java 1.3 class lib is really huge.

Here are some stats from the excellent Java Developers Almanach by Patrick Chan (it lists all signatures, looks like a train route year book :-):

Packages: 77
Classes: 1730
Interfaces: 400
Fields: 4006
Methods: 17158


Regards, Marc

Good coding? (none / 0) (#180)
by excalibor on Fri Mar 16, 2001 at 04:47:56 AM EST

Sheesh!!!

With those numbers, I don't see how Sun really expects its Java users to use the right class(es) for a given task...

It will probably end up being a, say, 30% of classes very used (even misused) buy the typical Java developers, and only some few experts will use the whole library, creating code hard to maintain (for it will be alien code for most other programmers...)

Something similar happens (or has happenned and it's now being solved) with C++ being mostly used as a better C because programmers haven't updated their knowledge to the ISO language... That will change in the next years, while I think Sun will keep on producing classes and classes for any and every fancy Internet hype or feature... at this pace, emmbebbing a jvm in a small device will be impossible (good-bye to universal portability...) Well, I won't suffer too much for that.

I very much prefer something more maneagable like the Standard C++ Library... Power, in this case, is not in numbers, but in flexibility for useful, understandable combinations with high expressiveness...

If they just add half of what Mr. Stroustrup commented on that interview (specially, IMO, Persistence and unified Sockets/Networking) we will have everything we wanted to make great software...

laters,
david

[ Parent ]
Java vs. C++ (4.00 / 1) (#188)
by tHEMeL on Sun Mar 25, 2001 at 03:49:01 PM EST

Power, in this case, is not in numbers, but in flexibility for useful, understandable combinations with high expressiveness...

So, I'm a C++ developer, I know the language pretty well, and by using little C and much ++ I get my code to be pretty pointer-free and memory-effective, without garbage collection.

Now, I'm forced to do a project in Java because everyone in mgmt was all hyped up about EJBs and application servers...

At first I totally hated Java, but it is not as bad as it looks, though I still find it hard to write Java code that 'satisfies' me when I look at it.

The problems you solve are a bit different... While in C++ you spend a lot of time coding solutions, in Java there's already a solution somewhere in the standard library, but it takes about 30 lines of code to convert all of your objects to the types you require... Let's take a look at an example I encountered today. So, there's this DOM DocumentWriter from the Xerces implementation, and I need to serialize an XML document to a string. Problem, the DocumentWriter only takes a PrintWriter for input, so I have to create a StringBuffer, then create a ByteArrayOutputStream, create an OutputStreamWriter for that and a PrintWriter from there... voila, I can write UTF8-encoded XML to a String.

It always works like that, and every time you want to do something simple you have to implement some kind of standard API for it to work, which is bad in default Java and even worse in an EJB environment.

What I miss about Java is cleverness. I always feel, well, constrained, when I code Java. I can't pin it down, but my intuition works best with templates, and operator overloading seems like the most logical thing in the world. Still, in Java I have to use stupid equals() and compareTo() functions, and to get a type-safe collection I have to create a subclass of the original (which, in part, is responsible for the bloat encountered in APIs).

What REALLY annoys me is the restriction on exception throwing. When I as a programmer want to use an exception, I have to declare it in my method header, and then in every calling level it passes... This kills off the beauty of distributed exception handling, adding a throw there and catching somewhere across a dozen calling levels. And while, if done consistently, this would stop programs from dying from unhandled exceptions, there's still no guarantee that any given line of Java code won't throw at least a handful of exceptions like NullPointerException, StringOutOfBoundsException and thereby catch you off guard.

Well, since I'm losing direction in this rant and I'm about to simply condemn Java as immature crap, I'll better stop (before I get to the nifty garbage collection, that doesn't help shit when someone uses native resources and doesn't provide finalizer, see Oracle JDBC drivers...).

Thanks for bearing with me.

[ Parent ]

map (none / 0) (#184)
by pjhunter on Mon Mar 19, 2001 at 12:52:39 PM EST

The current C++ standard has a sorted hashtable declared in map but does not have a facility for developers who want a hash table without the overhead of sorting.

The C++ map is implemented as a black root tree not a hashtable.


%pjh%
C++ in 2005: Can It Become A Java Beater? | 189 comments (187 topical, 2 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!