On the D website, there is an overview of the D programming language which includes a list of C/C++ features that have been deliberately
dropped. My game comprises thinking of your own favourite programming language - be it Perl, Java, Eiffel or Visual Basic - and seeing how many of these features have been 'dropped' from it.
My favourite language is the Object Pascal in Delphi. 'Yes' means 'Yes Pascal doesn't have this feature'.
C source code compatibility - Yes. Wow, gosh.
Link compatibility with C++ - No, can be linked to C++ Builder modules
The C preprocessor - Yes
Multiple inheritance (ie Full not Java-style) - Yes
Namespaces (use modules instead) - Yup
Tag name space - Yup
Forward declarations (compiler searches whole module for name definition) - Nope
Include files - Mostly 'Yes' but a little bit 'No'. Delphi does allow includes, but it doesn't
use them in the C/C++ sense; it imports binary symbol tables like D. Score
1/2.
Creating object instances on the stack as opposed to the heap - Yes, dropped when Turbo Pascal
became Delphi
Trigraphs and digraphs - Yes
Preprocessor - Yes
Non-virtual member functions - No, but the Delphi syntax copes better than C++ with the cited
problem (no error messages when you fail to supply a virtual base class)
by using an extra keyword - override - to signal programmer intent. Score 1/2.
Bit fields of arbitrary size - Yes
Support for 16 bit computers - I suppose 'No' since Delphi 1 was 16-bit.
Mutual dependence of compiler passes - I think 'Yes', but I am out of my depth
Compiler complexity - Probably Yes - deduced from Object Pascal's fast compilation. Besides everything
is less complex than C++.
Distinction between . and
->. Yes - uses only '.' operator.
It seems that - notwithstanding the release of Kylix - not so many people around here are familiar with the Delphi scene. A feature that has distinguished it from its Microsoft competitors is that it is very easy to write good object-oriented components for it. Partly because of this and partly because there is a good 'Delphi scene', for many years there have been large numbers of free Pascal libraries and componenets on the Web. You'll find many of them catalogued on sites like the Polish Delphi Super Page and the Russian Torry's Delphi Pages, as well as the inevitable SourceForge.
In this environment, all software houses that make Delphi components have struggled to make money. Only the very best have survived - who is going to pay money for a slightly dodgy replacement tree control when the slickest, fastest one available is an Open Source freebie?
TurboPower was originally the most innovative of companies, and even if it had lost its way a bit in recent times its passing as a Delphi component vendor is an occasion for regret. You'll find any number of free Delphi libraries for doing serial comms; I suspect that only TurboPower's includes a complete terminal emulator with its own scripting language, and only TurboPower's that includes a fully-fledged fax modem driver complete with all the very tedious stuff to encode and decode Fax TIFF files. All this conscientiously and beautifully documented. There are many other examples of excellence in TurboPower's large range.
I don't claim there is any reason why all this shouldn't have evolved in an Open Source environment. But AFAIK it hasn't. If the success of Delphi as a tool for Open Source development means that companies such as TurboPower can no longer survive, then I think long term all Delphi (and Kylix) programmers will be much the poorer for it.
I think I can throw the light of experience on this because we have just interviewed a recent graduate of Teeside - the University that is running the games programming course - for a general programming job. We are a small consultancy working with real time and embedded systems; to some extent we were looking for C++ and/or Delphi expertise, but most of all a demonstrable interest in programming and some nous.
The candidate explained that, although he had not been on the games programming course - I believe it starts this year - the Computer Science department at Teeside were being restructured ahead of the planned change, and this was reflected in the content of the units he had taken. Although C++ and Java appeared on his CV (as they do on all CVs I see), a little questioning showed that he knew virtually nothing about these languages. Not did he know anything about OO design and analysis, patterns, genericity, UML... He knew nothing at all about SQL except from what he had taught himself building a CD database in Access (for which points to him). His OS knowledge seemed essentially DOS-based with a smidgeon Windows.
On the other hand, he did know how to wire up a joystick, claimed to have extensive knowledge of various graphics APIs (DirectX, OpenGL), 8086 (but not 80386) assembly language. A test showed him to be a competent C programmer. He said he knew something about how one designed games for playability, for which I took his word.
He seemed surprised by my line of questioning (I got the impression we were one of his first interviews). He said that the C++ course teacher hated the language pasionately, and had encouraged the same attitude in his students.
Sadly we weren't able to make him an offer - we are very small and unable to take a risk on somebody so narrowly edcuated. I dare say a larger company will take the risk - and he may well turn out to be an excellent person and an asset. Good luck to him.
But this graduate, it seems to me, has been very poorly served by Teeside, and that institution would do well to review the direction in which it is headed. I'm sure it will be able to attract plenty of candidates to this course - but surely that is not the point.
Slashdot Mirror
- C source code compatibility - Yes. Wow, gosh.
- Link compatibility with C++ - No, can be linked to C++ Builder modules
- The C preprocessor - Yes
- Multiple inheritance (ie Full not Java-style) - Yes
- Namespaces (use modules instead) - Yup
- Tag name space - Yup
- Forward declarations (compiler searches whole module for name definition) - Nope
- Include files - Mostly 'Yes' but a little bit 'No'. Delphi does allow includes, but it doesn't
use them in the C/C++ sense; it imports binary symbol tables like D. Score
1/2.
- Creating object instances on the stack as opposed to the heap - Yes, dropped when Turbo Pascal
became Delphi
- Trigraphs and digraphs - Yes
- Preprocessor - Yes
- Non-virtual member functions - No, but the Delphi syntax copes better than C++ with the cited
problem (no error messages when you fail to supply a virtual base class)
by using an extra keyword - override - to signal programmer intent. Score 1/2.
- Bit fields of arbitrary size - Yes
- Support for 16 bit computers - I suppose 'No' since Delphi 1 was 16-bit.
- Mutual dependence of compiler passes - I think 'Yes', but I am out of my depth
- Compiler complexity - Probably Yes - deduced from Object Pascal's fast compilation. Besides everything
is less complex than C++.
- Distinction between . and
->. Yes - uses only '.' operator.
So 13/17. Better offers?It seems that - notwithstanding the release of Kylix - not so many people around here are familiar with the Delphi scene. A feature that has distinguished it from its Microsoft competitors is that it is very easy to write good object-oriented components for it. Partly because of this and partly because there is a good 'Delphi scene', for many years there have been large numbers of free Pascal libraries and componenets on the Web. You'll find many of them catalogued on sites like the Polish Delphi Super Page and the Russian Torry's Delphi Pages, as well as the inevitable SourceForge.
In this environment, all software houses that make Delphi components have struggled to make money. Only the very best have survived - who is going to pay money for a slightly dodgy replacement tree control when the slickest, fastest one available is an Open Source freebie?
TurboPower was originally the most innovative of companies, and even if it had lost its way a bit in recent times its passing as a Delphi component vendor is an occasion for regret. You'll find any number of free Delphi libraries for doing serial comms; I suspect that only TurboPower's includes a complete terminal emulator with its own scripting language, and only TurboPower's that includes a fully-fledged fax modem driver complete with all the very tedious stuff to encode and decode Fax TIFF files. All this conscientiously and beautifully documented. There are many other examples of excellence in TurboPower's large range.
I don't claim there is any reason why all this shouldn't have evolved in an Open Source environment. But AFAIK it hasn't. If the success of Delphi as a tool for Open Source development means that companies such as TurboPower can no longer survive, then I think long term all Delphi (and Kylix) programmers will be much the poorer for it.
I think I can throw the light of experience on this because we have just interviewed a recent graduate of Teeside - the University that is running the games programming course - for a general programming job. We are a small consultancy working with real time and embedded systems; to some extent we were looking for C++ and/or Delphi expertise, but most of all a demonstrable interest in programming and some nous.
The candidate explained that, although he had not been on the games programming course - I believe it starts this year - the Computer Science department at Teeside were being restructured ahead of the planned change, and this was reflected in the content of the units he had taken. Although C++ and Java appeared on his CV (as they do on all CVs I see), a little questioning showed that he knew virtually nothing about these languages. Not did he know anything about OO design and analysis, patterns, genericity, UML... He knew nothing at all about SQL except from what he had taught himself building a CD database in Access (for which points to him). His OS knowledge seemed essentially DOS-based with a smidgeon Windows.
On the other hand, he did know how to wire up a joystick, claimed to have extensive knowledge of various graphics APIs (DirectX, OpenGL), 8086 (but not 80386) assembly language. A test showed him to be a competent C programmer. He said he knew something about how one designed games for playability, for which I took his word.
He seemed surprised by my line of questioning (I got the impression we were one of his first interviews). He said that the C++ course teacher hated the language pasionately, and had encouraged the same attitude in his students.
Sadly we weren't able to make him an offer - we are very small and unable to take a risk on somebody so narrowly edcuated. I dare say a larger company will take the risk - and he may well turn out to be an excellent person and an asset. Good luck to him.
But this graduate, it seems to me, has been very poorly served by Teeside, and that institution would do well to review the direction in which it is headed. I'm sure it will be able to attract plenty of candidates to this course - but surely that is not the point.