D

[Paul Hsieh]

Is there anything that makes bstring superior to usual C++
interface/implementation, like std::string ?

Apparently there is, but I am not a C++ expert (a C++ person who was
very dissatistfied with std::string and/or MFC's CString wrote the
interface for me, I just filled in the implementation based on my C
library), so I don't know exactly what it is. Likely its performance
and functionality (but functionality is not a likely reason -- can't
you just build a super-class and add in whatever functionality you
like?). I will go investigate this further.

 

[Ioannis Vranos]

[...] I suggest you
read "The C++ Programming Language" 3rd Edition or Special Edition by Bjarne
Stroustrup (the creator of C++), *cover to cover*.

Well, I'm afraid that's way too much of an investement just to find
out why implementing more sophisticated memory management
functionality is a bad idea for C++. Is there any way you can provide
some kind idea as to why this is?

I am aware of the whole constructor / destructor paradigm in C++, and
yes of course that mitigates some kinds of memory leaks quite
substantially. But it doesn't remove the existence of "new" or
"malloc" which are still useful, yet are the source for memory leaks
and other corruptions (double freeing, for example) in the first
place.

Well lets better move to c.l.c++ to discuss this kind of things because
c.l.c. is inhabited by dragons and other nasty creatures waiting for some
innocent passers to attack them.

In regular programs you can almost completely avoid the explicit memory
allocation and deallocation on the free store by using the standard library
containers (use them for objects in the stack too).


Example:


#include <vector>

// ...

using std::vector;

vector<int> vec;


vec.push_back(7);


for (vector<int>::size_type i=0; i<vec.size(); ++i)
// do whatever with vec;


// At the end of the scope or when an exception is thrown, vec
// is cleaned along with its contents automatically.


But hurry lets leave from clc, i am hearing them approaching!






--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

 

[Randy Howard]

You must live in an extremely skewed world -- there are very few
projects left today where you can justify simply starting in the C
language. About the only places where this makes sense is where you
have no other compilers available, and its either that or assembly.

I thought you were making some good points, right up until the part
where you said the above, and then I became convinced you had simply
had some sort of brain-ECC error. You *must* be joking.

If you want C++ and have the memory and processor to spare, go for
it. If you like Python or Ruby better, they're also readily
available. At this point, it seems like your "mission" is to form
a line of converts heading down the hall for the other languages.
If so, that's rather OT for clc.

*I* want features, more safety, and I want a heck of a lot more
performance than C gives me!

C runs screamingly fast on most hardware, and the only places I've
ever had to tweak it for better performance is when standard library
functions have been the bottleneck. That's not the language, that's
the "libc" implementors' fault. Writing around such bottlenecks if/
when the become a factor is no big deal if you are even moderately
competent. Going to Python or one of your other alterative
languages certainly isn't going to help with performance.

And why am I resorting to inline assembly any time I want real
performance out of my state of the art C compiler?

Because it can't read your mind? Or because you haven't experimented
enough with how your compiler optimizes particular C constructs for
a given target CPU/OS combination? Maybe your target compiler isn't
as SOTA as you think it is. Real world example: VC++6 (used as a C
compiler) on Windows vs. gcc on Linux. The Windows implementation
(identical source code) ran 30% slower for a tight loop using a
particular standard library call. Looking at how code was generated
on both platforms, the gcc compiler was smart enough to resort to
the appropriate MMX instructions when compiled with the right arch
and cpu flags. The MS compiler simply did not. A little inline
assembly in my own replacement for the offending library call for
WIN32 and the program performed basically identically on both
platforms. I normally wouldn't care about maximum performance per
se if it required inline assembly because a lot of applications
simply don't need it. In this case, performance was THE thing so
it mattered above all else.

Why am I constantly re-implementing standard data
structures, debug wrappers, and various other things that are well
known practice? At least the C++ people had the good sense to create
STL ...

Because you never started building your own library of ADTs, or
didn't want to obtain one elsewhere? I can't read your mind.

For example, there is almost no C standard library function that I
cannot rewrite, or respecify to improve both performance and program
safety. Almost the entire stdlib is of a "first hack" quality,
practically enforced by the standard.

Then don't use it. There are a lot of standard lib functions that I
won't use either. As you say, it's not hard to implement similar
functionality on your own, or obtain it from a freely available or
commercial library.

 

[Kevin Easton]

(e-mail address removed) says... [...]

*I* want features, more safety, and I want a heck of a lot more
performance than C gives me!

C runs screamingly fast on most hardware, and the only places I've
ever had to tweak it for better performance is when standard library
functions have been the bottleneck. That's not the language, that's
the "libc" implementors' fault.

