Thursday, July 14, 2016

Sunday, July 10, 2016

Creating a very primitive installation tool: Using winzip to create archives that preserve directory structure

Even when i do an internal project, i like to create a quick installer package for anybody else who might want to use the tool(s). Winzip has a nice command line interface to make this happen, however it took an hour poking through documentation (and 7z proved non-obvious as to how to do it, and online notes suggested the developer is not too interested in making this use case about it on

The specific challenge is the right parameters to get the entire directory structure when you unzip at the destination. To me, this would be quite a useful mode of any zip/archive tool, yet the default is baffling a flat directory structure, surprise! Even using the GUI default modes does the expected it would seem NOT preserving the directory structure is the uncommon case, but that rant is not why i am writing this note for later.

So, here's the scoop:
using winzip, archive using this:
"c:\program files\winzip\wzzip" -P -r @BenchFileList.txt

where BenchFileList.txt has a format like this:

".\docs\GPU Architectures.docx"



and you will get what you expect: when you unzip you will have a directory structure such that your solution and project files are where they are expected to be.


Wednesday, July 06, 2016

migrating C functions when code refactoring

functions are default extern, so you don't need the extern on them when you move the declaration to a header file and definitions to a new file.

when adding the functions to the new cpp file, move the full function over, put the declaration in the header, include the header in the old file you are migrating from but still intend to reference the function. include the new header in the old function.

for the new .cpp file with the code that has migrated from the old .cpp to the new .cpp, include the new header file.

include the .cpp file for the new code in the project as well. or just wait until visual studio complains you forgot this step, come here to re-read this blog post, then do it :)

TODO: add an example here for clarity, but not tonight :)

enums, structs, typedefs of a global struct when code refactoring in C

i often end up in a situation where i've prototyped something in a small testspace then things work out and you want to reuse those tools as you build out another project in the same solution. i've run into this twice in the past year and spent 10 minutes resolving a misunderstanding of intent between the compiler and myself so i'm posting here to save time in the future. note this is for an internal test utility and not product code which shouldn't have any (or very few) globals in the first place, so i'm not putting this here as a shining example of how to do something but instead as how i resolve this specific issue.

here's the refactoring steps:

1. put the typedef and structure in the header file.

typedef struct foo_s { } foo_t;

2. put the declaration into one of the files (the central utility file for example):

foo_t foo;

3. when you want to reference the variable foo in another .c file, use this:

extern foo_t foo;

Enums follow the same pattern, put this in a header:
typedef enum eMODEL_MODE {
} eModelMode_t;

Declare the value into one of the other files:
eModelMode_t g_eModelMode = SINGLE_MODEL;

Reference like so:
extern eModelMode_t g_eModelMode;