Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > c-style string vs std::string

Reply
Thread Tools

c-style string vs std::string

 
 
Balog Pal
Guest
Posts: n/a
 
      09-17-2011

"Christopher" <(E-Mail Removed)>
>I am growing really tired of having to decypher 1000 functions that
> were written to do simple operations on c-style strings that I could
> do in 50 lines with streams and std::strings. My peer uses that same
> old ,"Its more efficient " argument that I always hear. In fact, that
> argument has grown into ,"we shouldn't use any of the STL containers,
> because they allocate, which is expensive."
>
> For example, I had to debug through 1500 lines today, that simply
> replaced a token in a char * with another char *, because everything
> to search for the token, convert characters to digits, check for
> digits or alpha characters, shift things to make room, replace
> elements, etc was all manually written. I could have done this easily
> with a find and replace call from the STL .
>
> Well, I am tired of it. I want to write a test and profile it. One
> operation at a time. I am sure the differences are negligable,
> especially when wieghing in the maintainability of the code.


Tired of bullshit? So quit and find a proper place to work, one that aligns
with your values.

There is no point wasting time on experiments or "proof" or anything -- a
shop with the described mentality is way beyond repair.

> Before I start spending time to disprove what hasn't even been proven,
> I want to check if anyone has had to do this and has preexisiting
> code? Or if anyone knows a reliable resource where I can get some,
> instead of writing it from scratch? Also, any advice on how to write
> such a test without having any points in it that could void the
> results would be useful.


I don't get your questions. You have the baseline. You have alternative in
your head. So cde the alternative version, run the unit tests to prove the
behavior is the same, then measure the peroformance -- or rather make the
opposition measure it for you proving the "inefficiency".

 
Reply With Quote
 
 
 
 
Ebenezer
Guest
Posts: n/a
 
      09-18-2011
On Sep 17, 11:43*am, Noah Roberts <(E-Mail Removed)> wrote:
> On Sep 16, 3:07*pm, Christopher <(E-Mail Removed)> wrote:
>
>
>
>
>
>
>
>
>
> > I am growing really tired of having to decypher 1000 functions that
> > were written to do simple operations on c-style strings that I could
> > do in 50 lines with streams and std::strings. My peer uses that same
> > old ,"Its more efficient " argument that I always hear. In fact, that
> > argument has grown into ,"we shouldn't use any of the STL containers,
> > because they allocate, which is expensive."

>
> > For example, I had to debug through 1500 lines today, that simply
> > replaced a token in a char * with another char *, because everything
> > to search for the token, convert characters to digits, check for
> > digits or alpha characters, shift things to make room, replace
> > elements, etc was all manually written. I could have done this easily
> > with a find and replace call from the STL .

>
> > Well, I am tired of it. I want to write a test and profile it. One
> > operation at a time. I am sure the differences are negligable,
> > especially when wieghing in the maintainability of the code.

>
> > Before I start spending time to disprove what hasn't even been proven,
> > I want to check if anyone has had to do this and has preexisiting
> > code? Or if anyone knows a reliable resource where I can get some,
> > instead of writing it from scratch? Also, any advice on how to write
> > such a test without having any points in it that could void the
> > results would be useful.

>
> Is he against use of malloc too? *The C guy I work with is and it's
> making it really hard/interesting to do my job.
>
> I think you may eventually find that people don't listen to logic or
> reason. *People make decisions and then come up with reasons to
> support them. *Then they trick themselves into thinking that they used
> those reasons to make the decision they made. *This is why no matter
> how reasonable an argument you make, you simply cannot convince people
> to your side most the time...and why you can't be convinced most the
> time too.
>
> If you really want to change their mind you'll have to use Jedi Mind
> Tricks. *Get some books or psychology, influence, and manipulation.
>
> One important thing you can do to help your side is "understand" their
> side. *Unless you do this, most people will simply stick to their guns
> harder and harder thinking you haven't listened to them. *Act like
> you've listened, like you're almost convinced, and then, "but...."
> Three things this does...it helps you actually listen to what they're
> saying because the best way to pretend that you have is to actually do
> so. *Next, it breaks down their defenses and lets them know that
> you're taking their opinion seriously--this is important to you, no?
> Finally, it creates a cooperation feedback in their brain; you've done
> them a 'favor' and now they need to return it by listening to your
> side.
>
> Sometimes you've got to give in to them a bit to get something you
> want more.
>
> The thing is, you've got to work with them, wrong as they are, right?
> Don't spend the time fighting. *Get what you can, run with it, and
> prove yourself. *If you fight all the time you'll have to fight all
> the time and it becomes a miserable place to work. *The small bit of
> frustration and hit to your pride that being forced to write shitty
> code sometimes causes is simply not worth that. *If you can't beat
> them, join them...


