Coding: Fleeting Thoughts

[3fj]

It strikes me that whilst delete deallocates memory, it keeps the pointer refrence. Is there a way to forget it?

[Rysto]

You can set the pointer to NULL after calling delete.

[0xBADFEED]

It strikes me that whilst delete deallocates memory, it keeps the pointer refrence. Is there a way to forget it?

That's called a "dangling pointer" and is the bane of many a programmer.

Lacking actual smart-pointers you can do something like:

Code: Select all

template<typename T>
void safe_delete(T* &ptr)
{
   delete ptr;
   ptr = NULL;
}

//Example usage
int* ptr = new int;
*ptr =  5;
safe_delete(ptr); //deletes pointer and sets it to NULL

//ptr is now NULL



And then use 'safe_delete' instead of 'delete'

['; DROP DATABASE;--]

I just get into the habit of always setting a pointer to NULL after deleting it. That way you're covered with e.g. free() too.

Also:

Code: Select all

sprintf("%d", foo);

Why does GCC let me do this?

[Berengal]

Also:

Code: Select all

sprintf("%d", foo);

Why does GCC let me do this?

It assumes you know what you're doing.

[jaap]

Also:

Code: Select all

sprintf("%d", foo);

Why does GCC let me do this?

Did you forget to include stdio.h?

[Rysto]

Also:

Code: Select all

sprintf("%d", foo);

Why does GCC let me do this?

Use the -Wall option and gcc gives a warning for this(assuming you've included stdio.h).

['; DROP DATABASE;--]

I thought I did... guess not.

Also, a lesson in efficiency. I implemented a simple protocol in an N64 emulator to read and write the game's memory over TCP/IP. You send a request containing address, # bytes, and a command (9 bytes in total), and it sends back however many bytes you requested.

As an experiment, I dumped all 4MB using this protocol in two different ways, and measured their speeds. The first method was a simple loop: (pseudocode)

Code: Select all

for(i = 0x80000000; i<0x80400000; i++)
{
request 1 byte starting at i
wait for reply
write reply[0] to file
}

The second made only a single request:

Code: Select all

request 0x400000 bytes starting at 0x80000000
wait for reply
for(i=0; i<0x400000; i++)
write reply[i] to file

You might think with both programs running on the same machine (i.e. connected to localhost), the difference in transfer speeds would be negligible. WRONG!
Method 1: 11 KB/s
Method 2: 27,060 KB/s.

[Two9A]

You might think with both programs running on the same machine (i.e. connected to localhost), the difference in transfer speeds would be negligible. WRONG!
Method 1: 11 KB/s
Method 2: 27,060 KB/s

Mm, you'd be surprised how much overhead there is on a one-byte transmission. TCP header, IP header, Ethernet header and footer; and that has to be put on at one end and taken off at the other. I'm surprised you got 11k/s

In other news, I'm left wondering why I do PHP for a living.

[qbg]

I just found myself writting this Java code for a school project:

Code: Select all

int leetness_level = Over9000();


along with:

Code: Select all

if (leetness_level > 9000) {
    // Really leet code omitted
}


[MoD]

Clearly your school teaches Java in a better fashion than mine. I wrote a program to write the programs they assign.

Its output is typically longer than its source code, if that gives an idea of the programs' typical complexity.

[Berengal]

Wait, you mean you wrote a program that outputted program that was the answer to an assignment without a priori knowledge of what that assignment was?
If so, what was the assignment, and how exactly does your program work?

[psykx]

Clearly your school teaches Java in a better fashion than mine. I wrote a program to write the programs they assign.

Its output is typically longer than its source code, if that gives an idea of the programs' typical complexity.

You actually made a homework machine??? I second Berengal questions.

[Xanthir]

No, he made a homework *generating* machine, not a homework *answering* machine. It creates homework problems.

[MoD]

The programs we were writing (something like eleven of them) were generally of the form "Make a class, give it field a of type b, field c of type d, and field e of type f. Write getter and setter methods and make a new class that instantiates three objects from the first one with given data."

So I wrote a Java program that took the class name, fields, the corresponding types and their values for the three instances, and generated the source code for the program I was supposed to write. Yes, it's trivial, but it just shows how much more so the multitudinous formulaic assignments were.

[Xanthir]

Ah, okay.

Fwiw, you could also have generated those problems programatically.

[Rysto]

I've just been assigned a ticket in our internal bug-tracking system. The due date for the ticket is January 18, 2038. For full marks, answer:

1) What's the bug I have to fix?
2) The due date of this bug is wrong. How is it wrong, and why is it wrong?

[sakeniwefu]

I've just been assigned a ticket in our internal bug-tracking system. The due date for the ticket is January 18, 2038. For full marks, answer:

1) What's the bug I have to fix?
2) The due date of this bug is wrong. How is it wrong, and why is it wrong?

