Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #10205 > unrolled thread

c-style string vs std::string

Back to article view | Back to comp.lang.c++

Contents

  c-style string vs std::string Christopher <cpisz@austin.rr.com> - 2011-09-16 15:07 -0700
    Re: c-style string vs std::string Ian Collins <ian-news@hotmail.com> - 2011-09-17 10:19 +1200
      Re: c-style string vs std::string Christopher <cpisz@austin.rr.com> - 2011-09-16 15:32 -0700
    Re: c-style string vs std::string Juha Nieminen <nospam@thanks.invalid> - 2011-09-17 06:27 +0000
      Re: c-style string vs std::string Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-17 02:31 -0500
        Re: c-style string vs std::string BGB <cr88192@hotmail.com> - 2011-09-17 09:03 -0700
      Re: c-style string vs std::string Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-17 14:02 +0000
        Re: c-style string vs std::string BGB <cr88192@hotmail.com> - 2011-09-17 08:13 -0700
          Re: c-style string vs std::string Juha Nieminen <nospam@thanks.invalid> - 2011-09-18 15:17 +0000
            Re: c-style string vs std::string BGB <cr88192@hotmail.com> - 2011-09-19 17:44 -0700
    Re: c-style string vs std::string Krice <paulkp@mbnet.fi> - 2011-09-17 00:56 -0700
    Re: c-style string vs std::string Goran <goran.pusic@gmail.com> - 2011-09-17 04:07 -0700
    Re: c-style string vs std::string Noah Roberts <roberts.noah@gmail.com> - 2011-09-17 09:43 -0700
      Re: c-style string vs std::string Ebenezer <woodbrian77@gmail.com> - 2011-09-17 18:53 -0700
      Re: c-style string vs std::string Ebenezer <woodbrian77@gmail.com> - 2011-09-17 18:29 -0700
        Re: c-style string vs std::string Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-18 14:45 +0000
          Re: c-style string vs std::string "Balog Pal" <pasa@lib.hu> - 2011-09-18 18:22 +0200
          Re: c-style string vs std::string Ebenezer <woodbrian77@gmail.com> - 2011-09-18 10:09 -0700
        Re: c-style string vs std::string Oliver Jackson <chexmofo@hotmail.com> - 2011-09-19 00:04 -0700
      Re: c-style string vs std::string James <2johnsons@oh.rr.com> - 2011-09-19 04:20 -0700
    Re: c-style string vs std::string "Balog Pal" <pasa@lib.hu> - 2011-09-17 22:46 +0200
    Re: c-style string vs std::string Gerald Breuer <Gerald.Breuer@Use-Author-Supplied-Address.invalid> - 2011-09-18 05:17 +0200

Page 1 of 2  [1] 2  Next page →

#10205 — c-style string vs std::string

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.

[toc] | [next] | [standalone]

#10206

On 09/17/11 10:07 AM, Christopher 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.

Assuming giving your peer a slap isn't an option, why don't you use your 
existing code?  Provide alternatives to the C code and compare the two. 
  That should be more convincing than an artificial benchmark.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#10208

On Sep 16, 5:19 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 09/17/11 10:07 AM, Christopher 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.
>
> Assuming giving your peer a slap isn't an option, why don't you use your
> existing code?  Provide alternatives to the C code and compare the two.
>   That should be more convincing than an artificial benchmark.
>
> --
> Ian Collins- Hide quoted text -
>
> - Show quoted text -

Lots of dependencies and I have to do it on my own time at home, where
I won't have access to the dependencies.
I suppose I can do the same idea though and use some sort of proxies.
I'll try that route.

[toc] | [prev] | [next] | [standalone]

#10214

Christopher <cpisz@austin.rr.com> 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.

  The efficiency depends on a lot of things.

  For example, if you only use static arrays of type char as your strings
(which are thus always allocated on the stack and never change size), then
they will be faster than using std::string (which will always allocate
memory on the heap).

  The same is true for class members. Certainly "class A { char str[30]; };"