If you can't join 'em, beat 'em. Remember the Alamo.
Those people died fighting for what was right.


Brian Wood
Ebenezer Enterprises
http://webEbenezer.net



> just keep mentioning it every time it comes up, "You
> know...if we used strings here, maybe it would take a few extra
> microseconds, but we wouldn't have run into this bug."
>
> Every so often you need to step past someone. *Use this sparingly
> though because nobody likes it.
>
> As to your original problem...had the same issue with someone myself
> and I did compare std::string to char*. *You'll never get the same
> speed out of std::string that you can with a "speed focused" char*
> function. *You'll be slower by a few nanoseconds every time. *The
> std::string construct simply does more. *So, you're opponent is right
> and it should be easy to give that to them to show you "understand"
> their side. *You will, however, run into the worse kind of bugs when
> that char* function goes kaboom. *They're harder to work with,
> impractical to protect, etc...


 
Reply With Quote
 
 
 
 
Ebenezer
Guest
Posts: n/a
 
      09-18-2011
On Sep 17, 11:43*am, Noah Roberts <(E-Mail Removed)> wrote:
> On Sep 16, 3:07*pm, Christopher <(E-Mail Removed)> wrote:
>
>
>
>
>
>
>
>
>
> > I am growing really tired of having to decypher 1000 functions that
> > were written to do simple operations on c-style strings that I could
> > do in 50 lines with streams and std::strings. My peer uses that same
> > old ,"Its more efficient " argument that I always hear. In fact, that
> > argument has grown into ,"we shouldn't use any of the STL containers,
> > because they allocate, which is expensive."

>
> > For example, I had to debug through 1500 lines today, that simply
> > replaced a token in a char * with another char *, because everything
> > to search for the token, convert characters to digits, check for
> > digits or alpha characters, shift things to make room, replace
> > elements, etc was all manually written. I could have done this easily
> > with a find and replace call from the STL .

>
> > Well, I am tired of it. I want to write a test and profile it. One
> > operation at a time. I am sure the differences are negligable,
> > especially when wieghing in the maintainability of the code.

>
> > Before I start spending time to disprove what hasn't even been proven,
> > I want to check if anyone has had to do this and has preexisiting
> > code? Or if anyone knows a reliable resource where I can get some,
> > instead of writing it from scratch? Also, any advice on how to write
> > such a test without having any points in it that could void the
> > results would be useful.

>
> Is he against use of malloc too? *The C guy I work with is and it's
> making it really hard/interesting to do my job.
>
> I think you may eventually find that people don't listen to logic or
> reason. *People make decisions and then come up with reasons to
> support them. *Then they trick themselves into thinking that they used
> those reasons to make the decision they made. *This is why no matter
> how reasonable an argument you make, you simply cannot convince people
> to your side most the time...and why you can't be convinced most the
> time too.
>
> If you really want to change their mind you'll have to use Jedi Mind
> Tricks. *Get some books or psychology, influence, and manipulation.
>
> One important thing you can do to help your side is "understand" their
> side. *Unless you do this, most people will simply stick to their guns
> harder and harder thinking you haven't listened to them. *Act like
> you've listened, like you're almost convinced, and then, "but...."
> Three things this does...it helps you actually listen to what they're
> saying because the best way to pretend that you have is to actually do
> so. *Next, it breaks down their defenses and lets them know that
> you're taking their opinion seriously--this is important to you, no?
> Finally, it creates a cooperation feedback in their brain; you've done
> them a 'favor' and now they need to return it by listening to your
> side.
>
> Sometimes you've got to give in to them a bit to get something you
> want more.
>
> The thing is, you've got to work with them, wrong as they are, right?
> Don't spend the time fighting. *Get what you can, run with it, and
> prove yourself. *If you fight all the time you'll have to fight all
> the time and it becomes a miserable place to work. *The small bit of
> frustration and hit to your pride that being forced to write shitty
> code sometimes causes is simply not worth that. *If you can't beat
> them, join them...


Sometimes you have to stand and fight like they did at
the Alamo. If you can't join 'em, beat 'em.
I would appreciate it if people would watch their mouths
here.


Brian Wood
Ebenezer Enterprises
http://webEbenezer.net
 
Reply With Quote
 
Gerald Breuer
Guest
Posts: n/a
 
      09-18-2011
Am 17.09.2011 00:07, schrieb Christopher:

> I am growing really tired of having to decypher 1000 functions that
> were written to do simple operations on c-style strings that I could
> do in 50 lines with streams and std::strings. My peer uses that same
> old ,"Its more efficient " argument that I always hear. In fact, that
> argument has grown into ,"we shouldn't use any of the STL containers,
> because they allocate, which is expensive."


