Should we follow standards? Do you follow?

[earlz]

I follow the standards that don't get in my way... I use to declare variables all in the upper block of a function.. but C++ broke me from that.... (although I am trying to correct that bad habit of mine in C)

I think /**/ comments are clunky for one-liners so // is fine. It's included in C99 anyway...

Recently I have begun trying to stick to standards enough so that my code compiles with gcc and pcc. This included some weird __packed handling macros though(which some might consider a hack).

[rant]
Trying to follow strict C++ orthodoxy is just insane. For instance, what about command line arguments? like

Code: Select all

MyFileClass myfile;

int main(argc,argv){
myfile.load(argv[1]);
}

That according to some people would be bad C++ coding. Because myfile can be accessed before it is constructed. The only "correct" solution is

Code: Select all

int main(argc,argv){ //I'm lazy rofl
MyFileClass myfile(argv[1]);
}

or

Code: Select all

MyFileClass *myfile;
int main...
myfile=new MyFileClass(argv[1]);
}
[/code

The error of that code though is that now to use myfile, you must pass it to every function. A few extra pushes per function in a loop though can have a rather big performance penalty. Can even mean about 10000 extra instructions that are NOT necessary. Not to mention the overhead of mov [ebp+xxx],xxxx. displacements cost clock cycles. I ran into this problem when making my x86 emulation project in C++. When changing from an "improper" global CPU class to a "proper" local CPU class(passed on stack) I saw a loop of 5 instruction executed about 0xFFFF times, slow down by about 5 seconds.

The problem with the pointer version of that code is now you must use the clunky "->" convention. Which also means more indirection and more memory accesses, which would have the same problem as the local version.


It is for this reason, I no longer use C++... C++ is built for people wanting fastly developed code, not necessarily the fastest code, C is built to work anywhere and as fast as you would like to optimize it for. 


[/rant]

[ucosty]

[rant]
Trying to follow strict C++ orthodoxy is just insane. For instance, what about command line arguments? like

Code: Select all

MyFileClass myfile;

int main(argc,argv){
myfile.load(argv[1]);
}

That according to some people would be bad C++ coding. Because myfile can be accessed before it is constructed.

Not true at all. Global objects, like myfile in your example, have their constructors run before main() is run.

http://www.yancy.org/research/library_m ... node4.html

Code: Select all

#include <iostream>
using namespace std;

class MyTestClass {
public:
	MyTestClass();
	~MyTestClass();
	
	void TestFunction();
};

MyTestClass::MyTestClass() {
	cout << "MyTestClass constructor called" << endl;
}

MyTestClass::~MyTestClass() {
	cout << "MyTestClass destructor called" << endl;
}

void MyTestClass::TestFunction() {
	cout << "!! Test Function !!" << endl;
}

MyTestClass testClass;

int main(int argc, char *argv[]) {
	cout << "main() has started..." << endl;
	testClass.TestFunction();
	cout << "main() is finished!" << endl;
	return 0;
}

The example above produces the following output

Code: Select all

MyTestClass constructor called
main() has started...
!! Test Function !!
main() is finished!
MyTestClass destructor called

This clearly shows the constructor running before main() is called.

[quok]

I personally don't think unit tests are a useful form of testing, especially for OS development where the modules are so dependent. Getting a unit test set up with a simulated environment is a lot of effort and, again, you have to test the correctness of your simulation. Does that call for a unit test too?

Testing some core classes like containers, string, etc, which are quite easy to test with a simple set of input data but ensures correct operation of other classes that build on these basic structures is quite a good move. And it actually saves you quite a bit of time and nerve when you know that it's not your linked list implementation that is suddenly incorrect, it is something else.

Actually, JamesM wrote that, not me. Please quote correctly.

[madeofstaples]

I am an inventor, not an engineer. I scoff at engineers.

Unless you have some strange notion of what an engineer is (which is probably the case, since it seems implied that engineers are not inventive), there's a bit of irony in scoffing at the people who've made it possible for you to announce on a public forum that you scoff at them.

If you always follow the standards, you will never ever discover a significantly better way of doing anything.

What do you mean? If you can find an objectively better way of doing something which requires you to break the standards, that would probably be grounds for proposing a change in future standards. If you just mean "significantly better" in the sense of "I like it better," then that seems rather arbitrary, and the only difference between writing code in the way you like and implementing the same algorithm in compliance with standards is that the standards-compliant code is guaranteed to compile correctly among future versions of the compiler.

The reason the shortcuts exist in the first place is that programmers who are willing to experiment a little have found those shortcuts to be a significant improvement to the code, in some way.

Well, it depends to which "shortcuts" you are referring; some shortcuts may be functionality supported by a specific compiler (usually with a corresponding command-line switch to enable/disable the feature), but other shortcuts may just be an error in the compiler--some small implementation detail. The second type of shortcut is the more dangerous, because when the error is fixed, your code breaks. The first type of shortcut is usually okay if you don't care about other compilers at least for the time being, and if it's a good enough feature, it will probably find its way into a standard by means of a proposal (which, get this, must follow technical writing standards).

Religiously avoiding them is pedantic and shortsighted.

Pedantic, maybe, but shortsighted? Recall that standards-compliant code is guaranteed to compile correctly (barring any compiler bugs, of course).

In a programming language, there are only two ways to do anything: The correct one, and all the others.

No, there are a million ways of doing everything. 99.9% of it comes under the header of "individual taste". What some committee considers "wrong" is just a matter of the personal tastes of a majority of the people who happened to muscle their way onto the committee. To follow blindly is to be a sheep.

I think there's a bit of a disconnect between you and Solar here. A computer scientist/engineer not following standards is akin to a lawyer composing a legal document which contains typos, slang, invalid grammatical constructs, etc. Sure it may be possible to derive what the lawyer probably meant, but some is left to interpretation, to say the least.

And because they were good, they were accepted into the standard (like // was).

Until enough programmers break the rules, no change ever gets added to the standard. You argument is circular, and therefore irrational.

Not true; it's not until a (common) problem is found that cannot be satisfied by the current standards. For example: variadic templates are supposed to be added to the C++0x standard, not because some rebellious programmers demand it, but because there are some problems that require very messy (often incomplete) solutions without variadic templates (e.g, boost::bind).

[stephenj]

The field of software engineering contains a frightening amount of dogma. At least formal engineering. Whenever I find myself in the company of formal software engineers, I find it difficult to shake the "used car salesman" vibe.

I once worked for a CMMI level 5 company. If you haven't had the pleasure, the focus is on process rather than results.

I have plenty of CMMI level 5 stories, and my SE prof was an IBM vet to boot... His horror stories (some weren't meant to be horror stories), on top of mine nearly scared me out of the field.

That being said, I don't have any problem with people following a system of best practices when it comes to developing. There are legitimate best practices, and it would be wrong of me not to mention that. But the term "software engineering" is so ambiguous I tend to avoid it.

[Solar]

What some committee considers "wrong" is just a matter of the personal tastes of a majority of the people who happened to muscle their way onto the committee.

Having worked several years with someone who is on the C++ committee, I can assure you neither he, nor anyone he knows of, "muscled his way into the committee". He's also the most competent C++ coder I have met so far, and knows more about the problems in C++ than I know about its features.

And one of his favourite pranks is to challenge a C++ coder to write a fully standard-compliant "Hello World". 90% (!!!) of the people fail that little test, because they are too lazy to ever have learned the language correctly. I came close, I made only one mistake instead of the usual 2-3...

If you know the language and do things non-standard because you have a reason, that's OK with me. I just dare anyone to show me a piece of code where non-standard coding is required to get a (defined) result.

Because undefined behaviour might format your hard drive...

To follow blindly is to be a sheep.

To break away without a reason is to be a sheep that's in for a rude surprise when the wolves come out.

Strictly follow K&R standards if you want to write REAL C.

"K&R" isn't a standard. ISO/IEC 9899:1999 is.

Until enough programmers break the rules, no change ever gets added to the standard. You argument is circular, and therefore irrational.

Yours, too.

[Colonel Kernel]

I like having only one standard to follow: The one overwhelmingly popular implementation of the language and runtime (C# on the CLR). It's much easier. Portability is really, really hard, and after 8 years of dealing with it I'm happy to get a break.

As for my kernel, I have no problems using gcc-specific features. I have no plans to port it to a different compiler... I will probably re-write it in another language first.

[quok]

As for my kernel, I have no problems using gcc-specific features. I have no plans to port it to a different compiler... I will probably re-write it in another language first.

I really really want to be able to compile my kernel with LLVM/clang and PCC, however both of them lack some GCC specific features that I'd really like to use. They also have different syntaxes for some of the same features that are are compiler-dependent (ie, not language specified), so what I ended up doing was implementing <quokos/compiler.h>, which detects which compiler is being used and #defines compiler-specific syntaxes to a common syntax that I can use in my code.

The only other sticking point here is different command-line arguments for enabling all the warnings and optimizations that I want. That makes a mess out of the Makefiles, unfortunately.

[earlz]

[rant]
Trying to follow strict C++ orthodoxy is just insane. For instance, what about command line arguments? like

Code: Select all

MyFileClass myfile;

int main(argc,argv){
myfile.load(argv[1]);
}

That according to some people would be bad C++ coding. Because myfile can be accessed before it is constructed.

Not true at all. Global objects, like myfile in your example, have their constructors run before main() is run.

http://www.yancy.org/research/library_m ... node4.html

Code: Select all

#include <iostream>
using namespace std;

class MyTestClass {
public:
	MyTestClass();
	~MyTestClass();
	
	void TestFunction();
};

MyTestClass::MyTestClass() {
	cout << "MyTestClass constructor called" << endl;
}

MyTestClass::~MyTestClass() {
	cout << "MyTestClass destructor called" << endl;
}

void MyTestClass::TestFunction() {
	cout << "!! Test Function !!" << endl;
}

MyTestClass testClass;

int main(int argc, char *argv[]) {
	cout << "main() has started..." << endl;
	testClass.TestFunction();
	cout << "main() is finished!" << endl;
	return 0;
}

The example above produces the following output

Code: Select all

MyTestClass constructor called
main() has started...
!! Test Function !!
main() is finished!
MyTestClass destructor called

This clearly shows the constructor running before main() is called.

now pass a command line argument from main() into a global constructor.

[clange]

And one of his favourite pranks is to challenge a C++ coder to write a fully standard-compliant "Hello World". 90% (!!!) of the people fail that little test, because they are too lazy to ever have learned the language correctly. I came close, I made only one mistake instead of the usual 2-3...

Could you please share the correct solution. I'm very curious since I definitely do not know C++ well enough yet . I remember reading about how to implement the true command (http://en.wikipedia.org/wiki/True_(Unix)) in a portable way and the result was much more complex than expected

I personally try to follow standards. Having support for libc and POSIX and STL will make it much easier to port existing software to your own system. I consider libc and STL to be mandatory (if you develop in C or C++, other languages will have other equally obvious libraries to support). I decided to implement a sort of POSIX compatibility layer to expose my OS's functionality to user space programs. This has many benefits: you don't have to make an effort to come up with your own library (someone else has been thinking long and hard on how to provide functionality), you can develop user space applications in your normal environment (access to IDE's, debuggers, profilers, etc.), it is easy to implement tests to verify your own library, and (as mentioned above) you can port existing software.

Just my 2c

clange

Edit:

now pass a command line argument from main() into a global constructor.

Hmmmm, how on earth do you expect that this will be possible? Global constructors execute before main(). Isn't this argument a bit silly since you complained about being able to access a object before it is constructed?

[earlz]

Hmmmm, how on earth do you expect that this will be possible? Global constructors execute before main(). Isn't this argument a bit silly since you complained about being able to access a object before it is constructed?

Assuming the programmer knows what he is doing... It should be possible to construct an object before accessing it... like.. I always though references should have been able to be used at the global scope.. A ordered construction at runtime...

[madeofstaples]

Hmmmm, how on earth do you expect that this will be possible? Global constructors execute before main(). Isn't this argument a bit silly since you complained about being able to access a object before it is constructed?

Assuming the programmer knows what he is doing... It should be possible to construct an object before accessing it... like.. I always though references should have been able to be used at the global scope.. A ordered construction at runtime...

Assuming the programmer knows what he is doing, then it follows that he understands that the dynamic linker calls the initialization routine (DT_INIT?) which constructs any objects in the global scope, before calling main.

It sounds like you want to implement a singleton pattern.

[Solar]

And one of his favourite pranks is to challenge a C++ coder to write a fully standard-compliant "Hello World". 90% (!!!) of the people fail that little test, because they are too lazy to ever have learned the language correctly. I came close, I made only one mistake instead of the usual 2-3...

Could you please share the correct solution.

IIRC:

Code: Select all

#include <iostream>
#include <ostream>

int main()
{
    std::cout << "Hello World" << std::endl;
    return 0;
}

The most common mistake is omitting the <ostream> include (which, strictly speaking, is necessary for operator<<() and std::endl, but can be done without on many compilers / libraries). #2 is forgetting the return 0; from main(), #3 is forgetting the std:: prefixes, #4 is using "\n" instead of std::endl. (Don't nail me down on the correct ordering, but you get the idea.)

I am not even sure if the empty parameter list to main() is strictly OK for C++.

[Combuster]

The most common mistake is omitting the <ostream> include

Not to mention that in all my C++ classes, NOBODY mentioned that

And I'd have used "using namespace std;" but I guess that's more a taste thing...

[Solar]

And I'd have used "using namespace std;" but I guess that's more a taste thing...

In a .cpp file, yes. In a .hpp file, you've just changed the namespace for everyone including your header, possibly knocking out user-defined functions with standard ones...

Rule of thumb: Never use "using" in a header file.

And if you're nice to your clients, don't use "using namespace" in a .cpp file, either. With "using <namespace>::<identifier>", people reading your code have a chance to figure out which namespace (and possibly, which library) which identifier came from...