Thread: How much is good pay for C++

Originally Posted by brewbuck

but it helps if you are a bad-ass programmer.

Or know the intricacies of some rare protocol, device or sytems and have the right cards (inductions, security, 4WD, etc) to get on site.

My next contract is 8 days for a SAT (site acceptance test) in the middle of the outback for a rail asset protection system . I will make 1/3 of what I made in a whole year as a graduate.

Originally Posted by abachler

I outsourced a more or less straight forward class to rentacoder once, because i didnt have time to mess with it but I needed it done around the same time i finished the core of the application. Ended up having to reexplain the requirements like 3 times even though I spelled out in no uncertain terms things like -

1. Cannot use MFC or STL or ATL. They guy gave me an MFC class that used STL.
2. Must compile on Visual Studio 6.0 ( was using a lot of inline SSE assembly) He gave me a 2003 SLN.
3. Must be suitable for multiple instances of the class. He wrote it as a DLL that used global variables and would choke if you tried to create two instances of the class.
...

I can see why you wouldn't want to use a bloated pig like MFC, but what's wrong with STL?

Did you actually pay for the crap you got, or can you basically fire the coder & get your money back?

Originally Posted by cpjust

I can see why you wouldn't want to use a bloated pig like MFC, but what's wrong with STL?

Personal preference. A lot of the programming I do is very low level, high performance, or real time applications. I guess ive just never seen the point of STL when its so much better and easier (at least for me) to implement the functionality explicitly. Case in point, vector, ok im sorry but this is just an array.

Code:

vector<int> v(3);

int v[3];

There is no difference. Except that the STL method is a little more wordy.

The methods you can use are nice, but honestly, how difficult is it to implement the reverse function, unless i guess you've never done it before. And what happens when you want the reverse function to do some special method of sorting while its reversing, well, then the STL just chokes and you end up using it just like an array.


Don't get me wrong, I'm not saying that templates arent useful to some programmers. I don't like it, I don't want it in my code. It was a fairly straight forward requirement. Given the fact that there is absolutely no need for the STL in the code I requested it really wasn't unreasonable. The fact that he didn't even USE any of the methods made it clear that he either didn't read the requirements or just ignored them.

Did you actually pay for the crap you got, or can you basically fire the coder & get your money back?

Yeah it ended up working although it was pretty crappy performance and sloppy coding. The project requirements needed to be met, as long as we had a working prototype by the deadline we were fine, I could always fix the code in the next phase. I may not be the greatest programmer that ever lived, or have the fancy CS degree that a lot of other software engineers have (my degree is in electronics engineering), but I always get the job done no matter what it takes and I have been working with computers for nearly 30 years. I started teaching myself assembly when I was 10 years old. I have always had a knack for computers.

Originally Posted by abachler

Case in point, vector, ok im sorry but this is just an array.
(...)
There is no difference. Except that the STL method is a little more wordy.

Actually, there is a difference in that a std::vector can be resized, but an array cannot. The actual equivalent (still as wordy) is:

Code:

std::tr1::array<int, 3> v;

The difference would be that this array object "knows" its own size, and is not converted to a pointer to a pointer to its first element unless explicitly requested.

Originally Posted by abachler

The methods you can use are nice, but honestly, how difficult is it to implement the reverse function, unless i guess you've never done it before.

Agreed, but then these algorithms are convenient and there is less chance of a silly bug in well tested code that has already been written (and thus code that you do not need to write).

Originally Posted by abachler

And what happens when you want the reverse function to do some special method of sorting while its reversing, well, then the STL just chokes and you end up using it just like an array.

hmm... wouldn't that be sorting instead, and hence std::sort could be used with say, a custom predicate?

Originally Posted by abachler

The methods you can use are nice, but honestly, how difficult is it to implement the reverse function, unless i guess you've never done it before.

Using that logic, why bother using any of the standard functions when you can just implement the entire C library yourself?

Originally Posted by cpjust

Using that logic, why bother using any of the standard functions when you can just implement the entire C library yourself?

I do see your point. If the end result is ending with our own library as opposed to using the standard library... where is the gain?

But careful
Some standard functions deserve just that. atoi and atol comes immediately to mind. Really ugly logic in these two.

Code:

int atoi(const char *str);

Really is bad design. Exactly the type of thing we are told not to do. I'd rather have something like the following so that proper error handling could be implemented.

Code:

int atoi(int *result, const char *str);

The function return value could then be used to diagnose the success of the conversion, while int *result would point to the actual conversion value.

I wouldn't go that far.

The problem with strtol is that errno is not set if the function succeeds. So you again cannot rely on it for proper error handling on the case of 0.

Use case:
1. Input: "hello" -> strtol fails. errno is set to EINVAL. Function returns 0
2. Input: "0" -> strtol succeeds. errno remains at EINVAL. Function returns 0.

Originally Posted by Mario F.

I wouldn't go that far.

The problem with strtol is that errno is not set if the function succeeds. So you again cannot rely on it for proper error handling on the case of 0.

Use case:
1. Input: "hello" -> strtol fails. errno is set to EINVAL. Function returns 0
2. Input: "0" -> strtol succeeds. errno remains at EINVAL. Function returns 0.

You are allowed, and encouraged, to clear errno before calling a function if the only way to determine failure is by examining errno. Not exactly elegant, but it does work.

Originally Posted by brewbuck

You are allowed, and encouraged, to clear errno before calling a function if the only way to determine failure is by examining errno. Not exactly elegant, but it does work.

Yes but the real stupid part about strtol() is that it only sets errno for certain kinds of errors:

If the string is empty, contains only whitespace, or does not contain an initial substring that has the expected syntax for an integer in the specified base, no conversion is performed. In this case, strtol returns a value of zero and the value stored in *tailptr is the value of string.

Notice it does not say it will throw an error for this, and in fact it does not. What it throws an error for is this:

If the string has valid syntax for an integer but the value is not representable because of overflow, strtol returns either LONG_MAX or LONG_MIN (see Range of Type), as appropriate for the sign of the value. It also sets errno to ERANGE to indicate there was overflow.

So in other words, feed it a bad string and errno is not changed, feed it too large a number and that is an errno error. strtol() never sets EINVAL -- you are supposed to detect invalid input using the return value and *tailptr.

strtol() is better than atoi() but still an unnecessary hassle with the error checking.

Yes but the real stupid part about strtol() is that it only sets errno for certain kinds of errors

As it should. You are suggesting there be a errno definition for bad strings (moreso than there already is) but that would require specification for what a bad string is in the standard. They could have easily gone with the simplistic "If conversion doesn't stop at '\0' then EBADSTRING is stored in errno..." You'd still have to do a fair bit of cooking your input to work with this particular verse. With that being the case, I imagine if it was debated at all, that the standards committee decided that the right thing was to let the programmer specify and check accordingly, through endptr.