The Unix Millenium Bug? Then the date is not wrong. If it specified January 19 and you did it by 23:59 the bug would already have released the nuclear heads.

[tetsujin]

I've just been assigned a ticket in our internal bug-tracking system. The due date for the ticket is January 18, 2038. For full marks, answer:

1) What's the bug I have to fix?
2) The due date of this bug is wrong. How is it wrong, and why is it wrong?

1: 32-bit unix time overflow issue (overflow is around 3AM GMT on the 19th...)
2: Hmmm... Maybe the application needs to store future dates sometimes? Maybe you need time (more than a day) to test the fix after it's in?

[Rysto]

2: Hmmm... Maybe the application needs to store future dates sometimes? Maybe you need time (more than a day) to test the fix after it's in?

Nah, it's simpler than that. Our ticket system uses 32-bit dates!

[btilly]

I thought I did... guess not.

Also, a lesson in efficiency. I implemented a simple protocol in an N64 emulator to read and write the game's memory over TCP/IP. You send a request containing address, # bytes, and a command (9 bytes in total), and it sends back however many bytes you requested.

As an experiment, I dumped all 4MB using this protocol in two different ways, and measured their speeds. The first method was a simple loop: (pseudocode)

Code: Select all

for(i = 0x80000000; i<0x80400000; i++)
{
request 1 byte starting at i
wait for reply
write reply[0] to file
}

The second made only a single request:

Code: Select all

request 0x400000 bytes starting at 0x80000000
wait for reply
for(i=0; i<0x400000; i++)
write reply[i] to file

You might think with both programs running on the same machine (i.e. connected to localhost), the difference in transfer speeds would be negligible. WRONG!
Method 1: 11 KB/s
Method 2: 27,060 KB/s.

See http://en.wikipedia.org/wiki/Nagle's_algorithm for an explanation of the huge difference.

[Rysto]

I just love how everybody has to define their own fixed width types. I just found the following in some code:

Code: Select all

typedef long S32;

If I use a typedef, surely my program must be platform independent, right?

[Posi]

I know that a language is not worth learning unless it changes the way you think (or something like that), but this one just makes me think about suicide. That language is VHDL.

For those that don't know about it, VHDL is a hardware describtion language. It allows you to implement hardware in software. A bonus is you do not have to figure out how you would actually have to implement the piece of hardware, but you can use the language to aid you with that. My beef with the language isn't so much about the language (although I do prefer {} over BEGIN END), its more the toolchain my school uses sucks ass in ways I have yet to dream of. What really takes the cake is that the compiler has two error messages: "Line XX: syntax error" and "Line XX: feature YZ is not supported in this implementation". I kinda find it hard to believe that a company made money off of this.

[Briareos]

This is it: this is the time that I use Haskell for one of my course assignments. This means I shall finally be forced how to do I/O with it. It is too bad, because Haskell would make the assignments (various NLP tasks) so straightforward if only we didn't have to deal with, y'know, real data that comes from external files and that one would do well to store in hash tables.

Grr. Monads.

[Berengal]

I feel you. Still haven't grasped monads... I have found that it's possible to push that stuff into a small corner do block and do most things purely functional, without understanding monads completely. Your mileage might vary.

[phlip]

That language is VHDL.

Thanks for reminding me.

I thought I'd repressed those memories enough... it seems not.

[Sc4Freak]

