I want to connect two PCs and have them communicate. Is there a nice component to do that? (preferably from TMS, or free), or do I just use standard C++ socket libraries?
What about sending data? Should I invent a simple protocol? TLV (type/length/value), where T is the message type and .. you get the picture...
Since you are using C++ Builder, you should really be using the Indy components, they are a nice well tested and easy to work with set of networking components... And they are already built into C++ Builder. If you are using C++ Builder, using Qt or boost can be really problematic (of course depending on C++ Builder version).
Indy components: http://www.indyproject.org/index.en.aspx
With Indy components you get all the components you need for basically every sort of network development you need, it is by far the most complete networking solution for C++Builder/Delphi that I have seen.
You might find this article interesting: Developing TCP/IP-based Server Applications using Indy Components [1] it shows examples in Delphi, but converting to C++ should be trivial.
Besides the Delphi in Depth [2] book is a good resource and contains samples in C++ as well.
About the developing your own protocol, it is almost impossible to answer that question with a definitive answer, it really depends on the requirements you have. Perhaps you should start by asking, is there an existing protocol that would work for me, before you end up, perhaps, reinventing the wheel.
[1] http://conferences.embarcadero.com/article/33256
[2] http://www.atozed.com/indy/book/index.en.aspx
You should look at Qt or Boost. (I personally prefer Qt's network API and documentation, but you may feel differently.)
And for something simple, why would you invent your own protocol? Just use HTTP. It's easy to work with and you can use all kinds of tools, not just your own code, to verify that everything is working properly.
Related
Could someone please explain their differences? Are they same and work the same way? Which one is better than the other components?
They are NOT the same, and they DO NOT work the same way. They take very different approaches to socket API interactions, event handling, error handling, etc.
TClientSocket and TServerSocket are the original VCL-based (Windows-specific) socket components. They were deprecated in Delphi 7 and are no longer installed by default, but are still available for manual install if you want to use them.
TTcpClient and TTcpServer were originally introduced in Delphi 6 as a cross-platform socket solution for Kylix (which is a dead product). They were removed from Delphi in XE6, downgraded to demo status, not even official components anymore.
In my opinion, TTcpClient and TTcpServer are horrible components, you should stay away from them. They use a very minimalistic "least common demoninator" approach to cross-platform programming, catering only to a few basic functions that multiple platforms support, not leveraging any platform-specific features or even higher-level functions. They have a very basic interface that is badly designed. They are very difficult to work with, have bad error handling, and are not very flexible to use.
If you need to write new socket code, TClientSocket and TServerSocket work great if you are only interested in supporting Windows, but if you need to support cross-platform then you should use a third-party socket library, such as Indy (TIdTCPClient/TIdTCPServer), ICS (TWSocket/TWSocketServer), Synapse (TTCPBlockSocket), etc.
ok there is no real way to connect to soap within ios5... sadly enough.
I cant really believe that things that take 3 lines of code in php,
$client = new SoapClient("scramble.wsdl");
print($mirror = $client->sendAndGetString("hello_world"));
need 366 lines of code in objective c? And that on a device that has one of the biggest number of ria's and web apps.
Kind of disappointing -
Are there any new libraries I am not aware of?
If I talk to our web developer team they maybe switch to another service type that is more supported by IOS.
What would be a alternative then?
Thanks
The difference between dynamically typed languages such as PHP and statically typed languages such as Objective-C regarding RPC protocols is that while dynamic languages typically allows you to wrap "any" service in run-time by reflecting out their metadata (e.g. WSDL), statically typed languages normally requires a code generation step before the compilation phase.
Two popular code generators seem to be wsdl2objc and sudz-c. See also this question.
Regarding alternatives, I have good experience using both JSON and XML-RPC, as well as the more schema-oriented Thrift and Protocol Buffers (ObjC).
I've written several tutorials about using SOAP services in iOS with Wsdl2Objc: http://brismith66.blogspot.com/search/label/iPhone%20Development
For me the easiest way is to use good tool to generate all required classes. Personally I use this site:
http://easywsdl.com/
It supports quite complex web services and is very easy to use.
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.
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.
I never liked components for winsock programming,I loved it in its natural way,but today my collegue told me to use Indy for my project.Could you tell me if Indy better alternative for my project?
-2 TCP servers,2 TCP clients.4 sockets total
-The project is a proxy.
And now the second question,I read daily that WSAASyncSelect is not good and that's predictable,it's from winsock 1.1.My question is: Suggest something better than AsyncSelect for winsock-by-hand.
Thank you.
My preference tends to lean on synapse for all of my socket work because of its light and easy to understand approach. It is not a component architecture, but a class architecture and implementation is generally as simple as copying one of the existing helper classes and modifying it to perform the exact steps needed. Synapse also has a great user community, and is being actively developed so get the latest changes from the svn snapshot (I believe its revision 98, the website has a zip of revision 38).
Yes, Indy is much better because it provides you with consistent abstraction of winsock communication. The difference is like creation windows using WinApi and simply using TForm.
Yes, Indy is better. So is ICS, or Synapse, or any of the other internet-related component sets. They handle all of the minutia and let you work on your application's actual functionality instead of wasting your time on the communications layer details. They're also much more well tested (because of the broader user base and wider range of hardware and operating systems) than your own code could ever hope to be.
NIH (Not Invented Here) is a really bad idea if there are well-constructed, well-maintained, and widely used alternatives available, especially when those alternatives are free with source (like Indy and ICS).