This question relates to
https://stackoverflow.com/questions/9603/what-is-some-great-source-code-to-read
which compiles a list of great (in the sense of readable, elegant, ...) source code.
Part of the learning experience when reading source code is certainly independent of the language but every language has its own ways to do certain things. So in this question, I'm looking for great Delphi code.
What is some great Delphi source code to read and learn from? Any suggestions?
The VCL/RTL itself is a very good example of great delphi code. It is available at your delphi installation folder ($delphi)\source, except for the new Starter edition, which I heard does not include the source code.
My suggestions
All the Jedi projects are very well written JCL (Jedi code library), JVCL, JEDI Windows API Library (Great to learn abot windows api and header conversions).
VCL and RTL Source code.
Virtual Tree View
Well for once, if you ask me, the VCL is fairly well written, and you can learn quite a bit about the Windows API from it.
Then there is the much hyped Delphi Web Script, which sounds rather interesting.
I would also recommend DEHL, which is quite a nice library, and the VirtualStringGrid, as a hugely popular and quite well written, though complex, component.
Then there is the JCL and JVCL, that I would also recommend.
The GExperts sourcecode on sourceforge.
Obvious answer: My sources
http://svn.berlios.de/viewvc/dzchart/utilities/Delphi7Help4Bds/trunk/
http://svn.berlios.de/viewvc/dzchart/utilities/dzAutoSave/trunk/
http://svn.berlios.de/viewvc/dzchart/utilities/dzCmdLineParser/trunk/
http://svn.berlios.de/viewvc/dzchart/utilities/dzLib/trunk/
http://svn.berlios.de/viewvc/dzchart/utilities/dzPrepBuild/trunk/
You saw that coming, didn't you?
Bold for Delphi - Framework, a masterpiece, huge and immaculately designed
StarUML - An UML Editor, wonderful clean design and code
Clever Internet Suite - Communication component set - clean architecture and code, commercial
"Good code" is a rather subjective topic ... everyone has an opinion on what can be considered good/bad code. Readable code might not necessarily be considered effective code, and vice-versa.
If your interest is learning how to create well-written code, you should instead study any code and find out how to improve or fix it. When I was in the Air Force, part of the training I would give my new troops would include them visiting sites like Koders or Sourceforge, where they would download source and analyze for functionality, effective results, coding standards, proper software engineering principles, etc. They would look at the code and answer "how would I do this differently?" This exercise gave them a much better understanding of what well-written code should look like.
My point is, you can't learn how to write "good code" if you don't know what "bad code" looks like.
Related
I've been browsing the DeHL repository on GoogleCode, and it looks really good to me.
Many interesting features that make basic programming tasks easier; Some neat things that are in the DotNet FCL, but are missing from the Delphi RTL can be found in this library;
Coded in a modern way, making good use of new language features;
Each class, record type, member function and parameter is documented in such a way that it'll show in the code completion of the Delphi IDE;
Well-organized and clean code;
Plenty of unit tests;
Open source and Free;
Basically, it looks like this library should've been included with Delphi, as part of the RTL.
One major drawback: The project has been discontinued. :-(
Now my question is:
Would it be safe to rely on this library for future projects, and use it as a base framework to build upon?
Basically I'd like to hear from somebody who's actually used this library whether or not it's worth it to invest time in getting to know this library, and why.
IIRC the project was discontinued because it was an over-engineered first attempt and a lot of its features turned out really messy and bloated. You should look at Alex Ciobanu's second attempt, which is simply called Collections. It contains most of the interesting features from DeHL, but leaner.
Be careful, though. It still makes heavy use of generics, which will make your binary size really big if you use it a lot, because the compiler team hasn't implemented a way to collapse duplicate code yet.
Hopefully this question won't be too convoluted or vague. I know what I want in my head, so fingers crossed I can get this across in text.
I'm looking for a language with a syntax of my own specification, so I assume I will need to create one myself. I've spent the last few days reading about compilers, lexers, parsers, assembly language, virtual machines, etc, and I'm struggling to sort everything out in terms of what I need to accomplish my goals (file attached at the bottom with some specifications). Essentially, I'm deathly confused as to what tools specifically I will need to use to go forward.
A little background: the language made would hopefully be used to implement a multiplayer, text-based MUD server. Therefore, it needs easy inbuilt functionality for creating/maintaining client TCP/IP connections, non-blocking IO, database access via SQL or similar. I'm also interested in security insofar as I don't want code that is written for this language to be able to be stolen and used by the general public without specialist software. This probably means that it should compile to object code
So, what are my best options to create a language that fits these specifications
My conclusions are below. This is just my best educated guess, so please contest me if you think I'm heading in the wrong direction. I'm mostly only including this to see how very confused I am when the experts come to make comments.
For code security, I should want a language that compiles and is run in a virtual machine. If I do this, I'll have a hell of a lot of work to do, won't I? Write a virtual machine, assembler language on the lower-level, and then on the higher-level, code libraries to deal with IO, sockets, etc myself, rather than using existing modules?
I'm just plain confused.
I'm not sure if I'm making sense.
If anyone could settle my brain even a little bit, I'd sincerely appreciate it! Alternatively, if I'm way off course and there's a much easier way to do this, please let me know!
Designing a custom domain-specific programming language is the right approach to a problem. Actually, almost all the problems are better approached with DSLs. Terms you'd probably like to google are: domain specific languages and language-oriented programming.
Some would say that designing and implementing a compiler is a complicated task. It is not true at all. Implementing compilers is a trivial thing. There are hordes of high-quality compilers available, and all you need to do is to define a simple transform from your very own language into another, or into a combination of the other languages. You'd need a parser - it is not a big deal nowdays, with Antlr and tons of homebrew PEG-based parser generators around. You'd need something to define semantics of your language - modern functional programming langauges shines in this area, all you need is something with a support for ADTs and pattern matching. You'd need a target platform. There is a lot of possibilities: JVM and .NET, C, C++, LLVM, Common Lisp, Scheme, Python, and whatever else is made of text strings.
There are ready to use frameworks for building your own languages. Literally, any Common Lisp or Scheme implementation can be used as such a framework. LLVM has all the stuff you'd need too. .NET toolbox is ok - there is a lot of code generation options available. There are specialised frameworks like this one for building languages with complex semantics.
Choose any way you like. It is easy. Much easier than you can imagine.
Writing your own language and tool chain to solve what seems to be a standard problem sounds like the wrong way to go. You'll end up developing yet another language, not writing your MUD.
Many game developers take an approach of using scripting languages to describe their own game world, for example see: http://www.gamasutra.com/view/feature/1570/reflections_on_building_three_.php
Also see: https://stackoverflow.com/questions/356160/which-game-scripting-language-is-better-to-use-lua-or-python for using existing languages (Pythong and LUA) in this case for in-game scripting.
Since you don't know a lot about compilers and creating computer languages: Don't. There are about five people in the world who are good at it.
If you still want to try: Creating a good general purpose language takes at least 3 years. Full time. It's a huge undertaking.
So instead, you should try one of the existing languages which solves almost all of your problems already except maybe the "custom" part. But maybe the language does things better than you ever imagined and you don't need the "custom" part at all.
Here are two options:
Python, a beautiful scripting language. The VM will compile the language into byte code for you, no need to waste time with a compiler. The syntax is very flexible but since there is a good reason for everything in Python, it's not too flexible.
Java. With the new Xtext framework, you can create your own languages in a couple of minutes. That doesn't mean you can create a good language in a few minutes. Just a language.
Python comes with a lot of libraries but if you need anything else, the air gets thin, quickly. On a positive side, you can write a lot of good and solid code in a short time. One line of python is usually equal to 10 lines of Java.
Java doesn't come with a lot of frills but there a literally millions of frameworks out there which do everything you can image ... and a lot of things you can't.
That said: Why limit yourself to one language? With Jython, you can run Python source in the Java VM. So you can write the core (web server, SQL, etc) in Java and the flexible UI parts, the adventures and stuff, in Python.
If you really want to create your own little language, a simpler and often quicker solution is to look at tools like lex and yacc and similar systems (ANTLR is a popular alternative), and then you can generate code either to an existing virtual machine or make a simple one yourself.
Making it all yourself is a great learning-experience, and will help you understand what goes on behind the scenes in other virtual machines.
An excellent source for understanding programming language design and implementation concepts is Structure and Interpretation of Computer Programs from MIT Press. It's a great read for anyone wanting to design and implement a language, or anyone looking to generally become a better programmer.
From what I can understand from this, you want to know how to develop your own programming language.
If so, you can accomplish this by different methods. I just finished up my own a few minutes ago and I used HTML and Javascript (And DOM) to develop my very own. I used a lot of x.split and x.indexOf("code here")!=-1 to do so... I don't have much time to give an example, but if you use W3schools and search "indexOf" and "split" I am sure that you will find what you might need.
I would really like to show you what I did and past the code below, but I can't due to possible theft and claim of my work.
I am pretty much just here to say that you can make your own programming language using HTML and Javascript, so that you and other might not get their hopes too low.
I hope this helps with most things....
I have inherited a legacy app written in C++ (VS2003) MFC that was not updated in years.
I have limited experience in C++, being mainly a Delphi developer. All other apps of the company are written in Delphi.
Going forward, I see a few choices:
1) Keep the app as is and become a C++ MFC developer. But I don't like the idea of using an outdated technology (MFC) for years to come, trying to keep up with new Windows versions and UI standards. It somehow feels like making several steps backwards and I don't think this is the best way to go (?)
2) Convert the app to any modern UI technology offered with C++ and become a C++ developer, but at least using modern technology. Might be a lot of work, not sure.
3) Rebuild the app from scratch in Delphi, where I will be a lot more productive thinking about the future. It's a lot more work right now, but it might pay off later.
Obviously, I personally prefer 3) but I would like to know from your experience which way is the best for the product.
It's a long term decision to make and I will have to stick with it, therefore I don't want to rush into one direction.
(I have intentionally not tagged this question as C++, trying to get answers from Delphi developers in similar situations)
EDIT:
Thanks to all for your answers.
After learning that it is possible to switch to C++ Builder with a MFC application, this seems to be the best solution.
It combines the least amount of modifications to the current app with the possibility to go forward using the VCL for future GUI improvements.
EDIT2:
It's not possible to combine MFC and VCL in one app, therefore C++ Builder won't be an option. (thanks David for pointing this out)
In general everything depends on how complex the application's logic is and what is the projected life time of the application. If it requires maintenance for another 20 years, then
I'd rewrite the UI in Delphi and move the business logic into C++ DLL (for beginning and possibly rewrite it in Delphi either). Then it can turn that the application can be maintained this way for another 10 years and relatively easily ported to other platforms if needed (less work would be required).
This is a hard question to answer generically. Can you provide any more information about your specific app? What sort of technologies does it use? How separated is the UI from underlying layers and logic?
Some general-ish points though:
Rewriting an app is generally a bad idea, for the following reasons:
It's surprisingly hard to get an accurate idea of the requirements. You're sure you know what it does (after all, it's right there in front of you!), but then you release your rewritten app and you get complains that functionality you didn't know was there is missing, that functionality is harder to access if you've changed something, etc.
It introduces bugs. The code, especially if it's old, is full of bugfixes, tweaks, etc. You will lose all that if you rewrite, especially if it's a different language and you can't reuse any code at all.
When using a different UI layer (MFC to something else) separating the UI can be very hard if the app wasn't written well in the first place. You will probably end up doing a lot of refactoring, even if you don't do a complete rewrite and simply move from MFC to 'something else'.
MFC is kept up to date (ish) - there is a MFC Ribbon control, for example, as well as modern controls and Windows 7 support. The least amount of work, probably, would be to upgrade to a modern version of Visual C++ and become a C++ developer. However, you're quite right that MFC is an old technology and is unpleasant to use, not only because of its design, but also because modern form designers etc are great to use.
You're a Delphi developer. Without rewriting the entire thing, you could consider migrating to C++Builder. Consider this:
You can use old versions of MFC with C++Builder. I've never done this, since the VCL is miles ahead, but it's possible and there are a number of people who do it. Check out this forum, for example. (Credit for that link: this thread.)
Once you have your app compiling and working with C++Builder, you can start migrating to the VCL. As a Delphi developer you'll find using this, even with C++, very familiar. It's the same form designer of course, and using it from C++ is pretty simple - it's a different language but code is often line-for-line translatable. Everything you're used to (DFM files, units, event handlers, etc) all translate.
Not only that, but Delphi code can be used in C++ projects. Just add the units to the project, and in your C++ code include the auto-generated unitname.hpp file. You can't (easily) use C++ code from Delphi, but you could create new modules in Delphi and use them from C++. As you do this, more and more of your app will slowly become Delphi code - ie, you don't need to rewrite in a different language all in one go.
As a Delphi developer, I'd suggest going the C++Builder route. Get it working with MFC, and then migrate your windows to the VCL. At that point, you could start rewriting modules in Delphi, or you may find yourself comfortable enough in C++ to continue developing as is.
Edit: I noticed in a reply above you like the idea above of making it a C++ DLL. The link I gave a paragraph or two above of using C++ object from Delphi might be more applicable than I thought. It would fit the RAD Studio (mix of C++ and Delphi) method as well.
Keeping the app as is, tying you to MFC, is likely not very productive - You'll need to learn a GUI toolkit you'll most likely never use for something else (Delphi is great for GUI, MFC doesn't even come close IMO), in addition to a new language.
That leaves you with the choice of rewriting it in a somewhat unfamiliar language using an unfamiliar GUI toolkit, which'll take a lot more time than rewriting it in a familiar language using a familiar GUI toolkit. So you should just get started porting this to Delphi.
Rewriting C++ code in Delphi isn't as easy as you think. A better way to rewrite it is by just redesigning it from scratch, without looking at the old code. Feel free to look how the old application worked, so you can rebuild it. Just don't look at the code. That way, you should get a more modern result.
Of course, if you use the RAD Studio then you have both the C++ as Delphi compiler, thus it should be able to continue to develop the C++ application, although this means you have to learn C++. Then again, any good programmer should be able to just move to another programming language and learn to use it within 2 weeks to a month. C++ can be complex but still, learning C++ and then maintaining the legacy app should take a lot less time than a complete rewrite.
Do keep in mind that any generic C++ application should be able to be compiled for any platform, although the MFC will probably restrict this to just Windows. Still, it's a language that has an even better backwards compatibility than Delphi!
But to keep in mind, will this app run on a different platform in the future? Should it become a .NET application? Or run on Linux? Should it support tablet computers? Android? Your choices today might be outdated again in two years. And since Delphi has a bit uncertain future right now, mostly because C#/.NET became so popular, you might have a more safe bet with C++. Try to replace the MFC libraries with a more modern UI technology, preferably one that's available for multiple platforms, and think very, very well about the future usages of this application.
In general I'd say:
If it's a tiny tool application, and it takes just a couple of days to do a full rewrite: go for it. Don't waste your time creating dll wrappers or to interface with the existing code in other ways. Just do a full rewrite and be done with it.
Otherwise: you'll probably be making changes in one specific area of the application at the time only. Unless the code is a complete spaghetti, you could even get away with making some local changes without fully understanding the implementation details of the rest of the code.
In any case, you need to invest some time into understanding the application and its language + frameworks.
You have a great opportunity to learn C++ and MFC. Take advantage of it. When Delphi goes astray you will have the required knowledge to keep on coding with a language that won't go away so easily, and you can even broaden your development horizons to areas Delphi (and C++ Builder) will never reach. MFC is no more outdated than the VCL is (although I agree the original design is worse).
Good UI programming has nothing to do with the ability to drop controls on a form visually. Many great applications are not built that way. Actually, trying to rewrite it in Delphi could bring you issue in the future, as long as Embarcadero delivers slowly, and without a credible roadmap.
I recommend
1) Keep the app as is and become a C++ MFC developer. But I don't like the idea of using an outdated technology (MFC) for years to come, trying to keep up with new Windows versions and UI standards. It somehow feels like making several steps backwards and I don't think this is the best way to go (?)
Since MFC is well supported and keeps going with the time. MFC is also a what-you'd-call intrusive framework, meaning that the framework dependencies are usually not easily refactored. (The author of CPPDepend published some nice stats on that IIRC, but I can certainly vouch for this from my own experience with large MFC applications).
If you're gonna rewrite to any modern UI framework, don't code the UI in C++ (judging from the fact that Delphi is an option, it is not about realtime visualizations or something like that).
(I'll unask the unasked question here: I you're gonna rewrite, XXXXXXXXXXXXX?) please gentle(wo)men, let's not do the flame
Does the app come with a descent amount of automated tests? If not you're pretty much stuck with option 1 and hope for the best. If there are many tests you can do a lot more with the code without breaking all kinds of things you didn't know were there.
I'm a C++-Programmer. But now i have to learn Pascal/Pascal. Are there any websites, documents around that can teach someone with my knowledge the difference?
It shouldn't be too difficult to pick up. C's design was influenced by ALGOL and Pascal, so the semantics and logical flow are going to be pretty familiar. You can get an overview of the differences between basic Pascal and basic C here.
But you tagged this as Delphi and you mentioned C++, which implies that you'll need information on OOP techniques. Try this article or this one, which compare object-oriented programming in Delphi with C++ and other languages. Both are a bit dated, but most of the basic information in them still applies today.
If you have any specific questions about language features, feel free to ask them here, and welcome to Stack Overflow!
You can check Essential Pascal written by Marco Cantù, is a introduction to the Pascal programming language. you can download a free copy from here.
Another excellent site for beginners, is Delphi Basics, this web site provides help and reference for the fundamentals of the Delphi language. It gives an introduction to the Delphi Object Oriented Language for newcomers.
A website that helped me a lot when I learned Delphi was http://www.delphibasics.co.uk/. I still use it. It presents common methods in a nice way.
You might consider this post on beginner guides to Delphi. It has some good links included that may be rather simplistic for you, but can still take you a long way.
Marco Cantu (mentioned in several answers) also has a book series called "Mastering Delphi." It is a great (maybe only) top to bottom resource. Everything Delphi is in it. But the last edition is for 2005. Four versions of Delphi have been released since. There are a couple of update sheets available from Marco's website (D2006 was mostly a bug fix of 2005). And Marco also has the Handbook series, but that is aimed at people who already know Delphi and are looking for help on the newest improvements.
Personally, Delphi is my favorite language. I hope you enjoy it!
your name sounds german so you might wanne check these pages out
delphipraxis
it's not really a comparison for cpp and delphi/pascal but you'll find a lot of information
due to me being a new user i'm not able to post a second link. but search google for delphi forum..
The Free Pascal documentation is another great resource:
http://www.freepascal.org/docs.var
If you had a differential of either venturing into Delphi land or Qt land which would you choose? I know they are not totally comparable. I for one have Windows development experience with Builder C++ (almost Delphi) and MFC (almost Qt), with a bit more time working with Builder C++. Please take out the cross platform ability of Qt in your analysis.
I'm hoping for replies of people who have worked with both and how he or she would compare the framework, environment, etc.?
Thank you in advance for your replies.
If you are talking UI frameworks, then you should be comparing Qt with the VCL, not the IDE (Delphi in this case). I know I'm being a stickler, but Delphi is the IDE, Object-Pascal is the language, and VCL is the graphical framework.
That being said, I don't think there is anything that even comes close to matching the power and simplicity of the VCL. Qt is great, but it is no VCL.
Edit: This answer was written in 2008. It probably is no longer so apt, though probably it is not entirely useless. Take with salt.
I have used both and have ended up going the Qt route. These are the reasons:
Trolltech offer quick and one-to-one support via email
Qt innovates, and introduces powerful new features regularly
The Qt documentation is amazing, and in the rare cases where it isn't, you can read the source code
Having the source code for Qt also allows you to debug inside your base libraries, which has been a life saver for me on many an occasion
The API is very consistent and well designed. We have put new people on the project and within a month they show deep knowledge of the toolkit and can learn new classes very quickly
It has bindings to other languages, eg. Ruby and Python.
C++ is somewhat of a downside, eg. compile times, packaging, and a less integrated IDE. However Qt does make C++ feel more like a higher level language. QStrings take all the pain out of string handling for example. Thus the additional issues with C++ that you would normally face, eg. more buggy code, are less prevalent in my experience when using Qt.
Also, there are more libraries for Delphi than for Qt, but this is mitigated due to the fact you can just use a c or c++ library in a Qt project, and also because Qt is so fully featured you often don't have to look any further.
It would be a strange situation where I would choose Delphi over Qt for a new project.
I would pick Delphi. Of course you ask any pascalholic and he is sure to answer just the same. ;)
Qt again is fine, but the VCL just feels more polished. But then that could be my years of working with it so it just feels right. My experience with Qt was limited to a short lived project that ended up being rewritten in Delphi after it was determined that cross platform was not really needed thanks to the power of GoGlobal which can make any win32 app a web application, and therefore run on any platform.
It really depends on your needs and experience. I have worked with both (though have to say that the last Delphi version I really worked with was Delphi 6, and I'm currently working with Qt 4.4).
The language
C++ pros:
C++ is more "standard", e.g. you will find more code, libraries, examples etc., and you may freely use the STL and boost, while Object Pascal is more of an exotic language
Qt compiles on different platforms and compilers (Kylix is based on Qt, BTW)
Object Pascal pros:
some dynamic properties are build right into the language, no ugly workarounds like the MOC are needed
the compiler is highly optimized for the language and indeed very fast
the language is less complex than C++ and therefore less error prone
The IDE
Qt pros:
Strictly spoken, there is no IDE for Qt besides the Designer, but it integrates nicely into your preferred IDE (at least Visual Studio and Eclipse)
the designer does a better job with layouts than Delphi forms (Note: this is based on
Delphi 6 experience and may not be true with current versions)
Delphi pros:
The IDE is really polished and easy to use now, and it beats Visual Studio clearly IMO (I have no experience with Eclipse)
there is no point 2... but if I had to assign the buzzword "integrated" I would assign it to the Delphi IDE
The framework
I will leave a comparison to others, as I don't know the newest VCL good enough. I have some remarks:
both frameworks cover most of the needed functionality
both have the source code available, which is a must IMO
both have a more or less consistent structure - I prefer Qt, but this depends on your preferences (remark: I would never say that Qt is almost MFC - I have used MFC for a long time, and both Qt and Delphi - and .NET, for that matter - are way better)
the VCL has more DB-oriented functionality, especially the connection with the visual components
Qt has more painting (2D / 3D / OpenGL) oriented functionality
Other reasons that speak for Qt IMO are the very good support and the licensing, but that depends on your needs. There are large communities for both frameworks,
A big difference between Delphi and Qt is the Qt signal/slots system, which makes it really easy to create N-to-N relationship between objects and avoid tight coupling.
I don't think such a thing exists in Delphi (at least there was no such thing when I used to use it).
I just started experimenting with Qt/C++/Qt Creator and I must admit I was surprised that this "little cute bastard" was just below my nose for some many years and I pay attention to it just now.
It (the framework) looks neat, feature-complete (even was stuff that .NET lacks such as inbuld XQuery support).
Seems that most of the Qt applications written are dealing with 2D/3D/Games.
I believe the downsides are only: having to know C++ and the lack of DevExpress goodies like QuantumGrid.
I am seriously considering porting one of my simple applications (a picture viewer like ThumbsView).
And it REALLY runs from same codebase. FOR REAL!
Forget about Kylix, Mono, Lazarus, Free Pascal. This Qt thing beats them all in 10 times.
Qt Creator is far from IDE. But I hope in the future they will add a more powerfull debugger, code insight and refactoring (at least the "Rename" one) and more meaningful compiler errors.
I would seriously recommend to someone without experience in Pascal/C++ to take the Qt learning curve.
I would pick Delphi, but that is probably because I have programmed it before. It seems there are still a number of companies which use it, and almost everyone who has 8+ years expierence has encountered it somewhere. It seems that most programmers can relate to using it or at least learning Pascal. Not to mention the fact that newer languages (C#) are based on it (at least partially).
Pick Delphi if your concern are native Win32 speed, a first class RAD environment and executable size. Pick QT if you need a truly cross-platform framework coupled with a now-flexible licensing policy and don't mind slightly bloated code.
I ported an old Delphi program under QT/C++, and I must say that QT is the framework that comes closest to VCL in terms of ease of use and power (IMHO)
I'd choose delphi. Only because I have more experience with it. I don't think that there is other reasonabl criterias.
Qt is cross-platform, Delphi not much if we count Kylix. Lazarus is cross-platform, but not quite feature-complete yet.