Sign in to follow this  
Aternus

Far pointers not supported in Dev-C++?

Recommended Posts

As I'm grasping the ropes of CPP, I try to teach myself new and neat stuff each day. Today I'm recreating the printf() function myself. Only problem is... when I want to write to the video memory, I'm using ehm... you guessed it, printf("%i",va_arg(a_list, int));. I looked up on some stuff about writing directly to the video memory and it all looks fairly simple... only problem is, when declaring a far pointer as the start address Dev-CPP say I'm using improper syntax. :O
char far * video_memory = (char far*)0xB8000000;
Get me these errors: 80 C:\Dev-Cpp\Sources and Creations\dotdotdottest.cpp expected primary-expression before "char" 80 C:\Dev-Cpp\Sources and Creations\dotdotdottest.cpp expected `;' before "char" I've also tried capitalizing far to "FAR", and get the same problem. So does Dev just not support far pointers, or is there something wrong on my side? Thanks for all help. P.S. I know I really shouldn't be learning this stuff as there's more effective ways of doing such and such and far pointers are "outdated". I still wanna try learning this, anyways. You know... for the fun of it. ;)

Share this post


Link to post
Share on other sites
Far pointers are only really used in 16-bit "real mode" code. Dev-Cpp creates 32-bit "(flat) protected mode" code, where far pointers are not used.

Moreover, you cannot access the screen in a modern OS by simply writing to some location in memory - the OS prevents you from doing so. You will need to use one of the OS supplied system services in order to write to the screen.

Share this post


Link to post
Share on other sites
While we're at it, you also shouldn't use C stuff like char* and printf. C++ has much nicer ways of doing it.

But yeah, direct hardware access is impossible under any modern OS. That includes video memory.

Now, just curious, but where did you dig up information about far pointers? Those haven't been used for ages... [wink]

Share this post


Link to post
Share on other sites
Haha. Well, first I wanted to know how default I/O wrote to the screen... since printf obviously didn't call on printf to write onto the screen. Found information on video memory and what not, then went digging up tutorials on that. Every last one of them was using far pointers, which of course didn't work with Dev. So I came here. ;)

And yes, I know cout and cin is much easier and in most ways better to work with, but I'm a stickler for file size. Would rather have a 15 KB program as opposed to a 515 KB program (iostream tends to do that). Besides, I kinda like the feel of working with C methods more. Makes me feel smarter!

--Aternus

Edit:The only difference for me between these 2 is file size... which is a couple hundred KB.
#ifdef EXAMP_1 //uses <string.h>
if(argc>1)
{
if(!strcmp(argv[1],"debug-mode"))
{
error->Debug = true;
}
}
#else //uses <string>
if(argc>1)
{
std::string CmdLine = argv[1];
if(CmdLine=="debug-mode")
{
error->Debug = true;
}
}
#endif




[Edited by - Aternus on June 9, 2006 6:50:22 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Aternus
And yes, I know cout and cin is much easier and in most ways better to work with, but I'm a stickler for file size. Would rather have a 15 KB program as opposed to a 515 KB program

6.5KB using cout and std::string. Using prinft and char* required 5.5KB

Quote:
Besides, I kinda like the feel of working with C methods more. Makes me feel smarter!

There's nothing smart about it. It's just more error-prone. I suppose you also feel smarter if you try to build a car using nothing but a hammer?

Share this post


Link to post
Share on other sites

if(argc>1)
{
std::string CmdLine = argv[1];
if(CmdLine=="debug-mode")
{
error->Debug = true;
}
delete CmdLine;
}



I would guess that you haven't compiled this code, as I cannot see how delete CmdLine is valid.

Share this post


Link to post
Share on other sites
Well, doing
#include <iostream>

int main()
{
std::cout << "int main";
}




Tends to be 515KB for me. O_o

As for the C thingie, I was just joking. Though C procedures do tend to look more complicated than cout, even though they aren't. That's what I meant by that.


-Etyrn

Edit: Make that 463 KB. Using printf made for 15.2 KB.

Edit - the sequel:@rip-off
It was a 4 AM copy paste where std::string used to be a char*. I'm off to bed. o.o

Share this post


Link to post
Share on other sites
For your compiled EXE size, make sure you're looking at a Release build, not a Debug build. Debug builds are always hideously large, because they contain extra information for (shocker!) debugging.

Share this post


Link to post
Share on other sites
I've personally played with the compiler options, and have never been able to get Dev-C++ to produce a small executable file when using iostreams. It seems to be inherent either in its compiler or in its iostreams implementation.

Share this post


Link to post
Share on other sites
Dev-Cpp uses GCC as its compiler, doesn't it? If so, the MinGW website has an FAQ on "Why is my C++ binary so large?".

Using command line gcc/g++ to compile a simple "Hello World" program, I get a file size of 555KB for a C version and 1MB for a C++ version. After stripping relocations and symbols ("strip --strip-all"), these files are reduced to 5.5KB/249KB respectively. Note that none of these were compiled with debug information.

The C++ version is much larger since it contains the implementation of std::cout, which eventually calls something like msvcrt.dll!fwrite. The C version, on the other hand, can call the higher-level msvcrt.dll!printf function.


[Edited by - bakery2k1 on June 9, 2006 8:16:57 AM]

Share this post


Link to post
Share on other sites
Quote:

Well, first I wanted to know how default I/O wrote to the screen... since printf obviously didn't call on printf to write onto the screen.

As others have already pointed out, your information about writing directly to the screen is woefully out of date. Nowadays, on a modern OS like Windows, the runtime library operations (like printf(), fopen(), iostreams, et cetera) call down to the appropriate functionality provided by the operating system. printf() will eventually reach the Windows character mode API, I imagine, just like fopen() eventually reaches CreateFile().

Your statement about using C APIs for size concerns are irrelevant with a modern compiler with appropriately configured options unless you are writing for an extremely limited platform. Your claims about feeling smarter when using C APIs certainly don't make you look smarter: if you are writing C++, use C++. C and C++ are not the same languages, and you'll only lead yourself into a world of hurt by using C APIs when you don't have to.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this