C or C++ something else....

[benben]

This might serve as a starting point:

http://www.digitalmars.com/d/comparison.html

IMHO, this comparison is biased. Almost half of the comparison criteria
are D language constructs. In a similar way an assembly language can
score much better if you put in criteria like "direct access to
register", "access to specific machine instructions", etc.

Ben

 

[Walter Bright]

IMHO, this comparison is biased.

Of course it is biased. It even says:

"And, like all language comparisons, it is biased in terms of what features
are mentioned, omitted, and my interpretation of those features."

 

[kwikius]

Of course it is biased. It even says:

"And, like all language comparisons, it is biased in terms of what features
are mentioned, omitted, and my interpretation of those features."

This looks ominous:

http://www.digitalmars.com/d/template.html

regards
Andy Little

 

[Walter Bright]

This looks ominous:

http://www.digitalmars.com/d/template.html

That's a little dry, being a specification. For more on what the design
decisions are and how to use them:

http://www.digitalmars.com/d/templates-revisited.html

 

[kwikius]

That's a little dry, being a specification. For more on what the design
decisions are and how to use them:

OH I see. Try looking at it in IE6. Just looks like a blank page.

regards
Andy Little

 

[Walter Bright]

OH I see. Try looking at it in IE6. Just looks like a blank page.

I am using IE6, and it displays fine.

 

[Walter Bright]

This is why, for large open source projects that have a large developer
base, C is sometimes an easier choice.

That's something I hadn't thought of, but it makes sense. C++ is a very
difficult language to master, so the more C++ features you use, the
smaller the number of developers there are who can contribute
successfully to the project.

 

[Phlip]

That's something I hadn't thought of, but it makes sense. C++ is a very
difficult language to master, so the more C++ features you use, the
smaller the number of developers there are who can contribute successfully
to the project.

That suggestion works both ways. C makes an endless range of trivial
operations (string copy, polymorphic collections, callbacks) absurdly hard.
So the more C++ techniques you use, the easier your code gets, and the more
crew you can use.

 

[kwikius]

I am using IE6, and it displays fine.

What can I say. I see a blank page. with a quote about templates or so.
I need to scroll down a page to see any other data.

regards
Andy Little

 

[Walter Bright]

What can I say. I see a blank page. with a quote about templates or so.
I need to scroll down a page to see any other data.

That's actually a bug in IE6. You'll see the same effect on Digg and
Slashdot.

 

[kwikius]

That's actually a bug in IE6. You'll see the same effect on Digg and
Slashdot.

Whatever. What I see is:

Templates
I think that I can safely say that nobody understands template
mechanics. -- Richard Deyman

I took it to be some sort of weird joke about D not actually
implementing templates, which may not be the impression you're after ?

regards
Andy Little

 

[Walter Bright]

That suggestion works both ways. C makes an endless range of trivial
operations (string copy, polymorphic collections, callbacks) absurdly hard.

Such are klunky, tedious and boring in C, sure, but not
hard-to-understand, as everyone who codes in C has to deal with it and
gets used to it.

So the more C++ techniques you use, the easier your code gets, and the more
crew you can use.

Certainly, C++ makes such things easier to use for people who understand
C++. I'm skeptical it makes things easier for people who don't
understand C++.

Let me give my favorite example: a friend of mine in college decided to
teach himself programming. He picked up the Fortran reference manual,
read it, and created his first program that wrote a bunch of data to a
file. It worked, but ran incredibly slowly. Mystified, he showed it to a
programmer who pointed out that the output file was opened, one
character was appended, and closed inside a loop, and why would he write
such obviously inefficient code? My friend replied that nothing in the
Fortran manual said anything about how I/O actually worked, so how was
he supposed to make the right design decisions?

I don't believe that people who don't understand C++ will be able to
write professional quality code in it, no matter how easy it looks.