will be significantly more efficient than "class A { std::string std; };"
with a constructor that sets the 'str' to be of size 30 (the class in
question will be faster to instantiate, copy and destroy).

  Of course even then it depends on how much those strings are being
allocated and destroyed. If this happens very rarely, then the difference
becomes negligible.

  If the C strings are being allocated, resized and freed constantly, then
it becomes more complicated. It depends on how and how much, and what kind
of operations are being applied to them, etc...

  If the difference is small or even negligible, then the modularity and
safety provided by std::string becomes a crucial factor. This will not only
reduce the amount of bugs, but in many cases it will make the code shorter,
simpler and easier to understand.

> In fact, that
> argument has grown into ,"we shouldn't use any of the STL containers,
> because they allocate, which is expensive."

  And what exactly is the proposed alternative?

[toc] | [prev] | [next] | [standalone]

#10216

Juha Nieminen <nospam@thanks.invalid> wrote in
news:4e743dce$0$4357$7b1e8fa0@news.nbl.fi: 

>   The efficiency depends on a lot of things.

Fully agreed.

>   For example, if you only use static arrays of type char as your
>   strings 
> (which are thus always allocated on the stack and never change size),
> then they will be faster than using std::string (which will always
> allocate memory on the heap).

This is not quite exact. The std::string implementation can use small 
string optimization technique which means that there would be no heap 
allocations for strings up to certain length (e.g. 16 bytes). 