That's not a question which should be answered in principle but related
to the actual problem. Bloat is only bloat if a real resouce-problem
araises from this "bloat".
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      09-18-2011
On Sun, 2011-09-18, Ebenezer wrote:
> On Sep 17, 11:43*am, Noah Roberts <(E-Mail Removed)> wrote:

....
[snip good stuff]

>> The thing is, you've got to work with them, wrong as they are, right?
>> Don't spend the time fighting. *Get what you can, run with it, and
>> prove yourself. *If you fight all the time you'll have to fight all
>> the time and it becomes a miserable place to work. *The small bit of
>> frustration and hit to your pride that being forced to write shitty
>> code sometimes causes is simply not worth that. *If you can't beat
>> them, join them...

>
> If you can't join 'em, beat 'em. Remember the Alamo.
> Those people died fighting for what was right.


What about the people who should have been at the Alamo, but got
themselves killed in a silly bar fight a week before the battle?

Sometimes it's better to give up, even when you know you're right.

(Not always; next week I hope to throw out most of a coworker's code
from the past half year and replace it with something I wrote in a
couple of nights ... Not much he can do about it if (as I suspect) I
can beat the existing code WRT performance and stability.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      09-18-2011
BGB <(E-Mail Removed)> wrote:
> if people know what they are doing, and performance matters some, the
> usual (fairly straightforward) solution is to throw a hash-table at the
> problem (not difficult to implement).


Actually implementing a good hash table is not trivial, for two reasons.

Firstly, the decision of which kind of hash table. Unlike eg. red-black
trees, there are many different possible hash table implementations, and
there's no one single that would be optimal. What type of hash table is
best may actually depend on what kind of data is inserted into it.

Secondly, a naive hashing function may have hidden surprises. It might
seem to work like a charm in all testcases... but then there may be some
pathological input (which is not even necessarily deliberately chosen to
break the hash table, but could be natural input from somewhere) that will
trigger the weakness in the hashing function (which usually presents itself
by the vast majority of the elements ending up in only a fraction of the
hash table positions, in other words, many elements having the same hash
values). This pathological situation might not be discovered in testing,
only when a client somewhere uses it with some unexpected input.

The major inefficiency in std::set and std::map is the memory allocation
that happens with each element. However, this inefficiency can be greatly
alleviated by using a fast memory allocator (which all STL containers
support). Such an allocator can make those containers faster by even an
order of magnitude or so.

Of course using a ready-made implementation of a data container (be it
std::set, std::map or their unordered variants in the new standard) also
reduces the amount of bug-hunting in the program, which is always a great
asset.
 
Reply With Quote
 
Balog Pal
Guest
Posts: n/a
 
      09-18-2011
"Jorgen Grahn" <(E-Mail Removed)>
>
> What about the people who should have been at the Alamo, but got
> themselves killed in a silly bar fight a week before the battle?
>
> Sometimes it's better to give up, even when you know you're right.


#include "the serenity prayer"

> (Not always; next week I hope to throw out most of a coworker's code
> from the past half year and replace it with something I wrote in a
> couple of nights ... Not much he can do about it if (as I suspect) I
> can beat the existing code WRT performance and stability.)



 
Reply With Quote
 
Ebenezer
Guest
Posts: n/a
 
      09-18-2011
On Sep 18, 9:45*am, Jorgen Grahn <(E-Mail Removed)> wrote:
> On Sun, 2011-09-18, Ebenezer wrote:
> > On Sep 17, 11:43*am, Noah Roberts <(E-Mail Removed)> wrote:

>
> ...
> [snip good stuff]
>
> >> The thing is, you've got to work with them, wrong as they are, right?
> >> Don't spend the time fighting. *Get what you can, run with it, and
> >> prove yourself. *If you fight all the time you'll have to fight all
> >> the time and it becomes a miserable place to work. *The small bit of
> >> frustration and hit to your pride that being forced to write shitty
> >> code sometimes causes is simply not worth that. *If you can't beat
> >> them, join them...

>
> > If you can't join 'em, beat 'em. *Remember the Alamo.
> > Those people died fighting for what was right.

>
> What about the people who should have been at the Alamo, but got
> themselves killed in a silly bar fight a week before the battle?
>
> Sometimes it's better to give up, even when you know you're right.
>
> (Not always; next week I hope to throw out most of a coworker's code
> from the past half year and replace it with something I wrote in a
> couple of nights ... Not much he can do about it if (as I suspect) I
> can beat the existing code WRT performance and stability.)
>


I think it would be more tactful to say:

next week I hope to replace most of a coworker's code
from the past half year with something I wrote in a
couple of nights ...

 
Reply With Quote
 
Oliver Jackson
Guest
Posts: n/a
 
      09-19-2011
On Sep 17, 6:29*pm, Ebenezer <(E-Mail Removed)> wrote:
> On Sep 17, 11:43*am, Noah Roberts <(E-Mail Removed)> wrote:
>
>
>
>
>
> > On Sep 16, 3:07*pm, Christopher <(E-Mail Removed)> wrote:

>
> > > I am growing really tired of having to decypher 1000 functions that
> > > were written to do simple operations on c-style strings that I could
> > > do in 50 lines with streams and std::strings. My peer uses that same
> > > old ,"Its more efficient " argument that I always hear. In fact, that
> > > argument has grown into ,"we shouldn't use any of the STL containers,
> > > because they allocate, which is expensive."

>
> > > For example, I had to debug through 1500 lines today, that simply
> > > replaced a token in a char * with another char *, because everything
> > > to search for the token, convert characters to digits, check for
> > > digits or alpha characters, shift things to make room, replace
> > > elements, etc was all manually written. I could have done this easily
> > > with a find and replace call from the STL .

>
> > > Well, I am tired of it. I want to write a test and profile it. One
> > > operation at a time. I am sure the differences are negligable,
> > > especially when wieghing in the maintainability of the code.

>
> > > Before I start spending time to disprove what hasn't even been proven,
> > > I want to check if anyone has had to do this and has preexisiting
> > > code? Or if anyone knows a reliable resource where I can get some,
> > > instead of writing it from scratch? Also, any advice on how to write
> > > such a test without having any points in it that could void the
> > > results would be useful.

>
> > Is he against use of malloc too? *The C guy I work with is and it's
> > making it really hard/interesting to do my job.

>
> > I think you may eventually find that people don't listen to logic or
> > reason. *People make decisions and then come up with reasons to
> > support them. *Then they trick themselves into thinking that they used
> > those reasons to make the decision they made. *This is why no matter
> > how reasonable an argument you make, you simply cannot convince people
> > to your side most the time...and why you can't be convinced most the
> > time too.

>
> > If you really want to change their mind you'll have to use Jedi Mind
> > Tricks. *Get some books or psychology, influence, and manipulation.

>
> > One important thing you can do to help your side is "understand" their
> > side. *Unless you do this, most people will simply stick to their guns
> > harder and harder thinking you haven't listened to them. *Act like
> > you've listened, like you're almost convinced, and then, "but...."
> > Three things this does...it helps you actually listen to what they're
> > saying because the best way to pretend that you have is to actually do
> > so. *Next, it breaks down their defenses and lets them know that
> > you're taking their opinion seriously--this is important to you, no?
> > Finally, it creates a cooperation feedback in their brain; you've done
> > them a 'favor' and now they need to return it by listening to your
> > side.

>
> > Sometimes you've got to give in to them a bit to get something you
> > want more.

>
> > The thing is, you've got to work with them, wrong as they are, right?
> > Don't spend the time fighting. *Get what you can, run with it, and
> > prove yourself. *If you fight all the time you'll have to fight all
> > the time and it becomes a miserable place to work. *The small bit of
> > frustration and hit to your pride that being forced to write shitty
> > code sometimes causes is simply not worth that. *If you can't beat
> > them, join them...

>
> If you can't join 'em, beat 'em. *Remember the Alamo.
> Those people died fighting for what was right.


Whoa. You, like, totally blew my mind with that analogy. That was
almost as good as your Noah's ark metaphor!
http://groups.google.com/group/comp....54d14136415717
 
Reply With Quote
 
James
Guest
Posts: n/a
 
      09-19-2011
On Sep 17, 12:43*pm, Noah Roberts <(E-Mail Removed)> wrote:
>
> I think you may eventually find that people don't listen to logic or
> reason. *People make decisions and then come up with reasons to
> support them. *Then they trick themselves into thinking that they used
> those reasons to make the decision they made. *This is why no matter
> how reasonable an argument you make, you simply cannot convince people
> to your side most the time...and why you can't be convinced most the
> time too.
>


A concise version of the above is my favorite Ben Goldacre quote.

"You cannot reason people out of a position that they did not reason
themselves into."

James
 
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
'System.String[]' from its string representation 'String[] Array' =?Utf-8?B?UmFqZXNoIHNvbmk=?= ASP .Net 0 05-04-2006 04:29 PM
Is "String s = "abc";" equal to "String s = new String("abc");"? Bruce Sam Java 15 11-19-2004 06:03 PM
String[] files = {"a.doc, b.doc"}; VERSUS String[] files = new String[] {"a.doc, b.doc"}; Matt Java 3 09-17-2004 10:28 PM
String.replaceAll(String regex, String replacement) question Mladen Adamovic Java 3 12-05-2003 04:20 PM
Re: String.replaceAll(String regex, String replacement) question Mladen Adamovic Java 0 12-04-2003 04:40 PM



Advertisments