Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: C Style Strings

Reply
Thread Tools

Re: C Style Strings

 
 
Chris Smith
Guest
Posts: n/a
 
      06-02-2006
kwikius <(E-Mail Removed)> wrote:
> In C it seems that it is possible to do better though
> there seems to be no standard higher level string library. Maybe there
> are plans to address this situation in the next version of the C
> standard?


One very big difference between C and some other languages (say, Java
and C# and VB, for example) is that there is no big organization that's
got billions of dollars invested in making C the next Big Thing. As a
result, the language is not as large or complex, and far more stable,
than some of these other languages. I doubt you'll see future versions
of C making really huge changes in the language or APIs to conform with
higher-level programming goals. After all, if you wanted this you
wouldn't use C, and the standards organization doesn't particularly care
if you use C or not.

Short answer: probably not.

--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
 
Reply With Quote
 
 
 
 
kwikius
Guest
Posts: n/a
 
      06-02-2006
santosh wrote:
> kwikius wrote:
> ... snip ...
>
> > The code in the post attempts to highlight the different problems of
> > dealing with resource management in both languages. Having to deal
> > manually with resources and having to check results of functions for
> > validity are both sources of additional code complexity in C it seems.
> > Maybe there are plans to address this situation in the next version of
> > the C standard?

>
> I guess you want garbage collection and exceptions support. Both impose
> run-time overhead. Increasingly, C is used in embedded programming
> where both might be unfeasible and unnecessary. I don't think there is
> much chance that they will be standardised.


Yes. C++ claims to be as useable as C in embedded systems, but I have
heard that use of exceptions rather than error codes causes problems.
There is a marginal effect on performance but AFAIK the larger problems
are due to the latency involved in unwinding the stack as well as
apparently extra memory use for the exception handling code. I guess
that the different style of error handling also causes major problems
with integration. There is probably also an element of sticking with
the way things have always been done. AFAIK Most compilers can turn
off exceptions, though I think this is non-standard even in the
so-called free-standing c++ implementations.

> Third-party garbage collectors are available for C. But if you really
> want these features built into the langauge, maybe you should consider
> Java?


I kind of like Java Swing.

> > If I have given incorect advice, I apologise. FWIW I certainly dont
> > advocate use of malloc or C-style strings or manual memory management.

>
> Good for you.
>
> > IOW I advocate use of C++ over C. C holds no advantage whatever.

>
> It depends on what you're trying to do. Sweeping generalisations aren't
> correct.


Actually after posting I am pretty sure that the C code will be faster.
Creating a C++ string probably involves an allocation. The C++ string
concat operator(+) may also involve an allocation,whereas the C code
only has one allocation. That is the downside of automated resource
management.

> > The concat function shows very neatly why it is best to avoid C-style
> > strings in C++.

>
> Indeed. If you decide to program in C++, then you should program in
> C++.


Well I like other languages too. I like the platform independent spirit
of Java and its GUI support, but I guess I would miss C++.

regrads
Andy Little

 
Reply With Quote
 
 
 
 
websnarf@gmail.com
Guest
Posts: n/a
 
      06-02-2006
kwikius wrote:
> Martin Ambuhl wrote:
> > kwikius wrote:
> > > #include <malloc.h>

> > This is neither a C header nor a C++ header, so off-topic in both groups
> > to which you posted.

>
> Ok.
>
> > > #include <cstring>

> > This is not a C header, so off-topic in one of the groups to which you
> > posted.

>
> Ok.
>
> > If you _must_ post to both <news:comp.lang.c++> and <news:comp.lang.c>,
> > try to make your post topical in each. As it stands, your post is
> > topical in neither.


These guys are real great at keeping the snow out of their cave, even
if they don't realize that its part of an avalanche on top of them.

> The code in the post attempts to highlight the different problems of
> dealing with resource management in both languages. Having to deal
> manually with resources and having to check results of functions for
> validity are both sources of additional code complexity in C it seems.
> Maybe there are plans to address this situation in the next version of
> the C standard?


The C standard is not something where people try to actually address
actual real world problems. You can look at their own manifesto --
they claim to "endorse standard practice" and things along those lines.
So in a sense they *endorse* all the problems with the C language, so
long as it is standard practice. Hence the continuing presence of
"gets" in the library.

C++ obviously goes a long way to addressing resources and error
handling in a useful way (RAII and real exception handling) however it
is not a garbage collecting language and thus it will always take a
little more effort to program in it properly. And of course C leaves
the whole concept of construction and destruction up to the programmer.

> > There is hardly ever any excuse for posting to both newsgroups; these
> > are concerned with two different languages, and advice given in posts to
> > both is almost certainly going to be wrong, or at least non-idiomatic,
> > in at least one of them.

>
> If I have given incorect advice, I apologise. FWIW I certainly dont
> advocate use of malloc or C-style strings or manual memory management.
> IOW I advocate use of C++ over C. C holds no advantage whatever.


Well hang on -- this is precisely where you can make an argument for C
over C++. In C since you are forced to do everything by hand, you have
the advantage of being able to do everything by hand. For example, you
use local stack based memory to back certain allocations if you know
that the lifetime of the resource is equal to the lifetime of the
function call. In C++ you can hope your compiler can figure it out; if
not it will use new/delete which eventually falls back to malloc/free
which is hundreds of times slower.

> [...] The
> concat function shows very neatly why it is best to avoid C-style
> strings in C++. In C it seems that it is possible to do better though
> there seems to be no standard higher level string library. Maybe there
> are plans to address this situation in the next version of the C
> standard?


Take a look at http://bstring.sf.net/ . I claim that even just the C
API is generally better than C++'s std::string, or Microsoft's CString
classes. But it includes a C++ API as well which should make everyone
happy.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      06-02-2006

http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

> C++ obviously goes a long way to addressing resources and error
> handling in a useful way (RAII and real exception handling) however it
> is not a garbage collecting language and thus it will always take a
> little more effort to program in it properly.


RAII is not possible in a garbage collected language. Garbage
collection can, in many real world cases, add more complexity than it
is meant to solve.

> Well hang on -- this is precisely where you can make an argument for C
> over C++. In C since you are forced to do everything by hand, you have
> the advantage of being able to do everything by hand. For example, you
> use local stack based memory to back certain allocations if you know
> that the lifetime of the resource is equal to the lifetime of the
> function call. In C++ you can hope your compiler can figure it out; if
> not it will use new/delete which eventually falls back to malloc/free
> which is hundreds of times slower.


That statement about C++ is simply incorrect; I can't even imagine
where it is coming from.

 
Reply With Quote
 
Andrew Poelstra
Guest
Posts: n/a
 
      06-02-2006
On 2006-06-02, Noah Roberts <(E-Mail Removed)> wrote:
>
> (E-Mail Removed) wrote:
>> Well hang on -- this is precisely where you can make an argument for C
>> over C++. In C since you are forced to do everything by hand, you have
>> the advantage of being able to do everything by hand. For example, you
>> use local stack based memory to back certain allocations if you know
>> that the lifetime of the resource is equal to the lifetime of the
>> function call. In C++ you can hope your compiler can figure it out; if
>> not it will use new/delete which eventually falls back to malloc/free
>> which is hundreds of times slower.

>
> That statement about C++ is simply incorrect; I can't even imagine
> where it is coming from.
>


I imagine that it comes from a basic understanding of stack-based memory.

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
You can lead a blind man to water but you can't make him chug it.
 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      06-02-2006

Andrew Poelstra wrote:
> On 2006-06-02, Noah Roberts <(E-Mail Removed)> wrote:
> >
> > (E-Mail Removed) wrote:
> >> Well hang on -- this is precisely where you can make an argument for C
> >> over C++. In C since you are forced to do everything by hand, you have
> >> the advantage of being able to do everything by hand. For example, you
> >> use local stack based memory to back certain allocations if you know
> >> that the lifetime of the resource is equal to the lifetime of the
> >> function call. In C++ you can hope your compiler can figure it out; if
> >> not it will use new/delete which eventually falls back to malloc/free
> >> which is hundreds of times slower.

> >
> > That statement about C++ is simply incorrect; I can't even imagine
> > where it is coming from.
> >

>
> I imagine that it comes from a basic understanding of stack-based memory.


How do you figure?

 
Reply With Quote
 
Andrew Poelstra
Guest
Posts: n/a
 
      06-02-2006
On 2006-06-02, Noah Roberts <(E-Mail Removed)> wrote:
>
> Andrew Poelstra wrote:
>> On 2006-06-02, Noah Roberts <(E-Mail Removed)> wrote:
>> >
>> > (E-Mail Removed) wrote:
>> >> Well hang on -- this is precisely where you can make an argument for C
>> >> over C++. In C since you are forced to do everything by hand, you have
>> >> the advantage of being able to do everything by hand. For example, you
>> >> use local stack based memory to back certain allocations if you know
>> >> that the lifetime of the resource is equal to the lifetime of the
>> >> function call. In C++ you can hope your compiler can figure it out; if
>> >> not it will use new/delete which eventually falls back to malloc/free
>> >> which is hundreds of times slower.
>> >
>> > That statement about C++ is simply incorrect; I can't even imagine
>> > where it is coming from.
>> >

>>
>> I imagine that it comes from a basic understanding of stack-based memory.

>
> How do you figure?
>


If you have stack-based memory, any memory allocated will be deallocated
by the hardware by definition when the memory is popped.

Without stack-based memory, malloc() and free() must be called (on a lower
level than C++ lets you see), which invokes the OS to manage freeing memory
and managing it.

Obviously, deallocating memory as a side effect of simply popping a stack is
many times faster than calling a function and letting the OS sort it out.

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
You can lead a blind man to water but you can't make him chug it.
 
Reply With Quote
 
Chris Smith
Guest
Posts: n/a
 
      06-02-2006
Andrew Poelstra <(E-Mail Removed)> wrote:
> On 2006-06-02, Noah Roberts <(E-Mail Removed)> wrote:
> >
> > (E-Mail Removed) wrote:
> >> function call. In C++ you can hope your compiler can figure it out; if
> >> not it will use new/delete which eventually falls back to malloc/free
> >> which is hundreds of times slower.

> >
> > That statement about C++ is simply incorrect; I can't even imagine
> > where it is coming from.
> >

>
> I imagine that it comes from a basic understanding of stack-based memory.


I don't believe the complaint was about stack memory. It was about the
incorrect statement regarding C++. The same statement may be considered
valid concerning Java, C#, VB, or C++/CLI, for example; but those are
different languages from C++. (The word "valid" should be taken lightly
there; I haven't verified the hundreds of times.)

C++ perfectly well allows programmers to allocate any "objects" (not
quite, really, since they don't own their identity so they are a sort of
2/3-object... but in C++ vocab they are objects) on the stack, with all
the accompanying performance benefits.

--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      06-02-2006

Chris Smith wrote:
> Andrew Poelstra <(E-Mail Removed)> wrote:
> > On 2006-06-02, Noah Roberts <(E-Mail Removed)> wrote:
> > >
> > > (E-Mail Removed) wrote:
> > >> function call. In C++ you can hope your compiler can figure it out; if
> > >> not it will use new/delete which eventually falls back to malloc/free
> > >> which is hundreds of times slower.
> > >
> > > That statement about C++ is simply incorrect; I can't even imagine
> > > where it is coming from.
> > >

> >
> > I imagine that it comes from a basic understanding of stack-based memory.

>
> I don't believe the complaint was about stack memory. It was about the
> incorrect statement regarding C++. The same statement may be considered
> valid concerning Java, C#, VB, or C++/CLI, for example; but those are
> different languages from C++. (The word "valid" should be taken lightly
> there; I haven't verified the hundreds of times.)
>
> C++ perfectly well allows programmers to allocate any "objects" (not
> quite, really, since they don't own their identity so they are a sort of
> 2/3-object... but in C++ vocab they are objects) on the stack, with all
> the accompanying performance benefits.


Yes, that is what I was talking about. C++ and C do not differ in the
way it was being stated.

 
Reply With Quote
 
Tomás
Guest
Posts: n/a
 
      06-03-2006
Malcolm posted:


> If we want we can do a speed-up
>
> void fastconcat(char *out, char *str1, char *str2)
> {
> while(*str1)
> *out++ = *str1++;
> while(*str2)
> *out++ = *str2++;
> *out = 0;
> }



I'd say that has the potential to "run slower" than a version which uses
strcpy. A system would be more efficient copying int's than char's, so
strcpy could be implemented platform-specifically as something like:

(Unchecked code

inline bool NoByteZero(unsigned const v)
{
return ( ( (v & 0x7F7F7F7F) + 0x7F7F7F7F ) | v ) | 0x7F7F7F7F;
}

void strcpy(char *pdest, const char *psource)
{
int *idest = reinterpret_cast<int*>(pdest);
int *isource = reinterpret_cast<int*>(psource);

for ( ; NoByteZero(*isource); *idest++ = *isource++);

char *cdest = reinterpret_cast<char*>(idest);
char *csource = reinterpret_cast<char*>(isource);

while( *cdest++ = *csource++ );
}

(This code makes the presumption that on the given platform, it's okay to
access memory which isn't yours.)


-Tomás
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Strings, Strings and Damned Strings Ben C Programming 14 06-24-2006 05:09 AM
Why do so many new style ansi streams and files etc, still use old style strings? Kza C++ 4 03-03-2006 07:00 PM
Catching std::strings and c-style strings at once Kurt Krueckeberg C++ 2 11-17-2004 03:53 AM
Need help with Style conversion from Style object to Style key/value collection. Ken Varn ASP .Net Building Controls 0 04-26-2004 07:06 PM
Comparing strings from within strings Rick C Programming 3 10-21-2003 09:10 AM



Advertisments