I just love how everybody has to define their own fixed width types. I just found the following in some code:

Code: Select all

typedef long S32;

What's the problem with that?

[Xanthir]

Long isn't necessarily 32 bits?

[3fj]

I've decided that i don't like using Matlab. Thinking in a matrix as well as types of variables is just a pain.

I can see the nessessity for it i guess, being as it was designed for computations on shedloads of real data. I just don't need to do that sort of thing. That, and i was forced to use it to code something i could have done in a few lines in most other languages.

[Rysto]

Long isn't necessarily 32 bits?

Oh heck no. On my x86-64 Linux system:

Code: Select all

# cat tmp.c
#include <stdio.h>

int main(int argc, char ** argv)
{
    printf("sizeof(long) == %zd\n", sizeof(long));


    return 0;
}
# ./a.out
sizeof(long) == 8


I'm pretty sure that goes for any other x86-64 gcc target, too.

[Xanthir]

Sorry, that was specifically a response to Sc4Freak, directly above me.

[Rysto]

Whoops. I missed that post. Consider my response as being directed to Sc4Freak instead.

[phlip]

More than that, though, is that this is a problem that has already been solved...

Ignoring the standard headers and rolling your own typedefs for that sort of thing accomplishes two things:
* Adds one more thing that needs to be changed and tested (and could easily break stuff if you forget to change it) if/when you actually port the code to another platform (such as x86-64).
* Makes the code harder to read, 'cause you're using new names for things that a newcomer to the code might not recognise (and calling it just "S32" only adds to that)... int32_t has a better chance of being recognised by the reader, since, being standard, they have a better chance of having seen it before.

['; DROP DATABASE;--]

A while ago I added a bunch of debugging functions to an SVN version of Mupen64plus. Things went pretty well; the original code is a bit messy but it wasn't too hard to figure out how to add on to it.

I left that project alone for a while, then came back and got the latest SVN version... agh! They've completely broken it! I had to hack some things just to make it able to pause properly; when "paused" it would just automatically step through the code in the debugger. The disassembler doesn't show half the instruction ("LUI $reg1," - they never did use the nice register names, or even "r1"; I didn't write the disassembler), the debugger interface frequently fails to update or crashes when paused, and it still has issues with stepping an instruction or two while paused. They also didn't fix any of the bugs, such as incorrectly handling jumps when stepping, and actually brought back a few I'd fixed, such as this:

Code: Select all

char buf[32];
sprintf(buf, "%f", foo);

where foo is one of the floating-point double registers, meaning the value can reach about 508 digits (and %f will print them all rather than using scientific notation).

What's most annoying is the FPU registers are so hairy it's as if they're deliberately obfuscated. N64 has 32 FPU registers, each 32 bits, that can be used individually as floats or in pairs as doubles. They can also occasionally contain integers, mainly when you're transferring between CPU and FPU registers.
So in the emulator we have two arrays of FPU registers; one 64-bit, and one 32-bit that doesn't even seem to be used. Then two arrays of pointers to each cast to different types. Some code uses one and some code uses another. It's damn near impossible to tell just how these bloody values are stored.

I don't know if I want to try to fix all this nonsense, start my own fork from the old version I had before all this stuff broke, or try (and probably fail) to write my own emulator. Bleh.

So, trying to get the raw values of the FPU registers into a byte array, padded to 64 bits:

Code: Select all

for(j=0; j<32; j++)
{   //8 (size of CPU regs) * 32 (# CPU regs) = 256
   CurData[256 + (8 * j)] = (unsigned char)((reg_cop1_fgr_64[j / 2] >> (24 + (j & 1 ? 32 : 0))) & 0xFF);
   CurData[257 + (8 * j)] = (unsigned char)((reg_cop1_fgr_64[j / 2] >> (16 + (j & 1 ? 32 : 0))) & 0xFF);
   CurData[258 + (8 * j)] = (unsigned char)((reg_cop1_fgr_64[j / 2] >>  (8 + (j & 1 ? 32 : 0))) & 0xFF);
   CurData[259 + (8 * j)] = (unsigned char)((reg_cop1_fgr_64[j / 2] >>  (0 + (j & 1 ? 32 : 0))) & 0xFF);
   CurData[260 + (8 * j)] = 0;
   CurData[261 + (8 * j)] = 0;
   CurData[262 + (8 * j)] = 0;
   CurData[263 + (8 * j)] = 0;
}

Yeah.

[tetsujin]

More than that, though, is that this is a problem that has already been solved...

Ignoring the standard headers and rolling your own typedefs for that sort of thing accomplishes two things:
* Adds one more thing that needs to be changed and tested (and could easily break stuff if you forget to change it) if/when you actually port the code to another platform (such as x86-64).
* Makes the code harder to read, 'cause you're using new names for things that a newcomer to the code might not recognise (and calling it just "S32" only adds to that)... int32_t has a better chance of being recognised by the reader, since, being standard, they have a better chance of having seen it before.

You forgot:

* It allows you to compile with compilers that don't (yet?) provide the stdint header...

Creating your own typedefs isn't a perfect solution - but just having that typedef there (even if it's not cross-platform correct) means that you can easily fix the code later, by changing the typedef in one place rather than usage in several hundred places.

[You, sir, name?]

Today's realization is how much speed you can gain by enabling the more... unorthodox compiler flags sacrificing binary compatibility and standards compliance.

Going from
gcc -O2
to
gcc -O3 -march=athlon64 -funroll-all-loops -ffast-math

Made my volumetric buddhabrot generator run 5 times faster. From 20 seconds per frame to 3 seconds per frame. It was like going from MATLAB to C

[phlip]

Creating your own typedefs isn't a perfect solution - but just having that typedef there (even if it's not cross-platform correct) means that you can easily fix the code later, by changing the typedef in one place rather than usage in several hundred places.

