On 29.08.2010 07:06, Nick Sabalausky wrote:
ubyte myByte = 0x09;
writef("%%%.2X", myByte);
writef("%%%02X", myByte);
On codepad.org (DMD 1.026 last time I checked), this prints this:
%09%09
So it's probably a bug in the new formatting code. I assume it's
supposed to follow the C behavior in
"Nick Sabalausky" wrote in message
news:i5cnrn$30h...@digitalmars.com...
> I'm having trouble understanding the docs on this. From what I could tell,
> it seemed like both of these should work:
>
> writef("%.2X", myByte);
> writef("%02X", myByte);
>
> But both of them just simply print the forma
I'm having trouble understanding the docs on this. From what I could tell,
it seemed like both of these should work:
writef("%.2X", myByte);
writef("%02X", myByte);
But both of them just simply print the format string as-is.
Hello bearophile,
Pelle:
I doubt that gives any performance gains. typeid(a).getHash should be
a constant expression anyway, and I don't see any gains in my tiny
benchmark test.
My code shows a limited time difference:
import std.stdio: writeln;
import std.date: getUTCtime, ticksPerSecond;
Pelle:
> I doubt that gives any performance gains. typeid(a).getHash should be a
> constant expression anyway, and I don't see any gains in my tiny
> benchmark test.
My code shows a limited time difference:
import std.stdio: writeln;
import std.date: getUTCtime, ticksPerSecond;
void main() {
JMRyan:
> In theory, garbage collectors make memory leaks a thing of the past.
Even with a perfect GC you may leave around references that keep alive some
data that you will never need to use. This is a kind of memory leak.
And the current D GC is not fully precise, this means that sometimes it
In theory, garbage collectors make memory leaks a thing of the past. In
practice, garbage collectors don't always work according to theory. This
makes me curious: how does one test for memory leaks in a D program?
I also don't know how smart or dumb garbage collectors are. How much help
doe
On 08/28/2010 10:25 PM, bearophile wrote:
torhu:
string a = "abc";
auto hash = typeid(a).getHash(&a);
If higher performance is necessary, you may pre-compute part of that:
void main() {
string a = "abc";
auto hash1 = typeid(a).getHash(&a);
auto stringHash =&(typeid(a).getHash);
torhu:
> string a = "abc";
> auto hash = typeid(a).getHash(&a);
If higher performance is necessary, you may pre-compute part of that:
void main() {
string a = "abc";
auto hash1 = typeid(a).getHash(&a);
auto stringHash = &(typeid(a).getHash);
auto hash2 = stringHash(&a);
assert
Hello Yao G.,
I'm here with another n00b question:
When dealing with big buffers (or files), which is better to use as
storage? void[] or byte[]?
If the data may contain pointers into the heap, use void[] if it will not
use byte[]. byte[] is "raw" data, void[] is anything at all.
What a
I'm here with another n00b question:
When dealing with big buffers (or files), which is better to use as
storage? void[] or byte[]?
What are the advantages and disadvantages of each one? I've seen that
void[] is used in some Phobos modules, like std.zlib, and in other modules
the choice i
Done:
http://d.puremagic.com/issues/show_bug.cgi?id=4745
On 28.08.2010 16:37, Kevin Bailey wrote:
So I have a class containing two strings:
class Foo
{
string s1, s2;
...
and I'd like to add a toHash() member, but I can't find
the built-in string hash function. These don't work:
s1.toHash()
s1.toHash
s1.hash
s1.hash()
hash(s1)
yet
So I have a class containing two strings:
class Foo
{
string s1, s2;
...
and I'd like to add a toHash() member, but I can't find
the built-in string hash function. These don't work:
s1.toHash()
s1.toHash
s1.hash
s1.hash()
hash(s1)
yet strings can clearly be the key in a map.
I
"Fab" wrote in message
news:i59i02$9...@digitalmars.com...
> Thank you. I am using
> my mobile phone to
> answer so it's pretty
> hard. I will try your
> tips later.
>
> ps: i wanted to say
> that delphi is slow
> and it seems to be
> old. in addition the
> bindings for sdl,
> allegro and so on a
15 matches
Mail list logo
