Re: writef: How to output hex byte?
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 this case.
Re: writef: How to output hex byte?
"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 format string as-is.
I gotta learn not to simplify my test cases without re-testing them...
The above examples work fine, but the following don't - what I'm trying to
do here is output a percent sign followed by a hex byte (as in URL escape
sequences), but these just output "%%02X":
ubyte myByte = 0x09;
writef("%%%.2X", myByte);
writef("%%%02X", myByte);
I know I can easily work around that, but I'm wondering if this is a bug or
if I've misunderstood how that format syntax is supposed to work.
writef: How to output hex byte?
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.
Re: built-in string hash ?
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;
void main() {
enum int NLOOP = 30_000_000;
string s = "and I'd like to add a toHash() member, but I can't
find the built-in string hash function.";
{
auto t0 = getUTCtime();
auto stringHash =&(typeid(s).getHash);
hash_t tot;
for (int i; i < NLOOP; i++)
tot += stringHash(&s);
auto t1 = getUTCtime();
writeln(tot, " ", (t1 - t0) / cast(double)ticksPerSecond);
}
{
auto t0 = getUTCtime();
hash_t tot;
for (int i; i < NLOOP; i++)
tot += typeid(s).getHash(&s);
auto t1 = getUTCtime();
writeln(tot, " ", (t1 - t0) / cast(double)ticksPerSecond);
}
}
And the asm shows the first loop to contain one less instruction (dmd
2.048, -O -release -inline), so the difference is small:
L42:lea ECX,01Ch[ESP]
mov EAX,02Ch[ESP]
pushECX
callEDI
add ESI,EAX
inc EBX
cmp EBX,01C9C380h
jb L42
LA7:lea EDX,01Ch[ESP]
mov ECX,_D12TypeInfo_Aya6__initZ
DMD seems to do a bad job of dead assignment removal at the ASM level. I've
seen this befor where half the asm in large blocks was dead.
mov EAX,offset FLAT:_D12TypeInfo_Aya6__initZ
pushEDX
calldword ptr 018h[ECX]
add EDI,EAX
inc EBX
cmp EBX,01C9C380h
jb LA7
Bye,
bearophile
--
... <
Re: built-in string hash ?
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() {
enum int NLOOP = 30_000_000;
string s = "and I'd like to add a toHash() member, but I can't find the
built-in string hash function.";
{
auto t0 = getUTCtime();
auto stringHash =&(typeid(s).getHash);
hash_t tot;
for (int i; i < NLOOP; i++)
tot += stringHash(&s);
auto t1 = getUTCtime();
writeln(tot, " ", (t1 - t0) / cast(double)ticksPerSecond);
}
{
auto t0 = getUTCtime();
hash_t tot;
for (int i; i < NLOOP; i++)
tot += typeid(s).getHash(&s);
auto t1 = getUTCtime();
writeln(tot, " ", (t1 - t0) / cast(double)ticksPerSecond);
}
}
And the asm shows the first loop to contain one less instruction (dmd 2.048, -O
-release -inline), so the difference is small:
L42:lea ECX,01Ch[ESP]
mov EAX,02Ch[ESP]
pushECX
callEDI
add ESI,EAX
inc EBX
cmp EBX,01C9C380h
jb L42
LA7:lea EDX,01Ch[ESP]
mov ECX,_D12TypeInfo_Aya6__initZ
mov EAX,offset FLAT:_D12TypeInfo_Aya6__initZ
pushEDX
calldword ptr 018h[ECX]
add EDI,EAX
inc EBX
cmp EBX,01C9C380h
jb LA7
Bye,
bearophile
Re: Memory management and garbage collectors
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 sees as possible pointers even stuff that is not a pointer, so noise may keep alive memory blocks that are not really referenced. > So take a for- > instance. Consider a circular linked list that we are done with. Each > node has a reference to it (from another node in the list). But, being > done with the list, we imagine that there are no references from outside > the list to any node. Is D's garbage collector smart enough to deal > recognize the circle of nodes as garbage? It's not a matter of being smart, it's a matter of how its algorithm works. In a GC based on reference counts, you keep an object alive if its count is nonzero, this means if one or more references point to it. In a GC like the D one (well, in a basic implementation of its idea), you have some starting pointers, the roots, and starting form them you explore the graph of the references, and along the way you mark the visited objects. At the end you scan the list of all the objects and delete the ones with no mark. So the presence of a cycle is not a problem. A cycle is recycled if no external pointers point to it. CPython GC is a reference counter, but they have added extra logic to recognize and recycle cycles too. I leave other of your questions to other people. Bye, bearophile
Memory management and garbage collectors
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 does it need? Okay, that is too general a question. So take a for- instance. Consider a circular linked list that we are done with. Each node has a reference to it (from another node in the list). But, being done with the list, we imagine that there are no references from outside the list to any node. Is D's garbage collector smart enough to deal recognize the circle of nodes as garbage? Is it necessary or at least helpful to set all the circle's links to null before being done with it? I assume that reference counting collectors are not smart enough to handle an abandoned circular list. But D's GC is not a reference counter. I don't know how smart GC's get. Is it okay to leave a single node linking to itself? Another for-instance. Consider this time a linear linked list. This time, the list is finite: it terminates with a node pointing to null. Are the issues here any different? Thanks in advance for any insights.
Re: built-in string hash ?
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);
auto hash2 = stringHash(&a);
assert(hash1 == hash2);
}
Bye,
bearophile
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.
Perhaps it works better if a was an Object, since typeid for objects
does more.
Re: built-in string hash ?
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(hash1 == hash2);
}
Bye,
bearophile
Re: void[] vs byte[]
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 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 is byte[] (chunk in std.stdio). Is there a place where this stuff is documented? Or choosing one or another is just a matter of preference and the differences are trivial? Thanks in advance. -- ... <
void[] vs byte[]
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 is byte[] (chunk in std.stdio). Is there a place where this stuff is documented? Or choosing one or another is just a matter of preference and the differences are trivial? Thanks in advance. -- Yao G.
Re: Ways to initialize static arrays
Done: http://d.puremagic.com/issues/show_bug.cgi?id=4745
Re: built-in string hash ?
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 strings can clearly be the key in a map.
I see that xml.d writes its own string hash function
but that just doesn't seem right.
Is there a way to get to the built-in ?
You can get to it through TypeInfo:
http://www.digitalmars.com/d/2.0/phobos/object.html#getHash
string a = "abc";
auto hash = typeid(a).getHash(&a);
built-in string hash ?
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 see that xml.d writes its own string hash function
but that just doesn't seem right.
Is there a way to get to the built-in ?
Re: Compiling Windows GUI-application
"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 are > bad and there are't > any free delphi > versions. Have you checked out Lazarus/FreePascal? http://www.lazarus.freepascal.org/index.php?topic=8406.0 -=mike=-