In some cases, it is a problem with the language, because the problem
lies in the way the standard library is defined. For example, functions
like strcat and strcpy should really be returning a pointer to the end of
the resulting string - they've already calculated it, but then they throw
it away, so if the caller needs it they have to calculate it again,
which can be time-consuming (relatively speaking) for long strings.

- Kevin.

 

[Frank Schmitt]

I'm not as familliar with C++, and, its feature set is not really what
I want. C++ also has absolutely no opportunity to be any faster than
C.

IMHO, this statement is wrong - how about expression templates ?

regards
frank

 

[Wolfgang Riedel]

I'm not as familliar with C++, and, its feature set is not really what
I want. C++ also has absolutely no opportunity to be any faster than
C. C++ has a certain set of additional features that, frankly, I just
don't have any interest in. Its just a personal preference kind of
thing.

When I say I want features, what I am talking about is things like
multi-threaded programming, guaranteed portability, access to my
platform's synchronization primitives (in a portable abstract way, of
course), access to ordinary arithmetic capabilities present in most
CPUs (like rotate, a proper portable right shift, expanding
multiplies, add with carry, and so on), a much more capable
preprocessor (so that you can unroll loops and so on in a more
systematic way, or have directly expressible explicit compile time
type checking), a way to debug and manipulate the memory heap,
completely abstracted stream I/O and so on.

I don't just want more features, I want features that from the lessons
that *I* have learned.

use PL/1

Wolfgang

 

[Mirek Fidler]

I'm not as familliar with C++, and, its feature set is not really what

I want. C++ also has absolutely no opportunity to be any faster than
C.

Well, I think you are completely wrong on this, at least if you take
into consideration time spend to implement an application. Templates
provide much more effective way w.r.t. runtime performance.

When I say I want features, what I am talking about is things like
multi-threaded programming, guaranteed portability, access to my
platform's synchronization primitives (in a portable abstract way, of
course), access to ordinary arithmetic capabilities present in most
CPUs (like rotate, a proper portable right shift, expanding
multiplies, add with carry, and so on),

OTOH, I agree that most of above issues are missing both from C and
C++.

a much more capable
preprocessor (so that you can unroll loops and so on in a more
systematic way, or have directly expressible explicit compile time
type checking),

Yeah. That is what C++ and templates are about too.

a way to debug and manipulate the memory heap,
completely abstracted stream I/O and so on.

Library stuff.

I don't just want more features, I want features that from the lessons
that *I* have learned.

I am learning C/C++ for more than 15 years now and what I have
learned during first 5 years is fact that C++ is way better tool than C


Mirek

 

[Mirek Fidler]

I am aware of the whole constructor / destructor paradigm in C++, and
yes of course that mitigates some kinds of memory leaks quite
substantially. But it doesn't remove the existence of "new" or
"malloc" which are still useful, yet are the source for memory leaks

Yes, but I think that most important is fact that
construtor/destructor paradigm removes almost any need of "delete" or
"free", at least at interface level.

In out C++ code there is hardly one "delete", usually well hidden in
implementation, per 10000 lines of code. I can show e.g. complete
sources of Win32/X11 wordprocessor without single "delete" or "free"
call.

Mirek

 

[Greg Comeau]

I'm not as familliar with C++, and, its feature set is not really what
I want.

Of course, you may prefer C, but it's sort of hard to believe
that there is *nothing* in C++ that you'd want. Perhaps this
is indicative that indeed you are not as familiar with C++.

C++ also has absolutely no opportunity to be any faster than
C.

If you are not familiar with something, then how can
you make that claim? Certainly C++ has many such opportunities.
Frankly, both language could do with some improvement here.

C++ has a certain set of additional features that, frankly, I just
don't have any interest in. Its just a personal preference kind of
thing.

When I say I want features, what I am talking about is things like
multi-threaded programming, guaranteed portability, access to my
platform's synchronization primitives (in a portable abstract way, of
course), access to ordinary arithmetic capabilities present in most
CPUs (like rotate, a proper portable right shift, expanding
multiplies, add with carry, and so on), a much more capable
preprocessor (so that you can unroll loops and so on in a more
systematic way, or have directly expressible explicit compile time
type checking), a way to debug and manipulate the memory heap,
completely abstracted stream I/O and so on.

This is confusing, because C has some of these same problems.

I don't just want more features, I want features that from the lessons
that *I* have learned.

This make sense. On this same note, it's important to keep
open-minded about featured derived from what others have learned
too. Many features in many languages are easy to misunderstand,
including in C, and do sometimes require a closer look. An
issue is that it's easy for syntax to become a focus when
things such as the underlying modeling, design, abstraction,
and techniques should be the focus.

 

[Ioannis Vranos]

You mean like exists in CBString? Yes, I am fairly well aware of these

things.



Don't get me involved with MFC. Regarding MS stuff i know .NET only.

My concern is not for the usual or expected usage. All languages are totally
safe and will never leak memory if you use them properly, or as intended or
even in just a limited scope (if translate all your ADTs into vectors, for

eg).


Lets see this. If you "new" memory and an exception is thrown you are in
high risk to have memory leak. If you fopen() a file the same problem.
That's why you have better use the standard library facilities.


Do you know the technique "resource aquisition is initialization"? C++
supports it.

But for some reason that has not served to diminish Java's message about safety
and portability now has it?

Personal opinion: Java is crap whatever approach you take to evalue it.

I'm not looking for a way for me *personally* to
write safer code (I can do that on my own in any language, thank you very
much.) I want to make code that I am reading or picking up from *other* people
to have safety standards at least equal to my own. Now how can *I* do that?
The fact is, *I* can't; but the *language* can!

Let's discuss a bit on "resource aquisition is initialization" technique.


class myfile
{
FILE *fp;

public:
myfile(const string &filename, const string &mode)
{
fp=fopen(filename.c_str(), mode.c_str());

if(!fp)
throw some_exception;
}

~myfile() { fclose(fp); }

operator FILE *()
{
return fp;
}

// ... more public member functions
};


// some scope
{
myfile file("whatever", "r");

// ...
}


When the object "file" reaches the end of its scope or an exception is
thrown, it releases its resources automatically.

In this way you have no resource leak, no need for explicit allocation and
deallocation, and no need for garbage collection. And you have the optimum
speed.

C++ standard library types support "resource aquisition is initialization".

I haven't moved to Java, because I don't buy their performance claims. In fact
I am pretty sure they are full of it. So I am aware that sacrificing
performance for safety is an option, but what if I don't want to sacrifice it?
What if I want more performance *and* more safety? Am I just screwed like
everyone in CLC and the ANSI standards committee would have me believe?

Still i think you need to read TC++PL 3.






--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

 

[Malcolm]

I am learning C/C++ for more than 15 years now and what I have
learned during first 5 years is fact that C++ is way better tool than C

It's a different tool. To extent that a C++ compiler is more complicated and
more expensive to write than a C compiler it is also "better".
However there are many situations where it is actually an advantage not to
have C++ features. An obvious one is where code has to be maintained by an
electronic engineer who isn't a full time programmer. Another one is where
the program is quite simple and it is much easier to do a procedural rather
than an object-oriented design - use of C++ in this situation often leads to
a horrible hybrid that is hard to understand and debug.

 

[Thomas Stegen]

Well lets better move to c.l.c++ to discuss this kind of things because
c.l.c. is inhabited by dragons and other nasty creatures waiting for some
innocent passers to attack them.

This is like going into a Rangers pub wearing celtic shirt. It is
not only dangerous, it is also stupid.

And by the way, if the "innocent passer[sic]" attacks he is no longer
innocent... Or am I missing something.

 

[Thomas Stegen]

Paul Hsieh wrote:

[SNIP]

How dare you? Haven't you learned by know that this type of discussion
is useless here at clc. C is the safest and fastest language on the
planet. Why on earth do you want additional libraries when you can
write them yourself? And if, against all odds, there is something bad
about C we don't want to know about it. We want to continue living in
the belief that C is the superior of all languages and has no flaws
whatsoever.

If you have a complaint submit it to the committee, we do not want these
kind of constructive and educational discussions here. Quite frankly,
such discussions offend us in ways you cannot even imagine.

That the drone-like predictability of responses to posts such as yours
from the regulars around here haven't deterred your attempts yet surely
marks you as a troll.

Pathetic.

 

[Mirek Fidler]

I am learning C/C++ for more than 15 years now and what I have

It's a different tool. To extent that a C++ compiler is more complicated and
more expensive to write than a C compiler it is also "better".

I agree with this, but I do not see as reason.

However there are many situations where it is actually an advantage not to
have C++ features. An obvious one is where code has to be maintained by an
electronic engineer who isn't a full time programmer.

Well, perhaps.

Another one is where
the program is quite simple and it is much easier to do a procedural rather
than an object-oriented design - use of C++ in this situation often leads to
a horrible hybrid that is hard to understand and debug.

I do not understand this. If it is procedural, write is as
procedural. C++ does not require you to put 'classes' where you do not
need them.

Mirek

 

[Jerry Coffin]

[ ... ]

I'm not as familliar with C++, and, its feature set is not really what
I want. C++ also has absolutely no opportunity to be any faster than
C.

Rather the opposite: C has virtually no opportunities to be faster than
C++, but there are quite a few situations in which C++ not only can be,
but more importantly, typically WILL be faster than C. Just for an
obvious example, templates offer quite a few opportunities for
generating code in-line that would normally involve calling functions
through pointers in C. In many cases, you can expect the C++ version to
be twice as fast as a bare minimum.

When I say I want features, what I am talking about is things like
multi-threaded programming, guaranteed portability, access to my
platform's synchronization primitives (in a portable abstract way, of
course), access to ordinary arithmetic capabilities present in most
CPUs (like rotate, a proper portable right shift, expanding
multiplies, add with carry, and so on),

C++ doesn't make a lot of fundamental improvements in these areas, but
it does provide a few things that make them substantially less
problematical. In C, you end up with some non-portable bits of code to
do the bottom levels of these sorts of manipulations, and C++ doesn't
really help in that area at all. C++ does, however, typically make a it
a whole lot easier to integrate those non-portable bits into the rest of
the code in a much more natural way. To use one of your examples, C++
doesn't directly support expanding multiplies -- you need to write some
functions to do that. The difference is that in C, you end up with code
something like:

your_type x, y, z;

set_val(&y, something);
set_val(&z, something_else);
ex_mul(&x, &y, &z);

Whereas in C++, you can overload operators, to at least keep the rest of
the code a bit more readable, so your multiplication looks like:

your_type x, y = something, z = something_else;

x = y * z;

a much more capable
preprocessor (so that you can unroll loops and so on in a more
systematic way, or have directly expressible explicit compile time
type checking),

C++ provides basically that, but doesn't call it "a more capable
preprocessor" -- instead, it calls it "templates".

a way to debug and manipulate the memory heap,
completely abstracted stream I/O and so on.

Depending on what exactly you mean by "complete abstracted" (for
example) C++ may provide quite a bit more of what you want. Then again,
it may not either -- for better or worse, your description is incomplete
enough that it's almost impossible to give a definitive answer.

 

[JustBoo]

An
issue is that it's easy for syntax to become a focus when
things such as the underlying modeling, design, abstraction,
and techniques should be the focus.

Oh man, I fight this all the time, in myself and with younger
engineers.

We start a meeting about a "subject," and before you know it, it's
become a debate about syntax and coding style. Hmmm... kinda'
reminds me of certain usenet newsgroups. I'm far too eager to
jump in myself and add fuel to the fire. I have to force myself to get
back to the subject at hand. It's way too much fun... it wastes an
incredible amount of time. Sometimes I say we could solve
world-hunger if we spent as time and energy on that. I'm just as
guilty though.

"One night I walked home very late and fell asleep in somebody's
satellite dish. My dreams showed up on TVs all over the world."-sw

Get your stinking advertisement off my post you striped bastards!

 

[JustBoo]

How dare you? [snippy]
And if, against all odds, there is something bad
about C we don't want to know about it. We want to continue living in
the belief that C is the superior of all languages and has no flaws
whatsoever.

Damn, that made me laugh out loud. You go sister!

If you have a complaint submit it to the committee, we do not want these
kind of constructive and educational discussions here. Quite frankly,
such discussions offend us in ways you cannot even imagine.

I feel your pain, baby.

That the drone-like predictability of responses to posts such as yours
from the regulars around here haven't deterred your attempts yet surely
marks you as a troll.

What is the wind speed of a...

Pathetic.

"Major Strasser has been shot!... Round up the usual suspects!"

 

[Greg Comeau]

Oh man, I fight this all the time, in myself and with younger
engineers.

We start a meeting about a "subject," and before you know it, it's
become a debate about syntax and coding style. Hmmm... kinda'
reminds me of certain usenet newsgroups. I'm far too eager to
jump in myself and add fuel to the fire. I have to force myself to get
back to the subject at hand. It's way too much fun... it wastes an
incredible amount of time. Sometimes I say we could solve
world-hunger if we spent as time and energy on that. I'm just as
guilty though.

This may sound like I'm contradicting myself, but I think
there is room for discussions about syntax and style too.
But I think it's important, as in all discussions, to prioritize,
and to give things time constraints. It's often good when
somebody can offer rationales, no matter what the discussion,
rather than mandates, or because it sounds good. Last but
not least, over the years I've come to appreciate things
such as "lunch time", or a discussion over a beer.
So there is a time and place for everything. Sometimes
it is just recreational fish-story'ing, other times
you can actually learn something from it.

 

[Louis-Philippe Huberdeau]

A language specification for D is already availible along with a compiler.

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

 

[David Rasmussen]

Yes, it is. It's been done and there's a compiler for D. See
www.digitalmars.com/d/ and www.digitalmars.com/d/comparison.html for a
language comparison.

D won't lift off until there is a gcc front end for it. When that
happens, it's use will explode.

/David