Sure, standard typedefs > roll-your-own typedefs >> no typedefs at all.

But if your compiler doesn't provide stdint.h, it shouldn't be too hard to find one on the 'net, or to just build your own - certainly, no harder than just throwing the standard out and rolling your own typedefs anyway, and has the added benefits of making you able to compile any other code you find that uses stdint.h.

[stephentyrone]

Today's realization is how much speed you can gain by enabling the more... unorthodox compiler flags sacrificing binary compatibility and standards compliance.

Going from
gcc -O2
to
gcc -O3 -march=athlon64 -funroll-all-loops -ffast-math

Made my volumetric buddhabrot generator run 5 times faster. From 20 seconds per frame to 3 seconds per frame. It was like going from MATLAB to C

Speaking as someone who has to read the bugs people file when this breaks their code, please, please don't tell people to use -ffast-math. You can do everything it does with source-level optimizations, and you've got a much better chance of understanding what those do to your code, so you know that it's your fault when it doesn't work anymore. =)

FWIW, unroll-all-loops will hurt your performance about as often as it will help it on most modern x86 chips (notable exceptions exist, but other optimizations will get a lot of those cases, depending on the compiler you're using).

[You, sir, name?]

In general, all cargo cult optimization is evil. After toggling a compiler flag, naturally one should test if the performance actually is improved (and ideally also understand what it does ), and not just assume it is because someone said so or it usually is.

In my case, funroll-all-loops and fast-math was efficient (the program was basically a ton of nested fixed-length loops riddled with safe floating point math) . But then I was only interested in running the program on this one computer.

[rrwoods]

I know that a language is not worth learning unless it changes the way you think (or something like that), but this one just makes me think about suicide. That language is VHDL.

For those that don't know about it, VHDL is a hardware describtion language. It allows you to implement hardware in software. A bonus is you do not have to figure out how you would actually have to implement the piece of hardware, but you can use the language to aid you with that. My beef with the language isn't so much about the language (although I do prefer {} over BEGIN END), its more the toolchain my school uses sucks ass in ways I have yet to dream of. What really takes the cake is that the compiler has two error messages: "Line XX: syntax error" and "Line XX: feature YZ is not supported in this implementation". I kinda find it hard to believe that a company made money off of this.

I feel your pain. I had to write a processor in VHDL for the final project in my hardware class.