<font face="Times New Roman" size="3">Funnily enough, some of the refactorers<font face="Arial" size="1">[1]</font> haven't quite got it right.
try:
<font face="Courier New" size="2"> </font><font size="2"></font><font face="Courier New" size="2">control.Text = (!i).ToString();</font>
[1] is "refactorers" a word?
Michael J
</font>
Michael_J
@Michael_J
Best posts made by Michael_J
Latest posts made by Michael_J
-
RE: Refactor This!
-
RE: Reinventing pretty much everything
@eimaj2nz said:
(... beginning snipped by MJ)
@Michael J said:<font face="Courier New" size="2">
<font size="3"><font face="Arial"><font face="Times New Roman">If you
have a decent compiler/Run Time library, built-in functions are usually
well optimised and probably faster than anything you can write. </font>
</font></font></font>
I agree that it's best not to re-invent the wheel, and that built-in functions are usually well-optimzed.
However,
it is entirely possible to write a function that's as fast as, if not
faster than, a library function. For example, qbolec's function is
about as optimal as you can get.
(... rest snipped by MJ)
<font face="Times New Roman" size="3">My assembler programming is a bit
rusty, so I can't say for sure. I've seen very fast
implementations for std::memcpy() that ut</font><font face="Times New Roman" size="3">ilised special op-codes for fast copying of data. This was much faster </font><font face="Times New Roman"><font face="Times New Roman" size="3">than
a naïve loop implementation. Knowing the specialised op-codes and
the way the optimiser works can yield some amazing speed improvements.
Whether this can be done for std::strncmp() or not, I don't know.
In general, I prefer to use system functions than to roll my own as
they've usually been written by smart folks who know the platform
intimately - but that's just my prejudice.
As with any advice I give, this is probably worth every penny you paid for it.</font>
<font face="Times New Roman" size="4">Michael J</font>
</font> -
RE: Reinventing pretty much everything
<font face="Courier New" size="2">#include <cstring>
bool stringstartswith(const char* str, const char* </font><font face="Courier New" size="2">startswith</font><font face="Courier New" size="2">)
{
return 0 == std::strncmp(str, </font><font face="Courier New" size="2">startswith, </font><font face="Courier New" size="2">strlen(</font><font face="Courier New" size="2">startswith</font><font face="Courier New" size="2">));
}
<font size="3"><font face="Arial"><font face="Times New Roman">If you
have a decent compiler/Run Time library, built-in functions are usually
well optimised and probably faster than anything you can write.
Michael J </font>
</font></font></font> -
RE: Ads by Google on this site:)
Wow! You almost make me want to stop blocking ads so I can see the comedy.
Almost.
Michael J
-
RE: Self-taught developers
I'm not sure that the problem is self-taught versus college trained.
I think it is more well-trained versus badly (or not) trained.
Just about anybody can learn to shove a few bits of VB, Java or C
together and make a program. However alarmingly few people
realise how poorly that skill scales. As programs get bigger and
more complex, there is a considerable skill required to maintain
correctness.
Good design, good coding practices, good testing practices ...
They seem pretty boring, but they make a vast difference in the quality
of the product. Yet employers largely don't recognise the
difference. Fred has hacked VB for two years while Joe is a
skilled analyst programmer. Fred works for $30/hour and Joe wants
$60. Who do you think they hire?
It isn't universal - there are some god employers, but there are many more clueless ones.
Me, bitter? Of course not. :-)
Michael J
(who spent the last three weeks designing test cases to test every permutation of every branch of a big module in a huge system).
-
RE: Help with C++ style
A memory allocator of the type you've showed us is more of a C
construct than a C++ one. On the whole, C++ developers change
memory allocation primarily in 2 ways:- Writing a custom allocator for STL classes
- Overloading new.
An allocator like yours will likely work well for an array of ints or chars, but may work poorly for classes.
Consider an array of std::strings alloacted using your allocator.
Firstly, the constructor will not be called, so the objects will be left in an uninitialised state.
Secondly, if you modify your allocator to use "placement new" so that the constructor works, you might find that the basic object
uses relatively little memory, and that the object will, itself,
allocate a big buffer (without using your allocator).
Such is life
Michael J