# Introduction

I was watching a rather interesting EEVBlog video where Dave Jones showed a tracking pre-regulator design someone named "John Barnes" sent him (hopefully I got that right). Unlike his first video where he took Linear Technologies example circuit which uses the threshold voltage of a MOSFET to set the pre-regulator voltage, the new design uses a PNP transistor and resistors to calibrate the pre-regulator voltage. This design has several advantages over the MOSFET design. The main big one is that the threshold voltage can be set indepedendant of the specific component parts used, where-as the MOSFET design was highly dependant on the exact part used. Additionally, the ability to find the specific MOSFET with the correct threshold was unlikely. Dave did say you could compensate for this by adding diodes, but really this is a poor design in my opinion and he seemed to agree. Dave did some spice simulations with some actual parts and was able to parametrically evaluate what resistor values to use for a given target pre-regulator voltage. This is great if you have the available parts in your simulation software, but I wondered if I couldn't arrive at the solution using some math so I could design with any components I wanted. I also was curious as to why the thing worked to begin with, which the simulation software doesn't give too much indication towards.

## Tuesday, March 19, 2013

### More Fun with Sieving Primes

I was playing around with my prime sieving implementation and I managed to improve the performance by making some simple changes. The code looks quite a bit different, but functionally it does basically the same thing. The one big difference is that I switched the code to use arrays instead of ArrayLists. Through some testing I realized that there was a fairly significant performance difference between arrays and ArrayLists. The actual problem has to deal with Java generics and boxing of primitives. I may go more into the details at a later date. It's a rather specialized optimization and for the vast majority of programs shouldn't be necessary. Other than that, the code is generally more readable.

## Tuesday, March 12, 2013

### A Safer Way to test the Validity/Safety of a Link

One thing that's always bothered me is figuring out if a link is legitimate or potentially a security risk. This is especially problematic with shortened URL's. I really dislike these and don't follow shortened URLs unless I absolutely know it's a trusted link. Many times just knowing the poster isn't enough to convince me to click a shortened URL as it's way to easy for someone to have their account compromised.

So how do you analyze the contents of a target link in a safer environment other than test-clicking willy-nilly in a browser?

## Tuesday, March 5, 2013

### That One Bug That Just Won't Go Away...

So I was recently trying to get a piece of C++ code to compile and I just could not figure out what was going on. Here's a sample roughly of what the code looked like. It's not quite the same code I was debugging, but it does spit out similar compiler outputs.

namespace space
{

template<typename type> class ClassA
{
protected:
int bounds;
public:
virtual ~ClassA(void)
{
}

virtual int doIt(void) = 0;
virtual int doIt2(void) = 0;
};

template<typename type> class ClassB : public ClassA<type>
{
protected:
ClassA<type> *parent;
public:
virtual ~ClassB(void)
{
}

virtual int doIt(void)
{
return bounds;
}

int doIt2(void)
{
return parent->bounds;
}
};

}


For the longest time I could not figure out why doIt2 wasn't calling properly. The actual code I was debugging was a bit more complicated, but I should have been able to quickly identify the problem and fix it.

The compiler message: 'ClassA::bounds' : cannot access protected member declared in class 'ClassA'

The message would highlight the access line in doIt2 where I try to retrieve the bounds value from parent. My first thought was that the problem might have to deal with C++ template types not being right since I'm not particularly well-versed with C++ templates. After double checking, then triple and quadruple checking the templates I decided that they were correct and that there must be some other problem. Needless to say, I chased red herring after red herring trying to figure out what was wrong.

So what was the actual problem? I forgot to declare ClassB as a friend to ClassA. This is one of those details that gets lost between Java programming and C++ programming. In Java, even though the field bounds is protected I can still access it from anywhere in the same package. The closest equivalent in C++ are namespaces, though these really aren't that close at all. So me being in a semi sleep-deprived state assumed (there's that magical 7 letter word which causes trouble) that I must be able to have access to bounds because not only was I in the same namespace, I was in the same file.

After taking a little break, I finally realized my mistake, shook my head and decided to write a blog post about the ordeal. Morale of the story? Take a break when you're stuck on a problem you just can't figure out. And get some sleep.

The fixed solution:

namespace space
{

template<typename type> class ClassB;

template<typename type> class ClassA
{
protected:
int bounds;
public:
virtual ~ClassA(void)
{
}

virtual int doIt(void) = 0;
virtual int doIt2(void) = 0;

friend class ClassB<type>;
};

template<typename type> class ClassB : public ClassA<type>
{
protected:
ClassA<type> *parent;
public:
virtual ~ClassB(void)
{
}

virtual int doIt(void)
{
return bounds;
}

int doIt2(void)
{
return parent->bounds;
}
};

}