Related
I've been looking everywhere but cannot find an answer, is it possible to draw a pixel in C++ without a library, to the console, where I decide where to plot it(x,y).If not, how does a library manage to do this, I read it had something to do with the library gaining access to the drivers on the computer, but even then its still part of the C++ program.By the way I have never had formal programming education so this may seem silly.
This is possible, but highly dependendt on your operation system. You will have to use the OS API, because the C++ standard in itself doesn't have any idea of that kinda stuff.
For example, Windows has the SetPixel function that can be used on the console window. You can get the console window by using GetConsoleWindow and its context using GetDC.
That said, it's one of the less orthodox things to do, not portable and hard to predict - redraws of the console window will erase your content. Reconsider your options, and think about whether using a library might not be the better idea.
My question is that, how Can I draw one single pixel on the screen using C++ native libraries and functions? I mean not to use external functions or libraries. How is it possible?
Something Like this:
int rgb = {255,150,113};
nativeLibrary.drawPixel(0,1, rgb);
A fancy example just it is.
You can't. C++ does not (yet) have any native graphics or GUI libraries.
C++ may eventually add graphics into the standard (they were considering it), but for right now, the C++ standard does not include graphics.
You can take advantage of other standards in order to write a pixel to the screen, though. If you're on Linux, there is already an answer up.
If you're using VGA, you can actually write directly to the VGA buffer (WARNING: WAY OUTDATED Like "meant for DOS" outdated). You would probably use C++'s inline assembly to set the render mode instead of whatever that page uses, then use a regular unsigned char* instead of a "far" pointer to access it. Although you probably aren't using VGA and probably don't want to use assembly (especially inline assembly).
So what do you do outside of that? Nothing, really. You need to use an external library specifically to render, so probably OpenGL or DirectX or some library making use of either.
Like the previous answer, there no native library to deal with images. However, if you are working in Windows API and particularly MFC, you may use CBitmap class.
I have an application written in Delphi that compiles in Delphi 2007. I think it was originally written in Delphi 7.
Anyway, I need to convert all the core non-GUI code into C++ because I want to release a Mac version of the software.
What is the best way to do this? Any shortcuts I can take to speed up the process?
EDIT: The code compiles to native code, not .NET.
Simple answer: You simply can't port non-trivial Delphi code to C++ without a complete rewrite. C++'s object model is very different from Delphi's. It doesn't have a base class like TObject from which all other objects are derived, and it lacks support for a lot of the RTTI stuff that Delphi code often takes for granted. And there's no simple way to reimplement Delphi RTTI in C++, since a lot of it's done at the compiler level, and a lot of it's based on the fact that all Delphi classes descend from TObject.
C++ also lacks support for the concept of unit initialization and finalization sections that are so common in Delphi, and what it has instead is badly broken. (Look up the "static order initialization fiasco" for all the gory details.)
Delphi's exception handling is also much more advanced than C++'s. Part of this is the object model and part of it's compiler magic. Plus, C++ has no support for the try-finally construct.
If you want to port a Delphi project to the Mac, Free Pascal is your best solution. It's not 100% compatible with Delphi, but it's good enough for a lot of things, and you specifically mentioned that you don't need to port the Delphi GUI stuff. AFAIK the GUI area is the source of most of FPC's compatibility weaknesses, so if that's not necessary, FPC is probably pretty close to ideal for your needs, at least until CodeGear gets an OSX compiler out. (Which hasn't been officially announced, but based on various things that have been said it's not unreasonable to suppose that one will be available sometime next year.)
For converting your code from Delphi to Cpp, have a look at
http://ivan.vecerina.com/code/delphi2cpp/.
I used this to convert some of the classes and functions in SysUtils, DateUtils and StrUtils using wxWidgets functions. If you are planning to use wxWidgets for C++ have a look at http://twinforms.com/products/wxwidgets/wxvcl.php which has all the converted source.
If you want directly develop Mac OSX applications using then have a look at wxForms for Delphi - http://twinforms.com/products/wxformsdelphi/index.php
I think this would be difficult to do mechanically, so you are probably looking at a complete re-write. One thing to bear in mind is that typically Delphi uses try...finally structures for resource management, whereas C++ uses a technique known as RAII (resource acquisition is initialisation). You should read up on this and other C++ idioms before you attempt the conversion.
If your code compiles in Delphi 2007 into .NET assemblies, you may have a much easier option than trying to port from Delphi's object pascal to C++.
You could potentially compile your logic into .NET assemblies (and maybe even portions of the UI), and use Mono to run it on Mac. You could write a custom GUI around Mono, or even potentially make a single, platform independent application.
You can use also Delphi Prism. It's for .NET, but it's the last expression in Delphi language spec. It supports also Mac OSX (see the link). Also the guys from CodeGear/EMBT are in the works for a new compiler as well as for a new version of Delphi which is expected to enter in beta in April and narrow the gap between Prism and RAD studio. See their 'Beta Programs' page.
The "correct" way to do this is to rewrite it in Objective C. I find Objective C a little weird, but there are a lot of similarities with Delphi in the way objects connect and delegate.
You may be able to use Free Pascal to do it more quickly, but you should seriously consider a rewrite.
I would be in love with Embarcadero if they could release a Mac OS X version of Delphi that didn't, you know, suck like Kylix did. One can dream.
Edit: There is a great benefit to staying in Delphi, and having a separate version for the Mac in Objective C. First, it means you don't need to rewrite the version on Windows, losing the (presumably) years of investment in Delphi code. Second, Mac software operates differently than Windows, from a UI perspective. A simple port of the product is inappropriate, and hobbles the developer from using the great native features of Windows and Mac. See: older versions of MS Word for Mac, or iTunes for Windows. They look and feel wrong.
I do have to say I'm fairly inexperienced when it comes to C++, don't be too harsh on me.
Recently stumbled unto the wonders of the win32 API and have chosen to practice using it (I'd rather not use MFC/wxWidgets/etc at this point, just for educational purposes).
Well, my real question is:
How do you properly code your win32 GUI stuff into classes. I mean, sure, you can make a class that saves individual window handles, allows for easier modification of window properties, has a more simplified version of CreateWindow(). But as I understand it you will need a messagepump and several callback functions for your created windows. How does that work when combining them with classes?
Could anyone point me in the right direction here? I don't mind reading (a lot of) example code as long as it is commented.
PS: I'm also having trouble finding good (read: easy) documentation on using 'resource files' for my window decorations. Bonuspoints for that! :)
I program in C++ for a living. I like C++.
That said, your life will be so much easier if you do your windows GUI in something .Net, e.g., C#. Win32 is very low-level and you will be building tons of stuff that you will get for free with the .Net libraries. Win32 is not a wonder, anymore. :-)
If you want to learn C++, pick something other than a GUI to do with it.
I personally would use MFC instead of reinventing the wheel here. However, if you insist you need to have an application object that is instantiated when the program is run and contains the message loop and a mechanism for forwarding messages to the correct window objects.
That's the way MFC does it, at least. I'm not sure if the MFC source code is available for download, but if you have access to Visual C++ install disks (any version) you should be able to install the source code on your computer to review.
The biggest problem I faced back when I used the Win32 API (have since moved on to Linux and cross-platform solutions) were the callbacks. Especially the winproc one, AKA the message pump. I found this, which should be a good hint. I did what that page suggests when I rolled my own wrapper.
Look at MFC or ATL/WFC. If you want to re-invent the wheel, the best reference source for how to do so is the wheel itself, especially since the source code is readily available.
I would suggest reading Windows++ by Paul Dilascia. It takes you through the whole process of building a class library in C++ on top of the Windows API. It's written for 16-bit Windows, but all of the concepts presented in the book still apply. Plus, you can get it really cheap since it's "out of date".
And make sure you learn about message crackers (#include <windowsx.h>), they will keep you from pulling out too much hair. ;-)
The best way to learn this is to go and readCharles Petzold's original book. He does a good job of showing how to set up the base message loop and how to build statements for routing the various events to handlers. The real problem here is that by reinventing everything you are going to be spending hours and hours writing and debugging windows event hanlding code instead of writing your own application.
Unless you have a compelling reason for doing this yourself, you woudl be far better served using someone else's construct like MFC.
The only reason I see for coding all this yourself is if you want a basic understanding of how it works before you switch over to MFC or something similar. At least this way you would see how it works under the covers before you can forget it forever.
Many years ago, I developed a set of classes to encapsulate the API (various reasons why we couldn't use MFC). I learned a lot from the MFC source code.
The big key is that every window has a UserInfo data member - you can use it for whatever you want. What you'll want to use it for is the class's this pointer.
Now, the other tricky thing is that the message handler callback function cannot be a normal class member function, as Windows uses C calls and not C++. So your callbacks must be statics. However, since you've saved the class's this pointer, its just a matter of getting the class's userinfo, casting it to your class's this pointer and then calling whatever (non-static) class functions you need.
If you plan it correctly, inheritance will work well, including all of the inheritance that the windows themselves exhibit (ie, an Edit is a Control is a Window).
The only reason I would recommend not reinventing the wheel is you are neither an expert at C++ nor the Win32 API. Trying to learn two unrelated subjects at once will not be productive. If you want to become better at C++, write a library for a subject you know a lot about. If you want to learn the Win32 API, program it raw to understand how it works before creating (or using) a wrapper for it.
There is a pretty good C++ Windows API tutorial on the Reliable Software site.
My main experience is with C && C++, so I'd prefer to remain with them. I don't want to use anything like QT, GTK, or wxWidgets or any tool kits. I'd like to learn native programming and this sort of defeats the purpose. With that in mind I'd also like to avoid Java.
I understand gnome and xfce and KDE and such are all Desktop Environments for Linux, and the base installed typically is X (Xorg). When coding for Linux, do you code for X, or for the desktop environment? Is there a standard Linux header for this (like win32 has windows.h) for Linux? or is it different coding methods for every desktop environment?
any help is greatly appreciated.
X is a hideous layer to program for and, despite your intent to avoid Java, QT or any of the excellent UI abstraction layers, you'll be doing yourself a disservice by coding to that level. I've done it (a long time ago when Motif was in its infancy on the platform we were using) and I would not do it again if there was an easier way.
Your use of the phrase "native programming" confuses me a little. If you want to learn native programming, it's to the APIs that you choose to call. Using similar reasoning, you shouldn't be coding in C either, instead opting for assembler (or direct machine code) since C provides an abstraction to the hardware.
If you want to learn X programming, that's fine. You'll end up with a lot more control over your interface but almost everyone else will be out-performing you in terms of delivery of software. Myself, I'd prefer to code to a higher-level API that I can use on many platforms - it gives me both faster delivery times and more market potential.
You don't build a house out of atoms, you build it out of bricks. My suggestion is to use the tools, that's what they're there for.
I don't want to use anything like QT, GTK, or wxWidgets or any tool kits. I'd like to learn native programming and this sort of defeats the purpose.
No you don't. Back in an early version of X11, like R1 or R2, I coded a complete "Hello, world" program in Xlib alone.
Roughly 700 lines of C.
You don't want to go there.
I guess you could write C code directly against Xlib, but you'd end up recreating all the functionality that GTK+ or QT provide that X doesn't alone.
Unix (and by extension, Linux) doesn't actually define anything to do with GUIs. X, which is commonly used, doesn't define anything to do with widgets or styles or anything of that nature - it's concerned mostly with drawing primitives and event handling. Essentially, if you wanted to write in pure X, you'd be defining the shape and behaviour of every element on screen. If you were crazy enough to abandon X, you'd be working at the graphics framebuffer level...
You're better off using some toolkit - if you're looking for light-weight, why not try FLTK?
GTK, QT and wx are toolkits that build on X to provide a friendlier API.
If you don't use an existing toolkit you'll need to write things at a very low level - directly handling mouse and keyboard events. If you want a button or a textbox you'll have to write it yourself using the low level xlib primitives.
Before trying this you're probably better off picking the toolkit of your preferred desktop environment and starting with that.
There is simply no such thing as "native" in this case. Windows and OS X just have an official option, while X does not.
The "native" interface for Linux & most other Unix-like OSs is Xlib, the lowest-level C API for X11.
GTK, Qt & others are all (so far as I know) implemented in terms of Xlib at their core. As others have said, Xlib gives you maximal control but you'll have to work for it (and others may run circles around you in terms of delivering a product).
As a point of reference, I personally implemented a fairly feature-rich & modern (i.e. flowable) cross-platform (Win32 + X11) GUI library in C++. Total count is about 29 KLOC of C++, of which about 2500 lines each was required for the X11 & Win32 shimming. The rest is for platform-neutral Widget implementations. Unless you're prepared to make a commitment like that, I strongly recommend going with one of the higher level libraries (Qt would probably be my choice, though I can't stand the preprocessor approach).
BTW, a big plus for Xlib is its raw portability--any Unix box with a screen will have it, and it can be made to work on Windows & OS X as well.
I feel it necessary to counterpoint the unanimity of the other answers here. X11 is indeed low level. But to "truly" understand what's going on, you should have some familiarity with how X11 works. Since all the toolkits work on top of X, you're using it whether you like it or not. There is nice tutorial online somewhere that I'm too lazy to search for. It guides you through building a simple Hello World. To do it, you'll have to learn how to create a window, request events, map the window, and process events in a loop. You could even go so far as to order some used books on Amazon. The O'Reilly vols 1 and 2 (for now get the cheapest editions, but nothing earlier than X11R4) are essential for reference and to get the full story of how the pieces work together. For learning, however, the best book is X Window Applications Programming by Eric Johnson and Kevin Reichard.
At some point along this journey, as everyone else says, you will find you've had enough. Two pages of code just to select a visual, and then you still have to populate a colormap before you can paint your custom bitmap. And then two days of rewriting and debugging to realize that it all does work; you just forgot to XFlush()!
The struggle is important, because you'll appreciate the toolkits more once you find the one you like.
I would suggest lesstif/motif as well. It also builds on top of X and the learning curve is, in my opinion, isn't as steep as GTK or Qt. The UI's you build with it aren't going to be as sophisticated as ones you could build with GTK or Qt though. More information can be found here.
As others have mentioned you probably don't want to X it's a pain.
Why not choose one among, say, Qt, wxWidgets and GTK and learn its internals, rather than its API? I do not mean just for the sake of it, but with the aim of contributing to the parts you find most appealing. In this way you'd fulfill your goal and get to do something useful, for you and also for others. I think this would be more rewarding than assigning yourself the rather artificial task of building an application with what amount to the wrong tools.
oh yeah, there is such "native" things:
FBUI, svgalib, directfb, exa(kdrive), SDL, Allegro..+Wayland, although not mainstream.
http://home.comcast.net/~fbui/
http://www.svgalib.org/
http://directfb.org/
http://xorg.freedesktop.org/wiki/ExaStatus
+
http://wayland.freedesktop.org/