In the end, it's just another consideration. For example, if I was
designing a device driver API for an operating system, I'd have it be a
C interface in order to maximize the pool of developers who can write
device drivers. Making it a C++ template metaprogramming API would
ensure that few would ever write a device driver.

 

[Greg Comeau]

That's something I hadn't thought of, but it makes sense. C++ is a very
difficult language to master, so the more C++ features you use, the
smaller the number of developers there are who can contribute
successfully to the project.

I agree this is an issue of concern, but I have found that the
claim a few sentence down that "The reality is: ... it takes
years to master it completely (including its C subset)."
to be universally true of many languages, including C,
so it becomes an interesting thought. It also ignores the
consequences also statted that the reality also is that
"C++ is a significantly more powerful language, and has
many features that allow writing more robust code."

 

[Greg Comeau]

That suggestion works both ways. C makes an endless range of trivial
operations (string copy, polymorphic collections, callbacks) absurdly hard.
So the more C++ techniques you use, the easier your code gets, and the more
crew you can use.

IOWs, the magic bullet remains elusive, and each way has its
own set of pros and cons, both short term and long term.

 

[Walter Bright]

Whatever. What I see is:

Templates
I think that I can safely say that nobody understands template
mechanics. -- Richard Deyman

I took it to be some sort of weird joke about D not actually
implementing templates, which may not be the impression you're after ?

LOL. I'm poking a bit of fun of a famous Richard Feynman quote.

 

[Walter Bright]

I agree this is an issue of concern, but I have found that the
claim a few sentence down that "The reality is: ... it takes
years to master it completely (including its C subset)."
to be universally true of many languages, including C,
so it becomes an interesting thought.

It takes many more years to master C++ than C.

It also ignores the
consequences also statted that the reality also is that
"C++ is a significantly more powerful language, and has
many features that allow writing more robust code."

For someone who thoroughly understands those features, yes. For those
who don't realize when they need to provide a virtual destructor, no.

 

[Roland Pibinger]

That's something I hadn't thought of, but it makes sense. C++ is a very
difficult language to master, so the more C++ features you use, the
smaller the number of developers there are who can contribute
successfully to the project.

Question: 'Every language has its flaws. What are the three things you
dislike most strongly in C++?'
Scott Meyers: 'I'd like to answer this question with "complexity,
complexity, complexity!"'
http://www.bookpool.com/ct/98031

 

[Phlip]

In the end, it's just another consideration. For example, if I was
designing a device driver API for an operating system, I'd have it be a C
interface in order to maximize the pool of developers who can write device
drivers. Making it a C++ template metaprogramming API would ensure that
few would ever write a device driver.

This is the difference between premature and postmature optimization.
Optimization generally obfuscates, yet an OS kernel that optimized by any
mean necessary would win the OS wars, and (at last) fully exploit our
hardware. That's a major benefit for the small cost of leaving behind the
driver authors who comprehend C-style optimizations better.

 

[Walter Bright]

This is the difference between premature and postmature optimization.
Optimization generally obfuscates, yet an OS kernel that optimized by any
mean necessary would win the OS wars, and (at last) fully exploit our
hardware. That's a major benefit for the small cost of leaving behind the
driver authors who comprehend C-style optimizations better.

If one is trying to write a take-over-the-world operating system,
getting wide device driver support is huge. A lot of people who write
device drivers are hardware engineers (who designed the hardware
device), not software engineers. They aren't going to invest another 10
years just so they can write a device driver in C++. They just won't
support your operating system. An OS that won't run on the hardware I
need it to run on is useless to me, no matter how fast it is.

Perhaps you could, however, provide two driver APIs: one in C, and one
in C++.

 

[Greg Comeau]

It takes many more years to master C++ than C.

My experience is that that is not always the case.
Probably neither of us can prove either way though.

For someone who thoroughly understands those features, yes. For those
who don't realize when they need to provide a virtual destructor, no.

For those who don't realize, probably still won't realize
under other, probably more by-hand involved, alternatives.