Algoritms

[Loren Pechtel]

The first version would get you tarred and feathered in a code review. Never thought of doing the latter with an and, it's normally done with subtraction.

The first method is bullet proof and portable. It should work on any compiler. The second method should work but I am not set up to run it.

My largest project was around 10,000 lines of code. Isuues of mainyainablity and readability matter.

For someone later on getting into the code the first method would be obvious to read and understand. I new of situations when people left a company code had to be compely rewritten. I had someone under me on a project who left the company and I had to rewrite from scratch.

If the problem is readability, then surely the solution is comments?

For example:

/**
 * Converts a digit character (0 to 9) to an integer. Assumes ASCII or Unicode encoding.
 *
 * @return int the integer represented by the given character. Returns -1 if the character is not a digit
 */
int text2int(char text_digit)
{
    // If the given char is actually a digit...
    if(text_digit >= '0' && text_digit <= '9') 
        // ...then use a bitmask to get its value as an integer and return it as an int.
        // @see http://www.asciitable.com
        return text_digit & 0x0f;

    return -1;
}

Disclaimer: I'm not competent in C.

I rely on open-source software to build websites, so I have to read a lot of other people's code. I actually do far more code-reading than code-writing. If the comments tell me what an algorithm is doing at each statement or block, I can understand it what it does without immediately understanding the code's logic.

Comments also help people find bugs, because it makes it easy to see when a algorithm doesn't do what the author says it does. I've had to bughunt in code I wrote years ago and I don't remember what I was thinking when I wrote it.

Actually, in most cases I'm opposed to comments. The problem is they don't always accurately describe what's going on. I much prefer making the names in the code so clear there's no need of a comment--I actually regard a comment describing what's happening as a bit of a code smell. Comments describing something external to the code are another matter, I'm quite willing to use them then.

 

[steve_bank]

The first method is bullet proof and portable. It should work on any compiler. The second method should work but I am not set up to run it.

It's usually done by subtracting an ascii 0, that makes it very clear what is going on.

My largest project was around 10,000 lines of code. Isuues of mainyainablity and readability matter.

What's open in Visual Studio right now is 33k lines of code. My largest I would guess was upwards of 200k.

The only difference between the two methods would be the number of assembly language instructions the compiler generates and hence speed of execution, possibly.

And speed of loading the program.

I took FORTRAN in the 70s. The teacher walked into the class and wrote on the board KISS, and said 'Keep It Simple Stupid'.

Being clever can be counter productive. Adds time to try and always minimize lines of code.

Ipetrich has the right idea, explore. It improves your skill even if it is not the best.

I do agree that being too clever can be counterproductive. I find myself avoiding some of the fancy C# features for this reason. I just don't think the one line version is being too clever if it's done by subtraction. The and version is unnecessarily clever.

This thr4ad is mostly for fun. I spent 30 years in completive often cut throat environments. If you want to get into knock down drag out arguments go for it. Been there done that.

As to comments I generally adhere to structured programing. As much as possible self documenting as well as puffiest comments that would allow an experienced person to follow.

As to 36 k lines, if you are using any MS tools the line count gets inflated by the added code for windows. Before the Visual Studio tools you had to write code for GUI and other functions from scratch and know the foundation classes. MS automated and simplified code development for windows. The expense is larger code size, but with modern PC memory that was no longer a problem.

You have to explain what you mean by a 200k line project. That would be a lengthy project for 1 person.

I developed hw and sw for automated test systems. I ended up writing a small OS shell with a command line interpreter and GUI from scratch along with other features. 10k lines is around 200 printed pages. The national average for number of debugged lines of code per day was not very high. Something like 20 lines per day. The average when I worked at Lockheed was less. The project ran about a year start to finish.

Easy to scribble 100 lines of code. Much harder to write, debug, and integrate larger numbers.

I started with C an switched to C++ when it became complicated.

