c vs c++

[Rein Halbersma]

There are many other places where explicit loops and comparisons could be eliminated by proper usage of the <algorithm> part of the STL.

Of course the downside of this approach is that you have to use the STL.

Random example #1: STL container types are heavily templated, causing lots of generated code bloat in a large program that uses vector<> or other containers over lots of different types. I've seen large codebases that contained instantiations of vector<> for hundreds of different types, adding up to several megabytes of generated code. On some platforms you just cannot afford this. Even on PCs with abundant RAM and virtual memory, more code still means more page faults, or at least more icache misses. To avoid this penalty, we use our own container class implementations that are compatible with <algorithm> etc. but were designed to keep generated code size to a minimum while still being reasonably efficient.

This kind of vector bloat can only happen if you use vector<T*> for many different T types and if your STL implementation does not provide a wrapper around vector::<void*> for all these types (see the example in Stroustrup's book). I have never experienced such bloat with a decent compiler and STL implementation (MSVC and gcc).

Writing your own containers is no picknick either, and a source of many bugs if you are not very careful. I had written my own Array template class to store fixed-size move lists and it took a lot of effort to get it 100% right. Later I discovered that std::tr1::array provided the same functionality and I replaced my Array without any problems and eliminated a few 100 lines of code with it.

Code reduction and more abstract code is simply more maintainable and more bug-free than do-it-yourself containers and algorithms, and almost always more efficient as well.

[SuneF]

Hi again
I was thinking which language is fastest at chess programming, c or c++ ?
I think it would be possible to make a c++ version of micromax and test result, or making a c version of stockfish
regards
Ethan Ara

If you're only interested in speed, I guess there is no difference if done right.

C++ offers several advantages though, most notably the large STL library which is like a great toolbox of highly tuned collections and algorithms but also it gives you inheritage, templets, operator overloads and so on.
C++ is object orientated whereas C is a more simple procedural languange.

However both C and C++ are very old languages, they are fast, compiling directly to ISA level but very primitive.
Modern languages today offer reflection, garbage collection, threading, parallel for-loops, LINQ, contra- and covariance, webservices and libraries that dwarfs STL.

Conclusion:
If you're about to learn a new language, don't let it be C. It's old, limited, outdated in its design paradigm and the syntaks is horribly bloated.

If you're only interested in creating the strongest world beating chess engine and you have the next 5-10 years to work fulltime on it, then use C++, it's more powerful than C, just as fast and has more modern feel to it.
Oh and btw, you will never get there anyway. Your engine will either get reversed engineered or some clone of an open source engine will beat you by 10 Elo.

If you're interested in becomming a proficient versatile programmer then forget C/C++, learn a modern more powerful language. You'll build the engine faster, it'll have fewer bugs, it will be easier to deploy on different platforms and you'll have learned a language you can actually use for developing other applications.

[WinPooh]

Also, and contrary to popular belief, there nothing C++ can do that C can't do.

What about template metaprogramming?
And of course, there nothing C can do that Assembly language can't do.

[Daniel Shawul]

I know the result would be a huge win for c
Last time we had this poll c++ was not invented so c has that 1000 default
vote for being first.
No way c++ would ever compete with that.

[rbarreira]

Modern languages today offer reflection, garbage collection, threading, parallel for-loops, LINQ, contra- and covariance, webservices and libraries that dwarfs STL.

Conclusion:
If you're about to learn a new language, don't let it be C. It's old, limited, outdated in its design paradigm and the syntaks is horribly bloated.

Yes, modern languages have lots of "nice" features. But they also have lots of problems, including portability and efficiency. There is no language which approaches the portability of C. Every serious platform out there has a high-quality C compiler, which means by learning C you'll learn something you can use for a long time.

Bloated syntax? Please... C's syntax is quite minimalist which is the very opposite of bloated.

I would say that everyone should learn C if they don't learn Assembly, in order to learn how computers actually work. Otherwise you'll make programs which run like crap and you won't even know why. That is if you want to be a serious programmer of course... if you just want to make a few simple scripts, learning C is overkill and you should just learn Python or Perl and call it a day.

[wgarvin]

Random example #1: STL container types are heavily templated, causing lots of generated code bloat in a large program that uses vector<> or other containers over lots of different types. I've seen large codebases that contained instantiations of vector<> for hundreds of different types, adding up to several megabytes of generated code. On some platforms you just cannot afford this. Even on PCs with abundant RAM and virtual memory, more code still means more page faults, or at least more icache misses. To avoid this penalty, we use our own container class implementations that are compatible with <algorithm> etc. but were designed to keep generated code size to a minimum while still being reasonably efficient.

This kind of vector bloat can only happen if you use vector<T*> for many different T types and if your STL implementation does not provide a wrapper around vector::<void*> for all these types (see the example in Stroustrup's book). I have never experienced such bloat with a decent compiler and STL implementation (MSVC and gcc).

Writing your own containers is no picknick either, and a source of many bugs if you are not very careful. I had written my own Array template class to store fixed-size move lists and it took a lot of effort to get it 100% right. Later I discovered that std::tr1::array provided the same functionality and I replaced my Array without any problems and eliminated a few 100 lines of code with it.

Code reduction and more abstract code is simply more maintainable and more bug-free than do-it-yourself containers and algorithms, and almost always more efficient as well.

I meant hundreds of actual instantiated types (not pointer types). Part of the reason for using a container like vector<> is so it can manage the lifetimes of the contained objects for you. Maybe games are different from most kinds of software. A modern game engine written in C++ will support thousands of types of objects, and loading something complex (like "a level") can mean loading a graph of hundreds of thousands of small objects of various types. I have seriously seen the compiler vendor's std::vector<> taking up over 25% of the codesize of a 25mb executable. Every AAA engine I've worked with has its own replacements for std::vector, because compiler implementations usually prioritize "speed" over everything else.

Its still a very handy tool to have for most programs; I'm just saying that one size doesn't really fit all.

[rbarreira]

If you're interested in becomming a proficient versatile programmer then forget C/C++, learn a modern more powerful language. You'll build the engine faster, it'll have fewer bugs, it will be easier to deploy on different platforms and you'll have learned a language you can actually use for developing other applications.

So what is this language which allows you to make a chess engine faster, with fewer bugs, more portable and more widely used than C/C++ so that you can later "actually use" it for other development? Do you have a specific example?

[Desperado]

If you're interested in becomming a proficient versatile programmer then forget C/C++, learn a modern more powerful language. You'll build the engine faster, it'll have fewer bugs, it will be easier to deploy on different platforms and you'll have learned a language you can actually use for developing other applications.

So what is this language which allows you to make a chess engine faster, with fewer bugs, more portable and more widely used ... ?

i think it s called " CopyAndPaste+ "

[SuneF]

Modern languages today offer reflection, garbage collection, threading, parallel for-loops, LINQ, contra- and covariance, webservices and libraries that dwarfs STL.

Conclusion:
If you're about to learn a new language, don't let it be C. It's old, limited, outdated in its design paradigm and the syntaks is horribly bloated.

Yes, modern languages have lots of "nice" features. But they also have lots of problems, including portability and efficiency. There is no language which approaches the portability of C. Every serious platform out there has a high-quality C compiler, which means by learning C you'll learn something you can use for a long time.

If you stick to just ansi C it is fairly portable but still in need of special native assemblies as opposed to eg Java. Once you begin with threads or anything requirering 3rd party libs it gets messy.

Bloated syntax? Please... C's syntax is quite minimalist which is the very opposite of bloated.

That's like saying assembly is more minimalistic than C. In some way you'd be right, but what I mean isn't the vocabulary itself, but the size of the code needed.

In C# forinstance you can do:

var numbers = new List<int> { 1,4,5,6,2,1,3,54,6};
numbers.Add(36);
numbers.Sort();

With just those three simple lines you get qsorting and you get a resizable int array. Try writing the C-equivalent of that, it will be huge, and I haven't even mentioned LINQ yet.. It's easier in C++ using STL, but still, neither comes close to C#.

I would say that everyone should learn C if they don't learn Assembly, in order to learn how computers actually work. Otherwise you'll make programs which run like crap and you won't even know why. That is if you want to be a serious programmer of course... if you just want to make a few simple scripts, learning C is overkill and you should just learn Python or Perl and call it a day.

You need to know how pointers, heaps and stacks work sure. You don't need to learn C for that though.

[mcostalba]

That is because your current algorithm is not stable and mine is

Hi Rein,

yes you are right !

This makes to compare speeds a bit more difficult because searched nodes are little different. Under this non-optimal conditions current SF code _seems_ a bit faster of your fastest version, that is the "always swap" one.

It is not self evident to understand why, we have to consider the surrounding conditions in which that code is used:

1) It is manly used only for captures that are very few, something from 0 to 4-5 and the code actually kicks in when we have at least 2 captures.

2) The swap is done with a register and very well optimized by the compiler

3) std::max_element() is a function, is not inlined and so there is some overhead there.

4) Pointers are a little slower than values, for instance I have tried to change current SF version using Move* bestMovePtr instead of Move bestMove and results are slightly slower.

So overall I think your idea is good, but possibly it needs further tuning work.

Marco

P.S: std::swap() uses some ad-hoc gcc magic (_GLIBCXX_MOVE) that probably is faster then the usual tmp way. On MSVC instead the swap is implemented with the usual algorithm you can find in current SF.