User: Password:
|
|
Subscribe / Log in / New account

yet another +5

yet another +5

Posted Mar 27, 2008 7:09 UTC (Thu) by pr1268 (subscriber, #24648)
In reply to: yet another +5 by wahern
Parent article: Striking gold in binutils

If the metric is easier development because the language provides more sugar for certain patterns, how do you justify not using Java or C#?

I can't find in my earlier post where I said I didn't use Java. In fact, I do from time to time. My earlier post was about why I'm such a fan of C++ - and how I can still enjoy all the benefits of both C and C++, even in the same program.

However, I take exception to your implication that Java provides competitive "sugar" to C++. Consider the following example of reading an integer from a file:

C++

int x;
ifstream in_file;
in_file.open("foo.txt");
assert(in_file);
in_file >> x;

Java

int x;
String line;
try {
  FileReader fr = new FileReader("foo.txt");
  BufferedReader br = new BufferedReader(fr);
  line = br.readLine();
  x = parseInt(line);
}
catch (Exception e) {
}

Not more sugar, IMO. Yes, I do realize that Java has to abstract a lot of file I/O due to the fact that it supports multi-byte character sets on dozens of architectures with different byte orders and file systems, thus explaining the syntactic "salt". But, still, even the C version is pretty simple:

C

int x;
FILE* in_file;
in_file = fopen("foo.txt", "r");
assert(in_file);
fscanf(in_file, "%d", &x);

But again, I'm not trying to dismiss Java, only to provide a counter example of where Java fails to provide any programming benefit over C++. Actually, the C and C++ examples above would likely only work on ASCII or UTF-8 filesystems, but Java's UTF-16 support is native to the language1. So, Java gets to tell C and C++ what "portability" means (even if the programmer has to dig through 67 layers of abstraction to accomplish what he/she set out to do). ;-)

As for C#, well, despite my own thoughts about Microsoft getting in the way, I just don't see why C# even needs to exist. Microsoft was actively marketing Java development suites and compilers in the mid- and late-1990s (Visual J++, anyone?), adding their own APIs and language features, until Sun Microsystems had the guts to stand up to MS and tell them to stop violating the terms of Sun's license (with a successful lawsuit). It was all sour grapes for MS afterwards, so they just had to go run out and create their own Java imitation. C'mon, Microsoft, you already had legions of Visual Basic programmers! Why go out and create a whole new language when there are so many already out there? Was it because Visual Basic wasn't "Java-like" enough?

Not that I think C# is a bad language; it does have some interesting features. But, I get this strange feeling that C# skills will be useless come five years from now, just like Visual Basic skills are in much less demand than they were five years ago.

As for coding C#, well, I abandoned MS Windows four years ago for a single-boot Linux. And the only native C# compiler for Linux I know of is Mono. Which causes anomalous behavior on my Slackware machines. Come to find out Mono has library dependency issues with my current toolchain and dynamic linker. In other words, I experienced DLL HELL in Linux2, simply by installing Mono (version 1.24) in Slackware 12. How ironic this is considering I'm trying to write Windows applications in Linux. I suppose the gratuitous DLL hell is all part of the Microsoft "experience" I'm supposed to get whilst writing C# code. No thank you.

I mostly agree with the rest of your post - I do indeed like C's portability (hey, it was one of the core motivations for creating the language to begin with), and I also like its efficiency. I can't say that adding garbage collection to C++ would be worthwhile; Even Bjarne Stroustrup labored over whether to include garbage collection in C++ back in the early 1980s.

My personal thoughts are that garbage collection built-in to the programming language would send several mixed messages to programmers using that language:

  • "I don't have to worry about freeing up allocated memory, since the GC will do it for me. This activity doesn't slow down my program, does it?"
  • "Since I don't have to worry about keeping track of run-time allocations (why bother? The GC will clean up my mess for me!), I can indulge my code by generously overestimating allocation space. Who cares about the mess to be cleaned up after the party? That's what the GC is for."
  • "I've been writing frugal, tidy, and efficient code for years by judiciously managing my run-time allocations. How come all of the sudden I don't have control over this anymore? What if I don't agree with the GC strategy? Can't I disable it completely and manage my own memory usage? After all, I'm quite good at it."

(And Boehm better not be on the line.)

I LOLed at your comment. I downloaded a source tarball several months ago (I forget which program/application) that had a Boehm GC dependency. I thought to myself, C++ doesn't have garbage collection for a reason, but why does this particular project feel that it needs to slather a layer of protection over the code? Are the programmers lazy? Or, do they not know how to use new and delete?

When C++ gets garbage collection and closures, call me.

Perhaps some of your garbage collection needs could be met by using the C++ standard library container classes (e.g., vector, list, deque, etc.). Or, more appropriately stated, your need for a GC to begin with could be eliminated. But, perhaps that's a discussion for another time. I've rambled on long enough, it's been fun pontificating and bloviating (to quote one of my graduate professors). :-)

1 C++ does have explicit support for multi-byte character sets with its wchar_t type. I don't know what kind of support C has in this regards, or if it supports multi-byte characters at all.

2 I'll openly admit that Microsoft unfairly receives the brunt of user frustration over DLL hell when in reality the basic concept of library dependency hell is a Unix creation which predates DLL files by several years.


(Log in to post comments)

yet another +5

