design patterns

I feel like I should pick up a book on common design patterns or maybe any kind of text with explanations of the thought process that real programmers take when dealing with medium size projects. The intense pondering I've been doing about this file reader is useful but I wonder if I'm missing something obvious that's a better way of doing it. Matt revealed the model-view-controller paradigm to me recently and that more or less blew my mind. Makes me wonder what else is out there.

netbook

Today's exercise was done on the Ubuntu netbook while at Ana's mom's house. I brought both the laptop and the netbook and they're using the laptop to do wedding invitation stuff.

The point here is that I forgot how much I like CodeBlocks under Ubuntu. XCode is intimidating and the OSX build of CodeBlocks is known to be a bit wonky. I use XCode anyways but sometimes it does things or adds files to a project and I don't know why. There isn't a project template for "simple uncomplicated console application". Even getting to the console output is two clicks away and oddly decoupled. I've considered going back to the command line but I am getting spoiled on auto-complete and function prototype reminders - especially because the structures involved with the file reader have a dozen or so members and it's hard to remember exact spelling and capitalisation.

Truth be told I'd be better of for having to do things all through the terminal (well I'd use TextWrangler or Notepad++ for syntax highlighting). I suppose what I mean to say is I need to keep it down to a few hand-made files and compiling at the command line. I abandoned that method on the netbook after a while since it wasn't convenient to quickly change one thing and recompile. Might not be as true on the laptop.

Alloc so far so good

This worked the first time which is a good sign that some stuff I see over and over again but don't actually use sticks!

The output is: Storage is at 0x808e008 and is size 4

...and the address naturally changes run to run.

So the program for getting data out of a file will return an address of where the data is stored. That's what malloc is for right? Put data into the heap and that data remains until freed (oh snap I just realized I never freed my array in the program above...) regardless of where it was allocated (like it won't go out of scope unless the variable storing the address goes out of scope before being passed out of the function).

This has the double benefit of delivering the data and allowing for knowing how many elements is in the stored space (proved with my use of sizeof).

So, hooray.

final decision

The final decision is to make a function that simply returns a pointer where some allocated memory with the data is.

even better

I keep thinking of better ways to write this program.

Like maybe what my file reader (the part of the program dealing with extracting the blocks) should shuffle the blocks out to some different program. Or maybe buffer them somewhere else?

Maybe I should stick to what it's at right now. Brute force and bulky but functional?

reusability

Programming before sleeping results in code dreams.

I realized last night (err... in a dream) that I'm copy/pasting a lot of code. Every function in the toolkit I'm making has a large chunk of semi-identical code for opening a file and seeking/reading through it. The only difference is that what particular piece of data is skipped over or read changes. I considered making one function for everything and having the lines for dumping the data out be keyed to a bunch of conditions you pass to the function, but that started to look obfuscated.

Is this what OOP is for? Could I have made one class for reading data and then have the subclasses be slight modifications? Is that the right word? I dunno.

Ok, so one way I could have done it was have one block of code in a function for reading out everything, but the difference between functions is the return values (or rather what data gets dumped to previously allocated storage).

I decided to have the size functions return the number of data instead of the total size in bytes. This way you have a number to use as your index when scanning through the returned data.

EDIT: I think I hashed out in the shower how to handle this with ONE function that goes through the file. The trick is passing the function a pointer to other "which data to get" functions. I haven't completely worked it out yet but it's promising. If I can write a program that does memory allocation AND function pointers in one go I'll be very happy!

specificity

On a whim I once again re-wrote some of my file reader. This time I'm making a library of functions that do specific things. I have one function finished and another half-started.

The first function scans through a file and reports back how many timestamps there are for a specific unit on a specific channel. You pass the function a string (the filename), a channel, and a unit. With this data I want to then allocate some memory to hold an array of all the timestamps for that unit/channel.

The second function will actually pass the timestamps to that allocated memory.

I can't decide if the first function should just report back the number of timestamps or if it should just go ahead and report back the number of bytes that need to be allocated. There are benefits to both methods.

Why allocate on the fly? Each timestamp is a long integer. There might be a dozen in a file or there might be several hundred thousand. This seems prime for learning me some malloc.

So this library would be used with all the different data types in the file eventually and would be used as follows:

1) Call the function that determines how big the data is in the file for that channel/unit, or digitized waveform channel, or event.

2) Allocate space for the data.

3) Call the function to get the data (passing it a pointer to the space allocated as well as the channel/unit/filename/etc).

This won't be too particularly useful in real life but it is good practice for making a program that does specific things instead of a kitchen sink program that I hand-modify every time I need it to do something else.

Practice is practice.