Good [programing dictates each function captains some pseudo code and a description of the variables.

I did not write software but I worked in avionics. Very strict documentation requirements and software design standards, they came into being as code grew. Commercial companies have adopted software development standards because it can be required internationally and it reduces overall software costs..



If you attempt to write 36k lines of code without any structure and documentation it will not be maintainable, it will be buggy, and difficult to debug.

I wrote 10k lines of code. Not inflated by windows.

 

[steve_bank]

Don't know what Loren means by C++ stinks. Aida another OOP used in Avionics. In the 80s the DOD had a competition between C++ and Aida, and selected C++.

Structured vs OOP is another thread.

 

[Loren Pechtel]

As to 36 k lines, if you are using any MS tools the line count gets inflated by the added code for windows. Before the Visual Studio tools you had to write code for GUI and other functions from scratch and know the foundation classes. MS automated and simplified code development for windows. The expense is larger code size, but with modern PC memory that was no longer a problem.

Might be, I didn't look to see if it was counting the designer files. I just asked the code analytics how many lines.

You have to explain what you mean by a 200k line project. That would be a lengthy project for 1 person.

That was many years of work.

If you attempt to write 36k lines of code without any structure and documentation it will not be maintainable, it will be buggy, and difficult to debug.

Structure, yes.

I just believe the careful use of names is in almost all cases superior to comments.

 

[lpetrich]

I'm using C++ instead of plain C, because C++ has some nice type-safe alternatives to the C preprocessor, alternatives that are much less bug-prone.

Yup. I've long said that programs, like ships, sink in the C.

Cute. On the other side, I once saw "C++ is to C what lung cancer is to lung". I've seen some people praise plain C as a very small programming language, one whose features can easily be memorized.

Here are some examples of C-preprocessor bugs.

With
#define INVERT -1

INVERT*INVERT gets expanded to -1*-1 which the compiler will say is nonsense.

But with
const int INVERT = -1;

INVERT*INVERT gets expanded to (-1)*(-1) -- much better

To define taking a square, one can do
#define SQUARE(x) x*x

But that is vulnerable to substitution bugs.

SQUARE(-3)
expands to
-3*-3
which is nonsense.

One can get around that problem by putting the x's in parens:
#define SQUARE(X) (x)*(x)

Thus,
SQUARE(-3)
expands to
(-3)*(-3)
which is much more sensible.

But if evaluating the arg has a side effect, that will be done twice. SQUARE(x++) will autoincrement x twice.

C++ template functions get around this difficulty nicely, and they can easily be specialized to whatever data type supports binary *.
template <class X> X SQUARE(X &x) {return x*x;}

The & means "reference", and it is a sort of hidden pointer. It is a good way of avoiding making copies of objects, what would happen without it.

 

[Loren Pechtel]

I'm using C++ instead of plain C, because C++ has some nice type-safe alternatives to the C preprocessor, alternatives that are much less bug-prone.

Yup. I've long said that programs, like ships, sink in the C.

Cute. On the other side, I once saw "C++ is to C what lung cancer is to lung". I've seen some people praise plain C as a very small programming language, one whose features can easily be memorized.

Here are some examples of C-preprocessor bugs.

The C preprocessor should be taken out and shot.

And then shot again for good measure.

 

[steve_bank]

When you are up to speed and know the entire C language and the use of all the operaturs you can write code faster with less lines than other languages like Pascal.

C++ came along to address software complexity and design on large multiple programmer projects.

C alone has deficiencies when code gets large. .

Using the full C++ language is not suitable for all projects. For focused one developer code C is fine. If you keep to ANSI C syntax then your code will be portable.

As always with free open source software you get what you pay for.

 

[lpetrich]

One does not have to use *all* of C++. Just whatever one finds convenient in it.

Looking at the above example, why write
#define INVERT -1

when one can write
const int INVERT = -1;

?

 

[steve_bank]

https://stackoverflow.com/questions/4103086/defining-constants-in-c

Learn something new every day.

define and constant are treted differently in C++, looks like it is related to the nature of the C++ object and how data is treated in the object.

Not a bug, it is a feature as it is sometimes said.

In C or C++ where you put the define in the code the preprocessor may not see it before you use it in an expression. The preprocessor goes through top to bottom/ Defines and constants are usually put in an include file with it being listed at the very top of the code file containing main()

 

[steve_bank]

8x8 bit integer multiply

unsigned int 8x8mult(unsigned int a; unsigned int b){

unsigned int mask = 1, accumulator = 0;
int j;
for(j = 0; j <= 7; j++){
if(mask & b) accumulator = accumulator + a;
a<<1;
mask<<1;
}
return(accumulator);
}

 

[Loren Pechtel]

One does not have to use *all* of C++. Just whatever one finds convenient in it.

Looking at the above example, why write
#define INVERT -1

when one can write
const int INVERT = -1;

?

Look how smart I can look with the preprocessor.

If my code is hard to understand it shows I'm a better programmer than you.

 

[steve_bank]

https://en.wikipedia.org/wiki/C++_classes

A short intro to C++. If you are doing a lot of math you can overload existing operators, change usage, along with creating your own operators.

The class is the foundation of C++.

A good reference site.

https://www.tutorialspoint.com/cplu... to the important OOP concept of data hiding.