It was a header that was available in old Borland compilers. Used
strictly for graphics in MS-Dos apps. You are at least 7 operating
systems, 16 bits, 20 years and untold compiler versions removed from
using it.
Yes, I know that <graphics.h> is gone. I am new to C/C++ and my knowledge is confined to the computer graphics being taught to us in college.
Is there some way I can use graphics.h in CodeLite to study the programs?
The similar level of abstraction in C can be easily reached with SDL
You will want SDL_Surface to put points of Bresenham to.
I'd also recommend ClanLib for use with C++, as more convenient to start with.
Both libraries are cross-platform (and can use OpenGL as engine)
The header file mentioned in your post is part of Borland's Graphic Interface library and is most commonly associated with Turbo C++. Because of its age it is no longer officially supported by Borland. There are however alternatives like OpenBGI and WinBGI which strive to emulate the functionality of the original library on modern systems. The source code for both libraries is available as well and are usable in CodeLite projects.
As a side note the documentation is also available online.
Related
I work in a factory where 80% of our equipment uses an MS-DOS interface. None of our engineers have experience in c/c++ programming, and it was requested we add some features to the machines interface. Our automation group has abandoned the MS-DOS platform in favor of Allen-Bradley controls. I'm feeling ambitious and decided to take on this project, even though I have next to no experience in c/c++.
On to the question:
All of the programming was written and compiled in Turbo C++. I would prefer to use DEV++ for various reasons (ease of use, additional headers, more developed C++ platform, ect.). The problem is the existing programming relies heavily on non-standard headers from TC++. There are 10 or so headers unavailable in DEV++ in the source code, and rewriting the code using more modern constructs is not an option; we would lose what little support we have from our AG, time, ect.
Is there a way I could add all the headers from TC++ to DEV++? For example adding the graphics.h to DEV++ and have it be fully functional? I have tried adding it to the include folder, calling it with #include"graphics.h", and if DEV++ manages to recognize it, it throws a ton of compiling errors because it doesn't recognize the internal commands in the graphics.h file.
Unfortunately I cannot include any example code from this project, due to non-disclosure and copy-write policies.
My programming experience:
DABBLE in RSLogigx500,5000 ; Arduino IDE (don't judge) ; Parker 6K ; PanelView ; ~40hrs of self-taught c and c++.
Any help would be much appreciated.
UPDATE
Very helpful information. It seems like this isn't going to be possible given how outdated the hardware is and the restrictions I have on this project, but thank you all for your input.
Most of the headers from old Turbo C are really just the MSDOS API, in a way. So it doesn't make any sense to attempt to use those headers in any other environment and you can't port them to a Windows compiler. Similarly, graphics.h is for a Borland-specific DOS graphics library called BGI and will not work on any other compiler.
It should be noted that old Turbo C++ (I'm assuming version 3.1?) didn't follow the C or C++ standards much. The C++ version it used is completely antique.
Also note that the Dev C++ IDE is outdated and doesn't update the GCC compiler any longer. The CodeBlocks IDE is a better alternative.
This is more of a "long comment" than a direct answer to your question, trying to guide you to a better understanding of what MAY be your challenge in your project.
I personally would choose a more "professional" level development tool. Either Eclipse (positives is that this is portable and looks/feels the same whether you use Windows or Linux), XCode (works only on Mac) or Visual Studio (which works only on Windows). These are full featured integrated development environments, and they are all very slick. All of them are free or nearly free.
Compiling OLD code, that is written for DOS into a modern compiler with on a modern OS may be quite a challenge, depending on what the application does and how much in the way of assumptions about it's environment the code is written with:
does it assume int is 16 bits
does it call direct to DOS to get file info, opening/reading/writing/closing files
does it do raw keyboard input
does it poke characters and/or pixels directly at the screen
does it use far and near pointers, are there driver-like components that interface directly to hardware interrupts
One thing that stands out in your question is the mention of graphics.h, which I believe is very Borland specific. Which means you'll have to write your own replacement functions - either a replacement graphics.h set of functions (I expect most functionality is available in any modern OS, it's more a case of "what is it called and what do I need in order to call that function"). This can be quite a task in itself.
The tricky part here is not only to identify what the code does, but to replace it with similar logic, that does the same thing in your new environment.
And of course, it all depends on what you want to do with the code, how well written it is - is it nicely modular, does each function do one thing and one thing only, or are there functions that "This calculates the value of , and then reads some data from disk, then does some I/O to the screen, and then talks to some external hardware, and because it gets calls frequently, also updates the time on the screen if it has changed".
In C++, if I write a simple game like pong using Linux, can that same code be compiled on Windows and OSX? Where can I tell it won't be able to be compiled?
You have three major portability hurdles.
The first, and simplest, is writing C++ code that all the target compilers understand. Note: this is different from writing to the C++ standard. The problem with "writing to the standard" starts with: which standard? You have C++98, C++03, C++TR1 or C++11 or C++14 or C++17? These are all revisions to C++ and the newer one you use the less compliant compilers are likely to be. C++ is very large, and realistically the best you can hope for is C++98 with some C++03 features.
Compilers all add their own extensions, and it's all too easy to unknowingly use them. You would be wise to write to the standard and not to the compiler documentation. Some compilers have a "strict" mode where they will turn off all extensions. You would be wise to do primary development in the compiler which has the most strictures and the best standard compliance. gcc has the -Wstrict family of flags to turn on strict warnings. -ansi will remove extensions which conflict with the standard. -std=c++98 will tell the compiler to work against the C++98 standard and remove GNU C++ extensions.
With that in mind, to remain sane you must restrict yourself to a handful of compilers and only their recent versions. Even writing a relatively simple C library for multiple compilers is difficult. Fortunately, both Linux and OS X use gcc. Windows has Visual C++, but different versions are more like a squabbling family than a single compiler when it comes to compatibility (with the standard or each other), so you'll have to pick a version or two to support. Alternatively, you can use one of the gcc derived compiler environments such as MinGW. Check the [list of C++ compilers](less compliant compilers are likely to be) for compatibility information, but keep in mind this is only for the latest version.
Next is your graphics and sound library. It has to not just be cross platform, it has to look good and be fast on all platforms. These days there's a lot of possibilities, Simple DirectMedia Layer is one. You'll have to choose at what level you want to code. Do you want detailed control? Or do you want an engine to take care of things? There's an existing answer for this so I won't go into details. Be sure to choose one that is dedicated to being cross platform, not just happens to work. Compatibility bugs in your graphics library can sink your project fast.
Finally, there's the simple incompatibilities which exist between the operating systems. POSIX compliance has come a long way, and you're lucky that both Linux and OS X are Unix under the hood, but Windows will always be the odd man out. Things which are likely to bite you mostly have to do with the filesystem. Here's a handful:
Filesystem layout
File path syntax (ie. C:\foo\bar vs /foo/bar)
Mandatory Windows file locking
Differing file permissions systems
Differing models of interprocess communication (ie. fork, shared memory, etc...)
Differing threading models (your graphics library should smooth this out)
There you have it. What a mess, huh? Cross-platform programming is as much a state of mind and statement of purpose as it is a technique. It requires some dedication and extra time. There are some things you can do to make the process less grueling...
Turn on all strictures and warnings and fix them
Turn off all language extensions
Periodically compile and test in Windows, not just at the end
Get programmer who likes Windows on the project
Restrict yourself to as few compilers as you can
Choose a well maintained, well supported graphics library
Isolate platform specific code (for example, in a subclass)
Treat Windows as a first class citizen
The most important thing is to do this all from the start. Portability is not something you bolt on at the end. Not just your code, but your whole design can become unportable if you're not vigilant.
C++ is ultra portable and has compilers available on more platforms than you can shake a stick at. Languages like Java are typically touted as being massively cross platform, ironically they are in fact usually implemented in C++, or C.
That covers "portability". If you actually mean, how cross platform is C++, then not so much: The C++ standard only defines an IO library suitable for console IO - i.e. text based, so as soon as you want develop some kind of GUI, you are going to need to use a GUI framework - and GUI frameworks are historically very platform specific. Windows has multiple "native" GUI frameworks now - the C++ framework made available from Microsoft is still MFC - which wraps the native Win32 API which is a C API. (WPF and WinForms are available to CLR C++).
The Apple Mac's GUI framework is called Cocoa, and is an objective-C library, but its easy to access Objective C from C++ in that development environment.
On Linux there is the GTK+ and Qt frameworks that are both actually ported to Windows and Apple, so one of these C++ frameworks can solve your "how to write a GUI application in C++ once that builds and runs on windows, apple mac and linux".
Of course, its difficult to regard Qt as strictly C++ anymore - Qt defines a special markup for signals and slots that requires a pre-compile compile step.
You can read the standard - if a program respects the standard, it should be compilable on all platforms that have a C++ standard-compliant compiler.
As for 3rd party libraries you might be using, the platform availability is usually specified in the documentation.
When GUI comes to question, there are cross-platform options (such as QT), but you should probably ask yourself - do I really want portability when it comes to UI? Sometimes, it's better to have the GUI part platform-specific.
If you are thinking of porting from Linux to Windows, using OPENGL for the graphical part gives you freedom to run your program on both operating systems as long as you don't use any system specific functionality.
Compared to C, C++ portability is extremely limited, if not completely unexisting. For one you can't disable exceptions (well you can), for the standard specifically says that's undefined behaviour. Many devices don't even support exceptions. So as for that, C++ is ZERO portable. Plus seeing the UB, it's obvioulsy a no-go for zero-fail high-performance real time systems in which exceptions are taboo - undefined behaviour has no place in zero-fail environment. Then there's the name mangling which most, if not every, compiler does completely different. For good portability and inter-compatibility extern "C" would have to be used to export symbols, yet this renders any and all namespace information completely void, resulting in duplicate symbols. One can ofcourse choose to not use namespaces and use unique symbol names. Yet another C++ feature rendered void. Then there's the complexity of the language, which results in implementation difficulties in the various compilers for various architectures. Due to these difficulties, true portability becomes a problem. One can solve this by having a large chain of compiler directives/#ifdefs/macros. Templates? Not even supported by most compilers.
What portability? You mean the semi-portability between a couple of main-stream build targets like MSVC for Windows and GCC for Linux? Even there, in that MAIN-STREAM segment, all the above problems and limitations exist. It's retarded to even think C++ is portable.
I'm considering learning Objective-C and Cocoa, mostly in order to use Apple's tools and GUIs.
However, I'd also like to do some graphics programming; OpenFrameworks and Cinder are two libraries which catch my eye, but then we're in C++ land.
I come from a Java/Swing/Processing background... don't know much about the C family. How effectively can you call C and C++ libraries, like Cinder and OF, from native Cocoa?
And, bonus points: would a solution like this work on an iPhone or iPad?
In short, C++ is just fine for OS X and iOS programs, and plays with Objective-C quite nicely.
In more detail:
However, I'd also like to do some graphics programming; OpenFrameworks and Cinder are two libraries which catch my eye, but then we're in C++ land.
I won't speak for those libraries directly.
To answer your question in more general terms: C++ is just fine in your app, since C, C++, ObjC, and ObjC++ are first class development languages for iOS apps.
I come from a Java/Swing/Processing background... don't know much about the C family. How effectively can you call C and C++ libraries, like Cinder and OF, from native Cocoa?
Objective-C++ allows you to use C, C++, and Objective-C all in the same translation. Feel free to use/combine C++, C, or ObjC where needed. The compile times will increase, and there are some restrictions* if you take this route. Otherwise, support is very good. Even Apple uses a good amount of C++ in their apps/libs.
And, bonus points: would a solution like this work on an iPhone or iPad?
Definitely. c++11 support for iOS and OS X is currently a bit behind. However, the clang team's been adding support for it very very quickly. There will likely be some bumps if you want the latest features, so I'd say hold back on bleeding edge C++ and compiler features if your project depends on it. Of course, it does not hurt to sample your program using the latest clang features with each release in order to determine how well it works with your programs.
Update: At this point (Nov 8, 2011) clang can handle nearly all of the C++ 2003 code I throw at it. Code speed and size does vary compared to GCC+LLVM. I would not want to drop either at this point, but both compilers work well for me with C++ 2003, and Apple's GCC will not support c++11, so it's a good time to start testing clang if you want c++11 features in the near future.
C++ is ideal (IMO) for general performance critical development on iOS, as long as your team knows how to use it.
Mixing C, ObjC and C++ is very powerful if you use the right features of each language for the right reasons, and good compatibility exists. This reaches back years from OS X (although the compiler was GCC at the time).
*restrictions: these are reasonable restrictions - all the features you need exist, but there are some things that people may expect which are not possible. the most common is likely the inability to derive types of different object models. that is, you cannot reasonably not create a c++ type from an objc type, but you can freely declare ivars of multiple types in either object type.
It is possible to use both OpenFrameworks and Cinder in iOS applications (see this related SO question: OpenGL ES, OpenFrameworks, Cinder and IOS creative development), though Apple "prefers" developers to use OpenGL.
As of now you can use Cinder from within a typical Cocoa project via the new CocoaCinderGL wrapper. It lets you add several NSCustomView's to your application, each one running an independent "instance" of Cinder. And obviously you can connect as many NSButtons, NSSliders as you like to those instances. Hope that helps!
I am new to code::blocks, so I was wondering how could I compile and run my computer graphics animation programs (those that use graphics.h) in Code::Blocks.
Is this possible with the default installation?
This is impossible. You can't use graphics.h without a time machine, so you're better off forgetting about it altogether. This question gets asked about once a week, and the consensus is always the same.
The graphics.h header is a proprietary graphics library included with Borland compilers back in the early 1980s. It is not a standard C or C++ library, and hasn't been modern or relevant for at least 20 years. It should come as no surprise that it does not work with modern compilers, or on modern operating systems. Using or learning to use it is an utter and complete waste of time. If your educational system is insisting upon you doing so, you should be entitled to a complete refund of your tuition.
It's good that you're moving up to a modern IDE like Code::Blocks. You should also upgrade your library and toolkits while you're at it. If you want to write graphics applications, you're undoubtedly going to be doing so in a graphical environment like Windows or X. You might as well learn the way to do it there, rather than getting lines to appear in an MS-DOS emulator and marveling at the appeal of retro tech.
I am making a C++ program.
One of my biggest annoyances with C++ is its supposed platform independence.
You all probably know that it is pretty much impossible to compile a Linux C++ program in Windows and a Windows one to Linux without a deluge of cryptic errors and platform specific include files.
Of course you can always switch to some emulation like Cygwin and wine, but I ask you, is there really no other way?
The language itself is cross-platform but most libraries are not, but there are three things that you should keep in mind if you want to go completely cross-platform when programming in C++.
Firstly, you need to start using some kind of cross-platform build system, like SCons. Secondly, you need to make sure that all of the libraries that you are using are built to be cross-platform.
And a minor third point, I would recommend using a compiler that exists on all of your target platforms, gcc comes in mind here (C++ is a rather complex beast and all compilers have their own specific quirks).
I have some further suggestions regarding graphical user interfaces for you. There are several of these available to use, the three most notable are:
GTK+
QT
wxWidgets
GTK+ and QT are two API's that come with their own widget sets (buttons, lists, etc.), whilst wxWidgets is more of a wrapper API to the currently running platforms native widget set. This means that the two former might look a bit differently compared to the rest of the system whilst the latter one will look just like a native program.
And if you're into games programming there are equally many API's to choose from, all of them cross-platform as well. The two most fully featured that I know of are:
SDL
SFML
Both of which contains everything from graphics to input and audio routines, either through plugins or built-in.
Also, if you feel that the standard library in C++ is a bit lacking, check out Boost for some general purpose cross-platform sweetness.
Good Luck.
C++ is cross platform. The problem you seem to have is that you are using platform dependent libraries.
I assume you are really talking about UI componenets- in which case I suggest using something like GTK+, Qt, or wxWindows- each of which have UI components that can be compiled for different systems.
The only solution is for you to find and use platform independent libraries.
And, on a side note, neither cygwin or Wine are emulation- they are 100% native implementations of the same functionality found their respective systems.
Once you're aware of the gotchas, it's actually not that hard. All of the code I am currently working on compiles on 32 and 64-bit Windows, all flavors of Linux, as well as Unix (Sun, HP and IBM). Obviously, these are not GUI products. Also, we don't use third-party libraries, unless we're compiling them ourselves.
I have one .h file that contains all of the compiler-specific code. For example, Microsoft and gcc disagree on how to specify an 8-bit integer. So in the .h, I have
#if defined(_MSC_VER)
typedef __int8 int8_t;
#elif defined(__unix)
typedef char int8_t;
#endif
There's also quite a bit of code that uniformizes certain lower-level function calls, for example:
#if defined(_MSC_VER)
#define SplitPath(Path__,Drive__,Name__,Ext__) _splitpath(Path__,Drive__,Dir__,Name__,Ext__)
#elif defined(__unix)
#define SplitPath(Path__,Drive__,Name__,Ext__) UnixSplitPath(Path__,Drive__,Name__,Ext__)
#endif
Now in this case, I believe I had to write a UnixSplitPath() function - there will be times when you need to. But most of the time, you just have to find the correct replacement function. In my code, I'll call SplitPath(), even though it's not a native function on either platform; the #defines will sort it out for me. It takes a while to train yourself.
Believe it or not, my .h file is only 240 lines long. There's really not much to it. And that includes handling endian issues.
Some of the lower-level stuff will need conditional compilation. For example, in Windows, I use Critical Sections, but in Linux I need to use pthread_mutex's. CriticalSection's were encapsulated in a class, and this class has a good deal of conditional compilation. However, the upper-level program is totally unaware, the class functions exactly the same regardless of the platform.
The other secret I can give you is: build your project on all platforms often (particularly at the beginning). It is a lot easier when you nip the compiler problems in the bud. Don't wait until you're done development before you attempt to go cross-platform.
Stick to ANSI C++ and libraries that are cross-platform and you should be fine.
Create some low-level layer that will contain all the platform-specific code in your project. Implement 2 versions of this layer - one for Windows, and one for Linux - with the same interface, and build them to 2 libraries. Access all platform-specific functionality in your project through that interface.
This layer can contain general classes for file access, printing, GUI, etc.
All the (now non-platform-specific) code that uses that layer can now be compiled once on Windows and once on Linux.
Compile it in Window and again in Linux. Unless you used platform specific libraries, it should work. It's not like Java, where you compile it once and it works everywhere. No one has made a virtual machine for C++, and probably never will. The code you write in C++ will work in any platform. You just have to compile it in every platform first.
Suggestions:
Use typedef's for ints. Or #include <stdint.h>. Some machines think int is 8 bytes, some 4. (It used to be 2 and 4. How the times have changed.)
Use encapsulation wherever possible. My last window's compiler thought %lld was %I64d", gave screwy return values for vsnprintf(), similar issues with close() and sockets, etc.
Watch out for stack size / buffer size limits. I've run into an 8k UDP buffer limit under Windows, amongst other problems.
For some reason, my Window's C++ compiler wouldn't accept dynamicly-sized allocations off the stack. E.g.: void foo(int a) { int b[a]; } Be aware of those sort of things. Plan how you will recode.
#ifdef can be your best friend. And your worst enemy! (At the same time!)
It can certainly be done. But compile and test early and often!
Also Linux and Windows have diffrent data model.
See article: The forgotten problems of 64-bit programs development
Standard C++ is code compiles without errors on any platform.
Try using Bloodshed Dev C++ on windows (instead of VC++ / Borland C++).
As Bloodshed Dev C++ confirms C++ standards, so programs compiled using it will be compiled on linux without errors in most of the cases.