A proponent of C recently posted a benchmark test in a thread here 
("Generally, are the programs written by C++ slower than written by C 
10%") where he inadvertently used too small strings so that the C++ 
version was more than twice faster (with VC++2010) than the equivalent C 
code based on malloc/free, presumably because of the small string 
optimization. 

This all depends very much on the compiler and optimization levels of 
course.

Cheers
Paavo

[toc] | [prev] | [next] | [standalone]

#10226

On 9/17/2011 12:31 AM, Paavo Helde wrote:
> Juha Nieminen<nospam@thanks.invalid>  wrote in
> news:4e743dce$0$4357$7b1e8fa0@news.nbl.fi:
>
>>    The efficiency depends on a lot of things.
>
> Fully agreed.
>

yep.


>>    For example, if you only use static arrays of type char as your
>>    strings
>> (which are thus always allocated on the stack and never change size),
>> then they will be faster than using std::string (which will always
>> allocate memory on the heap).
>
> This is not quite exact. The std::string implementation can use small
> string optimization technique which means that there would be no heap
> allocations for strings up to certain length (e.g. 16 bytes).
>

IIRC, it is 12-bytes in MSVC, but I could be wrong here.


in C, a typical "default" array size is like 256 chars or so (may be 
larger or smaller, generally needing to be the "largest reasonably 
expected value").

many people also use special constants, such as MAX_PATH (260), 
depending on what is being done.

another trick is to allocate a smaller fixed-size buffer, and if a 
larger one is needed, then to allocate a larger temporary buffer on the 
heap (this way one can use, say, 64 chars, and still be able to handle 
anything larger which comes along).


> A proponent of C recently posted a benchmark test in a thread here
> ("Generally, are the programs written by C++ slower than written by C
> 10%") where he inadvertently used too small strings so that the C++
> version was more than twice faster (with VC++2010) than the equivalent C
> code based on malloc/free, presumably because of the small string
> optimization.
>

IMHO, string creation/management via malloc/free is evil on multiple levels:
it is slow;
it is rather awkward (one has to remember to free them, ...);
it tends to chew through huge amounts of memory (many malloc 
implementations tend to fall on their face with lots of tiny allocations);
it invokes the problem that malloc/free + multiple DLLs = blows up in 
ones face (MSVC defaults to static linking the C runtime library, so 
each DLL has its own heap);
...

in C++, std::string is generally a much better option.


for a pure C solution, another option is essentially to regard plain 
strings as immutable atomic datums, and then make use of interning 
(where the strings are stored in strings-tables or similar, and the 
pointer to them is treated as their value).

interning strings can be made reasonably fast, and does not burden the 
other code with manually managing strings.

a theoretical issue is that lots of large and/or one-off strings would 
end up interned and eating lots of memory, but IME this hasn't really 
been much of an issue (especially if one uses a GC and a weak hash).

in many common cases, strings values tend to be very repetitive.


note that "buffered strings" / "character buffers" are essentially a 
different use-case, and are generally handled independently in such cases.

in this case, the string is often assumed to be mutable, and will 
typically be heap-based (allocated via malloc or a GC library or similar).

a "reasonable" strategy for plain C here is to essentially create an 
analogue of an std::string object in C (the string-buffer is 
held/managed by a wrapper object).

a string-buffer makes sense where either the string is mutable, or it is 
otherwise potentially large (examples being input and output buffers, 
read-in text files, ...).

granted, all this is not generally needed in C++ code, except where 
inter-operation with C code (or other non-C++-aware languages) is needed.


> This all depends very much on the compiler and optimization levels of
> course.
>

yep.

this applies to both languages.

[toc] | [prev] | [next] | [standalone]

#10222

On Sat, 2011-09-17, Juha Nieminen wrote:
> Christopher <cpisz@austin.rr.com> wrote:
...

>> In fact, that
>> argument has grown into ,"we shouldn't use any of the STL containers,
>> because they allocate, which is expensive."
>
>   And what exactly is the proposed alternative?

If it's anything like a recent project: slower, type-unsafe, informal
and buggy versions written in C. (Can't blame them: it's a C project.)

Or the worse options: choosing an inappropriate algorithm which works
with C arrays, e.g. doing linear searches in an array because you
don't have a std::map.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#10224

On 9/17/2011 7:02 AM, Jorgen Grahn wrote:
> On Sat, 2011-09-17, Juha Nieminen wrote:
>> Christopher<cpisz@austin.rr.com>  wrote:
> ...
>
>>> In fact, that
>>> argument has grown into ,"we shouldn't use any of the STL containers,
>>> because they allocate, which is expensive."
>>
>>    And what exactly is the proposed alternative?
>
> If it's anything like a recent project: slower, type-unsafe, informal
> and buggy versions written in C. (Can't blame them: it's a C project.)
>
> Or the worse options: choosing an inappropriate algorithm which works
> with C arrays, e.g. doing linear searches in an array because you
> don't have a std::map.
>

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).


I before did a check (between using an "if(!strcmp) {...} else ..." 
chain and using a hash-table followed by a switch, and found a "break 
even" point of about 6 options).

if there were < 6 total options, then the if/else chain was faster, and 
in > 6 options, the hash-table + switch was faster.

for larger N (100s or 1000s of strings to match against) then a 
hash-table is a clear win...

binary trees (and prefix trees) can give better performance in certain 
use cases, but are in general both more complex to implement and give 
worse performance than hash-tables in the average case IME.

a chain hash is a typical way to speed up array based lookups.

and, all of this works in C...


yes, "std::map" is more convenient, but it is not "essential" for 
writing efficient lookups.

this does not justify blaming noobish mistakes or oversights on the 
language itself, where one could just as easily condemn C++ for sake of 
"pointer-based memory objects being almost impossible to use without 
causing crashes" or "the lack of automatic bounds checking causes memory 
to become corrupt" or all of the other ways one can shoot themselves in 
the foot.

one can respond "well, it is not C++'s fault if you have no idea what 
you are doing", and the same goes for C.

C just leaves a little more in the open, and may require a bit more 
manual effort in such cases...

[toc] | [prev] | [next] | [standalone]

#10250

BGB <cr88192@hotmail.com> 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.

[toc] | [prev] | [next] | [standalone]

#10307

On 9/18/2011 8:17 AM, Juha Nieminen wrote:
> BGB<cr88192@hotmail.com>  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.
>

fair enough, one has to decide on the type of hash table, ...
but they are not all that complicated code-wise, and are typically not 
all that large (WRT code), albeit a factor worth consideration is the 
size (too small will not be very effective or will fail, depending on 
variety, and too large may waste memory or actually perform worse than a 
smaller hash).

however, "rules of thumb" are generally reasonably effective.


>    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.
>

I have had generally good success with polynomial hashes (generally 
better collision behavior than the more traditional shifts+xors hashes).

there are also some nifty (almost magical) properties of prime-numbers 
when used in hash-functions and similar (note: mersenne and non-mersenne 
primes exhibit different properties).


found this:
http://en.wikipedia.org/wiki/Universal_hashing

one of the algos mentioned is similar to one I often use.

however, I developed my variant on my own, initially mostly by fiddling 
and similar...


>    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.

possibly, but I have generally not had too many problems with bugs WRT 
hashing, but OTOH, this is also one of those things that one may end up 
internalizing due to frequent use.

[toc] | [prev] | [next] | [standalone]

#10217

On 17 syys, 01:07, Christopher <cp...@austin.rr.com> wrote:
> 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."

There may be a difference in speed, but std::string is better
(or should be) from programmer's perspective, because it's:
-more reliable and less likely to produce bugs
-usually more readable
-easier to refactor

I think things like that are more important than efficiency
which in most cases is in acceptable level with std::string also.

[toc] | [prev] | [next] | [standalone]

#10219

On Sep 17, 12:07 am, Christopher <cp...@austin.rr.com> 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.

Anectotal evidence: I once refactored part of a C-only code with C++.
The whole shebang: classes, polymorphism, exceptions (not
std::exception based though). I got smaller final executable (small
margin, but still). And I could have done even better if I hadn't
replace one C sort with std::sort (which I did). Performance wasn't an
issue, nor code size, really, just code simplification. So size was an
added bonus.

Goran.

[toc] | [prev] | [next] | [standalone]

#10228

On Sep 16, 3:07 pm, Christopher <cp...@austin.rr.com> 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...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...

[toc] | [prev] | [next] | [standalone]

#10238

On Sep 17, 11:43 am, Noah Roberts <roberts.n...@gmail.com> wrote:
> On Sep 16, 3:07 pm, Christopher <cp...@austin.rr.com> 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

[toc] | [prev] | [next] | [standalone]

#10239

On Sep 17, 11:43 am, Noah Roberts <roberts.n...@gmail.com> wrote:
> On Sep 16, 3:07 pm, Christopher <cp...@austin.rr.com> 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...

[toc] | [prev] | [next] | [standalone]

#10249

On Sun, 2011-09-18, Ebenezer wrote:
> On Sep 17, 11:43 am, Noah Roberts <roberts.n...@gmail.com> 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   .

[toc] | [prev] | [next] | [standalone]

#10251

"Jorgen Grahn" <grahn+nntp@snipabacken.se>
> 
> 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.)

:)

[toc] | [prev] | [next] | [standalone]

#10253

On Sep 18, 9:45 am, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Sun, 2011-09-18, Ebenezer wrote:
> > On Sep 17, 11:43 am, Noah Roberts <roberts.n...@gmail.com> 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 ...

[toc] | [prev] | [next] | [standalone]

#10276

On Sep 17, 6:29 pm, Ebenezer <woodbria...@gmail.com> wrote:
> On Sep 17, 11:43 am, Noah Roberts <roberts.n...@gmail.com> wrote:
>
>
>
>
>
> > On Sep 16, 3:07 pm, Christopher <cp...@austin.rr.com> 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.lang.c++/msg/4654d14136415717

[toc] | [prev] | [next] | [standalone]

#10282

On Sep 17, 12:43 pm, Noah Roberts <roberts.n...@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web