Posted Mar 27, 2008 10:54 UTC (Thu) by nix (subscriber, #2304) [Link]

GC support in the language has one major advantage over not having it: if the compiler and GC
layer cooperate, the language can do type-accurate garbage collection. That's pretty much
impossible with a 'guess if this bit pattern is a pointer' implementation like Boehm.

(But still, why GC in a C/C++ program? Easy: sometimes, the lifespan of allocated regions is
complex enough that you don't want to track it in your own code. A lot of large C/C++ systems
have garbage collectors in them, often hand-rolled. GCC does, for instance, and while its
effect on data locality slowed GCC down a lot, it *also* wiped out huge piles of
otherwise-intractable bugs. In my own coding I find that Apache-style mempools and disciplined
use of ADTs eliminates most of the need for GC while retaining the nice object-lifecycle
benefits of C/C++, so I can use RAII without fear. Losing that pattern in Java is a major
reason why I try to avoid the language: in effect Java eliminates memory leaks only to replace
them with other sorts of resource leak because you can't use RAII to clean them up for you...)

Python

Posted Mar 27, 2008 12:43 UTC (Thu) by ernstp (subscriber, #13694) [Link]

Sorry, completely off topic, I just had to post this.

Python:
int( file("foo.txt").read() )

:-P

Python

Posted Mar 27, 2008 13:21 UTC (Thu) by pr1268 (subscriber, #24648) [Link]

Show-off!

You forgot to catch the exception of the file not opening. Where's your deadParrot() error-handling function?

;-)

Python

Posted Mar 27, 2008 17:46 UTC (Thu) by cwarner (guest, #47176) [Link]

How far we've come.. how far.

Ruby

Posted Mar 28, 2008 1:15 UTC (Fri) by Tuxie (guest, #47191) [Link]

sorry, I had to :-)

x = File.read("foo.txt").to_i rescue deadParrot

Ruby

Posted Mar 28, 2008 16:08 UTC (Fri) by alkandratsenka (guest, #50390) [Link]

Reading whole file in memory just to parse int from it's first line is very funny :)

You'll need a longer version like this

(File.open('foo.txt') {|f| f.readline}).to_i rescue deadParrot

c++ vs c

Posted Mar 27, 2008 14:51 UTC (Thu) by jimparis (subscriber, #38647) [Link]

> C++
> 
> int x;
> ifstream in_file;
> in_file.open("foo.txt");
> assert(in_file);
> in_file >> x;

> C
> 
> int x;
> FILE* in_file;
> in_file = fopen("foo.txt", "r");
> assert(in_file);
> fscanf(in_file, "%d", &x)

Here's something that really bugs me about C++.  Where's the documentation?  With C, "man
fopen" "man assert" "man fscanf" gives me all the info I need.  With C++, I suppose some
manual page for ifstream would be most appropriate, but I don't seem to have it.  Which
package is that in?  Or must I resort to google searches every time?

Of course, even if I did have C++ manpages, deciphering "in_file >> x" still requires that I
track backwards to figure out the types of "in_file" and/or "x" (yay operator overloading!)

c++ vs c

Posted Mar 27, 2008 15:13 UTC (Thu) by pr1268 (subscriber, #24648) [Link]

I suppose some manual page for ifstream would be most appropriate, but I don't seem to have it.

All Glibc standard library functions have man pages (I'm unsure whether these came before or after the shell functions' man pages). I think this might be related to the founding philosophy that C is supposed to be portable, and the man pages were a convenient way of distributing documentation on the system call interfaces without having to decipher C code you've never seen before (not impossible, but time-consuming).

I can't recall ever seeing a C++ man page, but then again, the whole language standard was in limbo up until its 1998 ISO standardization. Not sure why they don't exist nowadays, but perhaps Stroustrup would prefer that you buy his book instead (stupid conspiracy theory). Some of the top links in Google searches for various C++ functions and standard library classes are quite decent (IMO).

Personally, I recommend anyone trying to "dive into" C++ go find a used C++ textbook. Just be sure to get one dated more recent than 1998 (because older C++ texts are rife with code that predates the ISO standard).

c++ man pages on gcc.gnu.org

Posted Mar 27, 2008 17:01 UTC (Thu) by bkoz (guest, #4027) [Link]


See:
http://gcc-ca.internet.bs/libstdc++/doxygen/

I believe some os vendors (debian, I think) package these.

-benjamin

c++ vs c

Posted Mar 28, 2008 12:00 UTC (Fri) by cortana (subscriber, #24596) [Link]

Indeed, man pages are not really suitable for C++ (and many other languages) for the reasons you state.

If you are on a Debian system, run: apt-cache -n search libstdc++ doc and install one of those packages. Then check out its directory in /usr/share/doc.

The docs are also online at http://gcc.gnu.org/onlinedocs/libstdc++/.

A very nice quick reference to iostreams and the STL can be found at http://cppreference.com/.

I have to say I don't really prefer the man pages for C development because often they contain oudated or just plain incorrect information. I prefer to use the glibc manual directly for reference.

Use of assert

Posted Mar 30, 2008 4:53 UTC (Sun) by pjm (subscriber, #2080) [Link]

Incidentally, please don't use or encourage use of ‘assert’ for checking for I/O errors or
other can-happen runtime conditions.  Such checks will disappear when compiled with -DNDEBUG
(or conversely make it impractical to compile with -DNDEBUG, thus discouraging use of
assertions), and fail to give a meaningful error message.  That should be ‘if (!in_file) {
perror("foo.txt"); exit(EXIT_FAILURE); }’.

Use of assert

Posted Mar 31, 2008 21:05 UTC (Mon) by pr1268 (subscriber, #24648) [Link]

Well, I had to level the playing field somewhat since Java forces me to put all that code in a try/catch block...

But yeah, I generally do what you recommend in C/C++.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds