D

[Ioannis Vranos]

Re: D

"Paul Hsieh" <qed@pobox.co m> wrote in message
news:796f488f.0 307100037.44517 83b@posting.goo gle.com...[color=blue]
>
> Well, he's asking for libraries and safety, and has pointed out the
> buffer overflow problem related to safety -- that's an obvious queue
> my "better string library":
>
> http://bstring.sourceforge.net/
>
> The point of the bstring library, especially in comparison to the
> numerous other string libraries out there, is that its high
> performance, it carries absolutely no extra baggage with it, while
> remaining totally interoperable with the char * buffer style strings.[/color]


There is no buffer overflow problem in the C++ standard library and
std::string is also interoperable with char *.
[color=blue]
> As to his comment about GC, I have thought about it, but I can't think
> of a way to implement it properly with high performance *and* support
> the typical malloc/free paradigm at the same time.[/color]


Check .NET. It has interesting GC mechanisms.

[color=blue]
> Even if you could
> make it work, the fact that C/C++ still cannot *guarantee* prevention
> of buffer overflows leading to undefined behavior, add a GC background
> thread and this is likely to manifest itself in programing errors that
> are *truly* impossible to debug.[/color]


C & C++ are different languages. In C++ code you can guarantee buffer
overlofw protection by using the standard library facilities. I suggest you
read "The C++ Programming Language" 3rd Edition or Special Edition by Bjarne
Stroustrup (the creator of C++), *cover to cover*.






[color=blue]
> Some C/C++ programmers are also used
> to the idea that "encoded pointers" shouldn't lead to unexpected
> behavior (though most C-based GC solutions fail when you do things
> like this.)
>
> The real goal of GC is eliminate the memory leaks, and simplify code
> somewhat. So as an alternative to GC, why not just significantly
> extend the heap management semantics? So many programmers write their
> own "debug wrappers" for malloc/realloc/free anyhow, why not just
> decide on a one useful set of very general extensions, provide sample
> code for the vendors to use, and add it to the language standard. I
> have some ideas here that have worked very well for me in practice, if
> the C++ people are truly open to these ideas.[/color]



You need a slow, thoroughh read of TC++PL 3 (see above). :-)







--
Ioannis

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

[Finny Merrill]

Re: D


This is off-topic in comp.lang.c

[Paul Hsieh]

Re: D

"Mirek Fidler" <cxl@volny.cz > wrote in message news:<bejipi$59 hrr$1@ID-198693.news.dfn cis.de>...[color=blue][color=green]
> > *I* want features, more safety, and I want a heck of a lot more
> > performance than C gives me! The thing is, there is no *technical*[/color]
>
> May I ask you a humble question why you are not using C++ instead ?
> I agree there is no technical reason and that is what C++ is about....[/color]

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.

--
Paul Hsieh

http://www.pobox.com/~qed/

http://bstring.sourceforge.net/

[Paul Hsieh]

Re: D

"Ioannis Vranos" <ivr@nothis.ema ils.ru> wrote:[color=blue]
> "Paul Hsieh" <qed@pobox.co m> wrote:[color=green]
> > Well, he's asking for libraries and safety, and has pointed out the
> > buffer overflow problem related to safety -- that's an obvious queue
> > my "better string library":
> >
> > http://bstring.sourceforge.net/
> >
> > The point of the bstring library, especially in comparison to the
> > numerous other string libraries out there, is that its high
> > performance, it carries absolutely no extra baggage with it, while
> > remaining totally interoperable with the char * buffer style strings.[/color]
>
> There is no buffer overflow problem in the C++ standard library and
> std::string is also interoperable with char *.[/color]

I have it on good authority that std::string is slow, lacking in
features and has been happily replaced by my CBString library in at
least one instance. I am not a C++ expert, so I don't know the
details, but apparently my CBString is a necessary and valuable
replacement for MFC's CString (most notably, because my library is
portable to something outside of MFC) which itself is a well motivated
replacement for std::string. I don't know the technical details as to
what is really wrong with std::string, but apparently its just not
acceptable.
[color=blue][color=green]
> > As to his comment about GC, I have thought about it, but I can't think
> > of a way to implement it properly with high performance *and* support
> > the typical malloc/free paradigm at the same time.[/color]
>
> Check .NET. It has interesting GC mechanisms.[/color]

..NET's primary assumption is the existences of the CLI platform. This
allows them to make certain assumptions about all memory utilization
which cannot be made in more ordinary native C/C++ implementations .
[color=blue][color=green]
> > Even if you could
> > make it work, the fact that C/C++ still cannot *guarantee* prevention
> > of buffer overflows leading to undefined behavior, add a GC background
> > thread and this is likely to manifest itself in programing errors that
> > are *truly* impossible to debug.[/color]
>
> C & C++ are different languages. In C++ code you can guarantee buffer
> overflow protection by using the standard library facilities.[/color]

Yes, I know, if you look at my bstrlib library above you will see that
I have done exactly this. But in the end both languages still rely on
programmer competence to avoid buffer overflows. Don't get trapped
into the same nonsense that the C people have fallen into by simply
saying that spec *ALLOWS* for safe implementations -- that's
ridiculous. I am concerned with *real world* safety, not theoretical
safety.

Security flaw and just software instability in general comes from this
inattention to real world safety issues, and the features of C++ do
not guarantee any such way
[color=blue]
> [...] I suggest you
> read "The C++ Programming Language" 3rd Edition or Special Edition by Bjarne
> Stroustrup (the creator of C++), *cover to cover*.[/color]

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.

--
Paul Hsieh

http://www.pobox.com/~qed/

http://bstring.sourceforge.net/

[Paul Hsieh]

Re: D

"Mirek Fidler" <cxl@volny.cz > wrote in message news:<bejbd4$5p g08$1@ID-198693.news.dfn cis.de>...[color=blue][color=green]
> > The point of the bstring library, especially in comparison to the
> > numerous other string libraries out there, is that its high
> > performance, it carries absolutely no extra baggage with it, while
> > remaining totally interoperable with the char * buffer style strings.
> > It brings up the functionality level to nearly that of Python/Perl
> > (though I'm obviously missing regex's) with no dramatic compromises.[/color]
>
> Is there anything that makes bstring superior to usual C++
> interface/implementation, like std::string ?[/color]

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.

--
Paul Hsieh

http://www.pobox.com/~qed/

http://bstring.sourceforge.net/

[Ioannis Vranos]

Re: D

"Paul Hsieh" <qed@pobox.co m> wrote in message
news:796f488f.0 307101501.6013e dff@posting.goo gle.com...[color=blue]
>[color=green]
> > [...] I suggest you
> > read "The C++ Programming Language" 3rd Edition or Special Edition by[/color][/color]
Bjarne[color=blue][color=green]
> > Stroustrup (the creator of C++), *cover to cover*.[/color]
>
> 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.[/color]


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>::s ize_type i=0; i<vec.size(); ++i)
// do whatever with vec[i];


// 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]

Re: D

In article <796f488f.03070 91835.3c541889@ posting.google. com>,
qed@pobox.com says...[color=blue]
> 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.[/color]

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.
[color=blue]
> *I* want features, more safety, and I want a heck of a lot more
> performance than C gives me![/color]

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.
[color=blue]
> And why am I resorting to inline assembly any time I want real
> performance out of my state of the art C compiler?[/color]

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.
[color=blue]
> 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 ...[/color]

Because you never started building your own library of ADTs, or
didn't want to obtain one elsewhere? I can't read your mind.
[color=blue]
> 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.[/color]

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.


--
Randy Howard
remove the obvious bits from my address to reply.

[Kevin Easton]

Re: D

In comp.lang.c Randy Howard <randy.howard@f oomegapathdslba r.net> wrote:[color=blue]
> In article <796f488f.03070 91835.3c541889@ posting.google. com>,
> qed@pobox.com says...[/color]
[...][color=blue][color=green]
>> *I* want features, more safety, and I want a heck of a lot more
>> performance than C gives me![/color]
>
> 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.[/color]

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]

Re: D

qed@pobox.com (Paul Hsieh) writes:
[color=blue]
> "Mirek Fidler" <cxl@volny.cz > wrote in message
> news:<bejipi$59 hrr$1@ID-198693.news.dfn cis.de>...[color=green][color=darkred]
> > > *I* want features, more safety, and I want a heck of a lot more
> > > performance than C gives me! The thing is, there is no *technical*[/color]
> >
> > May I ask you a humble question why you are not using C++ instead ?
> > I agree there is no technical reason and that is what C++ is about....[/color]
>
> 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.[/color]

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

regards
frank

--
Frank Schmitt
4SC AG phone: +49 89 700763-0
e-mail: frank DOT schmitt AT 4sc DOT com

[Wolfgang Riedel]

Re: D

Paul Hsieh wrote:[color=blue]
>
> "Mirek Fidler" <cxl@volny.cz > wrote in message news:<bejipi$59 hrr$1@ID-198693.news.dfn cis.de>...[color=green][color=darkred]
> > > *I* want features, more safety, and I want a heck of a lot more
> > > performance than C gives me! The thing is, there is no *technical*[/color]
> >
> > May I ask you a humble question why you are not using C++ instead ?
> > I agree there is no technical reason and that is what C++ is about....[/color]
>
> 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.
>
> --
> Paul Hsieh
> http://www.pobox.com/~qed/
> http://bstring.sourceforge.net/[/color]

use PL/1

Wolfgang

[Mirek Fidler]

Re: D

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

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.
[color=blue]
> 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),[/color]

OTOH, I agree that most of above issues are missing both from C and
C++.
[color=blue]
> 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),[/color]

Yeah. That is what C++ and templates are about too.
[color=blue]
> a way to debug and manipulate the memory heap,
> completely abstracted stream I/O and so on.[/color]

Library stuff.
[color=blue]
> I don't just want more features, I want features that from the lessons
> that *I* have learned.[/color]

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]

Re: D

[color=blue]
> 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[/color]

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]

Re: D

In article <796f488f.03071 01347.5ce51276@ posting.google. com>,
Paul Hsieh <qed@pobox.co m> wrote:[color=blue]
>I'm not as familliar with C++, and, its feature set is not really what
>I want.[/color]

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++.
[color=blue]
>C++ also has absolutely no opportunity to be any faster than
>C.[/color]

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.
[color=blue]
>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.[/color]

This is confusing, because C has some of these same problems.
[color=blue]
>I don't just want more features, I want features that from the lessons
>that *I* have learned.[/color]

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.
--
Greg Comeau/ 4.3.0.1: FULL CORE LANGUAGE, INCLUDING TC1
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Thomas Stegen]

Re: D

Ioannis Vranos wrote:
[color=blue]
>
>
> 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. :-)[/color]

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.
"What is the future c existence which does not do in all languages"

[Thomas Stegen]

Re: D

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.

--
Thomas.
"What is the future c existence which does not do in all languages"