Between every now and then I get an idea, which is to make a little test app (to test some idea I just got from nowhere), It's said that C++ is the language of choice for quick coding (and I've programmed in C++ long time ago), so I start to write the .cpp file.
When comiling, I get errors like "can't convert 'unsigned long' to '_COORD'", which is a stupid thing since an unsigned long is: 32-bits, a cord is make up of two short variavbles (short = 16-bit). And I've treid all typecast I can imagine (even float), but no, I have to do it the long, --[ o v er b l o a t ]--, way:
COORD stupid_var;
stupid_var.x = uint0;
stupid_var.y = uint1;

This isn't the first time I get error like this, perhaps it's the compiler, me, or is C++ really that HLL (so it has forgotten the real data types: (bit, nibble), byte, word, dword, qword, etc)?

IN the end, it all ended up as usual: I abandonned the C++ version, sweard never to try it again and started to code it in asm, which is faster to code and easier then C++. C++ is just IMO an ineffectivce way of coding, and no wonder why the files det "enourmous", when one can't do simple things in a simple way, such as move dword sized data into a struct with only two word sized variables.

Can some one please tell me why C++ was invented, it can't have been to make app making faster (compile time is much slower too, no one second builds...)
Posted on 2003-06-06 16:07:40 by scientica
hehe :-D You program too much in assembly recently and you forgot the "standard" C/C++ way of doing it. :grin:

Anyway, if you want to do what you originally intended to do, only thing I can come up with is to use memcpy(). -- This is sort of "standard hack" in C world. But, you know it very well that using memcpy() for 4 byte variable is overkill, unless the compiler is smart enough to generate simple mov for that.
Posted on 2003-06-06 17:24:20 by Starless
This works:


void printCoord(const COORD &s)
{
cout << hex;
cout << "X is " << s.X << ", Y is " << s.Y << endl;
}

void foo()
{
COORD s;
unsigned long l = 0x12345678;
*(unsigned long*)&s = l;
printCoord(s);
}


And foo() compiles to:


push ecx
lea eax,[esp]
mov dword ptr [esp],12345678h ; <<<<<
push eax
call 00401030
add esp,8
ret

So the result is pretty much the same as the result in asm..

No offence intented, but the people who say coding in asm is faster than in HLLs usually just haven't got enough HLL experience.. Also, you're an asm programmer, you think in an assembly way. That's not the right way to think when programming C++. In assembly, you think at the machine level, COORD=DWORD=everything that's 4 bytes. And it's true, that's how it's implemented.

C++ doesn't think at implementation level, so you have to think differently as well. A COORD isn't a DWORD, because a COORD is something with an X and an Y coordinate, while a DWORD is just an unsigned long integer. If they were the same they would have given them the same name. If a function says wants a COORD you don't give it a DWORD.

The advantage of a compiler is that the compiler figures out the implementation. If you use a COORD in assembly, it's your choice to put it in a register or a memory variable. You'll have to think about this, not the assembler. With a compiler, you just use COORD and then the compiler figures out 'hey, a COORD is 32-bits in size, I might put that in a register'. What you're doing with putting a long into a COORD is actually something the compiler should do, not you. You're thinking at the wrong level.

C++ also was created with portability in mind. In fact, if the windows API didn't set compiler flags to prevent it, a COORD might have been any size the compiler likes. C++ doesn't guarantee two structure members are right after each other in memory. What if you compile the program on a sparc machine or something, that *requires* alignment of data. In that case, it's not always possible to have a continous structure. Some padding might be necessary to align the next piece of data. Did you know that in C++, 'B'-'A' doesn't necessarily have to be 1? C++ allows machines that have totally different character set mappings, so in fact even comparisons like c >= 'A' && c <='Z' aren't portable (that's why there are functions for that like isupper()). Or that a C++ char can possibly be 12-bits?

Since sizes of C++ types are measured in chars, on a machine with 12-bit chars every type has to be a multiple of 12-bits. You couldn't even create a COORD struct of 32-bits on such a machine. Still, C++ is designed to run on any machine so that's why you have to do dirty tricks to do what you want (long -> COORD). If you use such tricks, you'll loose the portability.

The problem with the windows API is that it relies a lot on the properties of the x86. It can make a COORD 32-bits because that's possible on the x86. And it needs to give it a fixed size because it has to be binary compatible with windows. Windows expects a 32-bits COORD so the compiler has to use 32-bits. However, using standard C++ without compiler specific options, it's impossible to guarantee a COORD struct will be 32-bits.

It's only because you know of these properties the windows API enforces on the compiler output, that you can put a long in a COORD. But in pure C++, this would never be allowed. And *that's* exactly the reason why you can't 'just copy a long over a COORD' in C++.

Thomas
Posted on 2003-06-06 18:04:27 by Thomas
Originally posted by Thomas
No offence intented, but the people who say coding in asm is faster than in HLLs usually just haven't got enough HLL experience.. Also, you're an asm programmer, you think in an assembly way. That's not the right way to think when programming C++. In assembly, you think at the machine level, COORD=DWORD=everything that's 4 bytes. And it's true, that's how it's implemented.

(no offence taken :))
It's true that I have rather little HLL skils (if one except (V)Basic, which basically is english), I stoped learning/using C++ (stopped in the sence that I don't use it more than a few times a year), the reason for stopping was the fact that I began to learn asm, which to me is easer to understand and gives me more control (what I tell the computer to do it does, more or less).
I still say that coding in asm is faster, wheter you right about why I think so I don't really know. :tongue:

C++ also was created with portability in mind. In fact, if the windows API didn't set compiler flags to prevent it, a COORD might have been any size the compiler likes. C++ doesn't guarantee two structure members are right after each other in memory. What if you compile the program on a sparc machine or something, that *requires* alignment of data. In that case, it's not always possible to have a continous structure. Some padding might be necessary to align the next piece of data. Did you know that in C++, 'B'-'A' doesn't necessarily have to be 1? C++ allows machines that have totally different character set mappings, so in fact even comparisons like c >= 'A' && c <='Z' aren't portable (that's why there are functions for that like isupper()). Or that a C++ char can possibly be 12-bits?

Portabillity, I prefer compabillity.
IMO portabillity means limiting things to a certain level where "everyone/thing" can do the same/similar thing.
Compabillity means to me, all I do will run as it is, with out modifications, recompilation or such, optimizations will run (as long as they follow the official documentations/recomendations, special "hacks" however are another battlefield).
'A'-'B' doesn't have to be 1 any where, 'just' remap the keyboard/character layout :P

The problem with the windows API is that it relies a lot on the properties of the x86. It can make a COORD 32-bits because that's possible on the x86. And it needs to give it a fixed size because it has to be binary compatible with windows. Windows expects a 32-bits COORD so the compiler has to use 32-bits. However, using standard C++ without compiler specific options, it's impossible to guarantee a COORD struct will be 32-bits.

Well that's no problem, the Windows API (Win32 API) is made for the x86 architecture, it's used on Windows versions made for 32-bit CPUs, if there were to be a 12-bit machine, well then a 13-bit OS would be required, and then it would be naturaly for that OS to have a 12-bit API. Don't say that that would make it hard/impossible to run 32-bit apps on a 12-bit machine, think of the 64-bit machines (pre Opteron), could apps written for a 64-bit mahine (lets say an Itanium) run on a 32-bit machine (how about a Pentium III) , no (well, yes there are _emulators_ for both architectures).

It's only because you know of these properties the windows API enforces on the compiler output, that you can put a long in a COORD. But in pure C++, this would never be allowed. And *that's* exactly the reason why you can't 'just copy a long over a COORD' in C++.

It's clear to me that assembly is what I'll stick to, unless I start doing all in hex (not likeley thought, however some bit fiddeling I'll do, since it's fun :)).
This proves IMO that in C++ you can't always do what you want (there is a limit to what you can do), and that C++ don't give you the control you may want over your sources.
Posted on 2003-06-06 19:44:53 by scientica
Thomas, it seems to me that you opened another can of worms. Portability of, say, C++ (or any other HLL for that matter) is not clear in practice.

As I see it, there are two approaches to the portability: One is "stick to the standard" approach and the other is "install my software bundle everywhere" approach.

I was (and still am) of the first kind. But, sticking to the standard did not give me much. Some useful (maybe only to me) library, but no useful app. To create a useful app, one has to get to know the target system itself (e.g. socket) and some interface library, be it Curses, Motif, or MFC. They are not the same across all platforms, not to mention machine architectures. So, sticking to the standard is only good for people like me whose coding is not for mass consumption.

This difficulty with standard led to the second approach, typically employed by FSF and related software projects. This is actually non-portability in disguise. Take, for example, Cygwin. Not to mention the implementation quality or possibility, they simply impose their own way of doing things to users. And, they claim portability between linux and windows. Wow, unbelievable. I don't think that is truely portable. Do you? This approach is annoying in that I have to install unwanted things only because I want to compile self-claimed "portable" software.

Oh, yes, there is another approach: "#ifdef everything", but this is not a truely portable way of coding something, either. It's just masquerading a non-portable code as portable by making it compile several different places. But, at the surface, this looks better than "install mine everywhere". A good example is Mozilla. Mozilla runs smooth on platforms that it supports. It does not insist on using gtk+ on Win32, nor using Win32 API on linux.

Then, the question remains unanswered. Are HLL (not just C++) really "portable" and useful at the same time?
Posted on 2003-06-06 21:53:27 by Starless
This proves IMO that in C++ you can't always do what you want (there is a limit to what you can do), and that C++ don't give you the control you may want over your sources


yes, ypu can do whatever you want, if you want more control, you can use a objet file or other directly generated for example by nasm, masn, tasm, goasm, or you simply can choice to use the __asm__ block specific of you C or C++ compiler, in fact, java let you use asm or other native software, this is called JNI, like you see, a HLL let you use a low level programm if you want, maybe you lose some portability, all like you and me know is choice of the programmer, the right tool for the right job.

The Hll are for easy deploy is more easy see a structure like a loop and see inmediately the start and the end.. onyl if you are good programmer in asm can seee easely (or have consistent and logic indentation), and you have the option of think more in the solution fo the problem (algo) than think in what or what register you will use or what others no.

In other form, you have too a lot of diferent data tyoes.. remember?? WORD,DWORD, HANDLE, HINSTANCE, LPSTR, remeber but why not simple 4???, yes the answer is give a subjetive meaning of what we are doing..

In fact, you can code like you want, but for me knowledge is power, fi you know good asm, why not learn C????.

Also like i think you can have good or bad experiences, but is like all, some say that windows sucks.. also i dont remember the famouse BLUE window, i know how use windows, i can say linux sucks, but is that i dont know how to install some things...

Yes is more fast to deply in C in the way that you dont need learn the internal structure (register, memory, loops), [ also, you can translate from C to C++ in one day... (by examples) and to java in maybe 5 days].. you have all this cover by the compiler, i remember time a go, in this board see a "example" iin C vs asm, compared with a guy that use a bicicle and the boy that make the bicycle, i consider that example.. a little wrong.. saying that the person that make the bicicle have all the power.. this is not true, think in the way that this guy at the end, maybe know all the internal structure of the bicicle, but the person that use the bicicle have the posibility of make fun things like "acrobatics" and this guy maybe can see some thing that this bicicle need for the personal use of this person, instead the other person, only know the internal, yea, can too manipulate some things, but only in the internal way, but maybe... can not make acrobatics.. or maybe can...

If you dont trust in my.. that this maybe is a bad example, question the facturer of some good bicicles, and question if they can do the acrobatics of the persons that buy that bicycles?? the most probably is that they say, i can only run in the bicicle and jump, but i can not make some beabtifull acrobatics that they can (they know the internals, but not know the other level).


That is my opinion, personally i understand more things with asm, but why i dont understand some things in C/C++?? because is designed for hide that things... :)..

That is my opinion.



in this post.. i really feel my short knowledge of some words of your language.. lol, sorry for that...mm i can understand a little german.. and i never take a course ;)
Posted on 2003-06-06 22:58:53 by rea


(no offence taken :))
It's true that I have rather little HLL skils (if one except (V)Basic, which basically is english), I stoped learning/using C++ (stopped in the sence that I don't use it more than a few times a year), the reason for stopping was the fact that I began to learn asm, which to me is easer to understand and gives me more control (what I tell the computer to do it does, more or less).
I still say that coding in asm is faster, wheter you right about why I think so I don't really know. :tongue:

I won't stop you from coding in anything. If you like asm and code fast in asm, use asm :) However I think you could code faster in C++ if you'd spend some time learning it well. In fact, some years back I could code faster in asm than C++ as well.. Now that I know it well and used it for a couple of years it's the other way around.


Portabillity, I prefer compabillity.
IMO portabillity means limiting things to a certain level where "everyone/thing" can do the same/similar thing.

But what is portability limiting? The implementation? The language features? As long as the machine it's running on is Turing complete (I don't know of any computer that isn't ;)), everything is possible on it. But possibly not directly. For example, simple microcontrollers often lack a multiplication instruction. Does that mean you can't run C++ on it? No, it means the C++ compiler has to figure out how to multiply (by emulating it with shifts or something). That's the power of a compiler. If you would use an assembler, you're limited by the instructions of the machine (though you can emulate yourself of course). C++ defines standard features that are guaranteed to work on every machine, even though the hardware may not directly support it. An expression like (a+b*c) % d is always valid, no matter what it's running on.
A problem here is the size of datatypes, which are not strictly defined in C++. An int may be 32-bits, but also 64 or 189 if you like. Still, some guarantees are given, like long >= 32-bit, short >= 16-bit, char >= 8-bits, and long >= int >= short >= char. These things can be used when using bitflags, but naturally you'll have to limit yourself to the above values if you want to keep it portable.

Compabillity means to me, all I do will run as it is, with out modifications, recompilation or such, optimizations will run (as long as they follow the official documentations/recomendations, special "hacks" however are another battlefield).
'A'-'B' doesn't have to be 1 any where, 'just' remap the keyboard/character layout :P

Compatibility is fine for systems that use the same architecture and processor, like your programs that run on NT, 2000 and XP fine. But compatability is not really portable. You can't use a windows executable on a non-x86 linux machine without emulating it. Portability nearly always requires recompilation, which is good since the output will be written specificly for the target system, giving optimal performance.

Well that's no problem, the Windows API (Win32 API) is made for the x86 architecture, it's used on Windows versions made for 32-bit CPUs, if there were to be a 12-bit machine, well then a 13-bit OS would be required, and then it would be naturaly for that OS to have a 12-bit API.

That's true, my point was that using any OS specific API makes portability nearly inpossible and often requires non-standard C++ things to get the binary compatibility with the OS (think of forced structure packing). Portability is really hard if you're using APIs, on any OS.

Don't say that that would make it hard/impossible to run 32-bit apps on a 12-bit machine, think of the 64-bit machines (pre Opteron), could apps written for a 64-bit mahine (lets say an Itanium) run on a 32-bit machine (how about a Pentium III) , no (well, yes there are _emulators_ for both architectures).

Of course, emulation always solves the problem, but it's not a really efficient solution. Without an emulator, data types will change and it will never be able to run unless the API itself is adjusted accordingly.

It's clear to me that assembly is what I'll stick to, unless I start doing all in hex (not likeley thought, however some bit fiddeling I'll do, since it's fun :)).
This proves IMO that in C++ you can't always do what you want (there is a limit to what you can do), and that C++ don't give you the control you may want over your sources.

There is a limit, yes. But this limit has never caused me much trouble. Of course, the occasional dirty cast comes around, but almost exclusively when dealing with the windows API. If you stay away from APIs (yes I know that's not easy and often impossible ;)), you don't need tricks.


Thomas, it seems to me that you opened another can of worms. Portability of, say, C++ (or any other HLL for that matter) is not clear in practice.

As I see it, there are two approaches to the portability: One is "stick to the standard" approach and the other is "install my software bundle everywhere" approach.

I was (and still am) of the first kind. But, sticking to the standard did not give me much. Some useful (maybe only to me) library, but no useful app. To create a useful app, one has to get to know the target system itself (e.g. socket) and some interface library, be it Curses, Motif, or MFC. They are not the same across all platforms, not to mention machine architectures. So, sticking to the standard is only good for people like me whose coding is not for mass consumption.

As I said, portability is very hard when using OS features (which you often need). There are many good libraries out there though. The C++ STL is available on nearly any C++ platform, and makes it possible to do portable file/console I/O. Also GUI libraries like wxWindows, QT, etc. allow multi-platform GUIs. But it's true that you're limited by the platforms supported by the libraries.

This difficulty with standard led to the second approach, typically employed by FSF and related software projects. This is actually non-portability in disguise. Take, for example, Cygwin. Not to mention the implementation quality or possibility, they simply impose their own way of doing things to users. And, they claim portability between linux and windows. Wow, unbelievable. I don't think that is truely portable. Do you? This approach is annoying in that I have to install unwanted things only because I want to compile self-claimed "portable" software.

This is the approach java has taken. Java programs need a java interpreter. It works and it's very portable, but like you said, it's not the real thing.

Oh, yes, there is another approach: "#ifdef everything", but this is not a truely portable way of coding something, either. It's just masquerading a non-portable code as portable by making it compile several different places. But, at the surface, this looks better than "install mine everywhere". A good example is Mozilla. Mozilla runs smooth on platforms that it supports. It does not insist on using gtk+ on Win32, nor using Win32 API on linux.

As long as wrappers are written for all supported OSes, it should work fine. And a lot of work :)

Then, the question remains unanswered. Are HLL (not just C++) really "portable" and useful at the same time?

Pure C++ is portable. So are libraries written in pure C++. Problems start when using an API. But that's hardly surprising, if you choose to use a specific API, of course it won't run on other platforms. But that's not a problem of C++ or any HLL, the problem is that all APIs are different and you can't do much about that other than the solutions you already mentioned.

My main point was to point out why scientica couldn't easily copy a long over a coord. The reason is that C++ does its best to be portable. And such an action would break portability. As scientica showed, there is a portable way to do it. If the next version of windows will have coords of 128 bits, that would still work. They won't do that, since old programs would not be binary compatible anymore. If the API had a clean C++ interface, it would not be a problem to switch to larger coords. It hasn't, so were stuck with what we have.



This proves IMO that in C++ you can't always do what you want (there is a limit to what you can do), and that C++ don't give you the control you may want over your sources

yes, ypu can do whatever you want, if you want more control, you can use a objet file or other directly generated for example by nasm, masn, tasm, goasm, or you simply can choice to use the __asm__ block specific of you C or C++ compiler, in fact, java let you use asm or other native software, this is called JNI, like you see, a HLL let you use a low level programm if you want, maybe you lose some portability, all like you and me know is choice of the programmer, the right tool for the right job.

No you can't do what you want. Well you can, but not without ugly casts so you shouldn't (because it breaks portability). Question is: do you need such a level of control? In pure C++, no. When using APIs, you'll have to. It's the strong requirements of the API that forces you to use these kinds of casts. Not C++.

The Hll are for easy deploy is more easy see a structure like a loop and see inmediately the start and the end.. onyl if you are good programmer in asm can seee easely (or have consistent and logic indentation), and you have the option of think more in the solution fo the problem (algo) than think in what or what register you will use or what others no.

It's up to you whether you want to have this choice. Usually, I don't care. I just want a while loop, if statement or something else and let the compiler decide. In some cases I care and I'll have to do it myself. It's a choice, everything has its advantages and disadvantages.

In other form, you have too a lot of diferent data tyoes.. remember?? WORD,DWORD, HANDLE, HINSTANCE, LPSTR, remeber but why not simple 4???, yes the answer is give a subjetive meaning of what we are doing..

The answer is abstraction. The higher the language, the more abstraction you get. Why not make the whole language only accept hex codes? In the end, code and data is all the same, just a bunch of bytes. Assembly is the first level of abstraction. No bytes, but opcodes. DWORD=HANDLE=HINSTANCE=LPSTR, they're all the same in the end. HLLs think differently. Sure, they are the same physically, but not conceptually. Of course a string pointer is not a file handle. And you shouldn't treat them as such. If you would, you could pass a file handle to a string function and that's just wrong. The different types prevent this already at compile time.
Also, multiple types give the flexibility to change them later. The windows API wouldn't be a good example because of the binary compatibility, but what if a handle in some other cross-platform library would not have its own type but 'int' was used instead. Suddenly the need arises to change the handle type to some_struct *. If it had its own type, this is perfectly possible. If all code just used int, it isn't.

Thomas
Posted on 2003-06-07 04:52:53 by Thomas

yes, ypu can do whatever you want, if you want more control, you can use a objet file or other directly generated for example by nasm, masn, tasm, goasm, or you simply can choice to use the __asm__ block specific of you C or C++ compiler, in fact, java let you use asm or other native software, this is called JNI, like you see, a HLL let you use a low level programm if you want, maybe you lose some portability, all like you and me know is choice of the programmer, the right tool for the right job.


-cought-, -cought-, when you're using __asm block then you're doing asm not C++...,
and the __asm block, well they shouldn't be allowed, since they're not protable, right?

What troubles me is the level of abstraction in HLLs, it's "incompatible with my optimal thinking" which means all these abstratcions irritates me since I can't do what I want, when I develop I develop for a specific arcitecture (which mean I intend to use archtecure specific instrucitons, and things such as DWORD==COORD==HANDLE ), preferably x86 (soon x86-64 hope fully), I'm not writing code for PPC, or Mac, If I were to code for those machines I'm sure I'd do that for a specific task, thus I'd have to use machine specific features. IMO x86 is the "Stanard" architecture, used by the most people, servers use afaik mostly 64-bit CPUs, has their own OSes wich uses the distingctivness of the 64-bit CPUs to function as Servers should do, servers aren't made for playing computer games, so thay don't need AGP, they can do with an old monitor and VGA, EGA or such.

C++ is IMO, a nice idea, but there are some problems, everything isn't portable, like the __asm blocks, why are they allowed in C++ (or are they not a part of the Standard C++ (ANSI C++?) )

What the point of makin code portable (and avoiding architecture specific features) if you only intend to use it on one specific architecture?
Posted on 2003-06-07 05:59:58 by scientica
that's what you got a preprocessor for scientica, to make different builds based on user set flags.

So you could write in a routine different versions of the asm piece but for different CPU architectures.
Posted on 2003-06-07 06:19:32 by Hiroshimator


But what is portability limiting? The implementation? The language features? As long as the machine it's running on is Turing complete (I don't know of any computer that isn't ;)),
Thomas


Technically, to be truly Turing Complete requires an infinite amount of memory; so no machine in existence is truly Turing Complete. The phrase "Turing Complete" generally applies to languages, not hardware (we say that a language is "Turing Complete" if you can compute any function that is possible to compute on a TM within that language).

However, for all practical purposes, your point is well taken.
Cheers,
Randy Hyde
Posted on 2003-06-13 10:19:59 by rhyde
Originally posted by scientica
Between every now and then I get an idea, which is to make a little test app (to test some idea I just got from nowhere), It's said that C++ is the language of choice for quick coding


Who said that?
C++ is a huge language that doesn't support the concept of restrictibility very well (meaning you have to learn a very large percentage of the language in order to effectively use it). C++Builder aside, C++ is one of the last languages I would think of for banging out quick and dirty code. Maybe Ada and PL/I are worse, but there are much better alternatives for banging out stuff quick. Heck, for Q&D stuff, VB is a whole lot better (not that I know VB that well, but...)


(and I've programmed in C++ long time ago), so I start to write the .cpp file.
When comiling, I get errors like "can't convert 'unsigned long' to '_COORD'", which is a stupid thing since an unsigned long is: 32-bits, a cord is make up of two short variavbles (short = 16-bit). And I've treid all typecast I can imagine (even float), but no, I have to do it the long, --[ o v er b l o a t ]--, way:
COORD stupid_var;
stupid_var.x = uint0;
stupid_var.y = uint1;


You just don't know enough C++ (actually C); that's all. Someone else has posted the solution to this problem so I won't repeat it. It *is* possible to think in assembly and code it C/C++. This is the best way to write code that is high-performance in C++. It does take, however, quite a bit of study to achieve this level and thinking you can pick up a C++ compiler one day and crank out code to your satisfaction is about like some C++ programmer thinking they can write optimized assembly code because they've got an Intel instruction reference handy. In both cases, it takes considerable experience that is gained through a lot of hard work with the language.


This isn't the first time I get error like this, perhaps it's the compiler, me, or is C++ really that HLL (so it has forgotten the real data types: (bit, nibble), byte, word, dword, qword, etc)?


Actually, C/C++ are among the few languages that let you access these data types at such a low level. Try this in ISO Pascal some time :-)


IN the end, it all ended up as usual: I abandonned the C++ version, sweard never to try it again and started to code it in asm, which is faster to code and easier then C++. C++ is just IMO an ineffectivce way of coding, and no wonder why the files det "enourmous", when one can't do simple things in a simple way, such as move dword sized data into a struct with only two word sized variables.

Which is a real shame (abandoning C++). Because had you stuck it out and seen it through, you might have learned how to do this in C++ so that the next time you wanted to crank out a Q&D solution in C++, you would have known how to do this operation. (And, hopefully, you've read the posts that have followed so that you have seen the right way to do this).


Can some one please tell me why C++ was invented, it can't have been to make app making faster (compile time is much slower too, no one second builds...)

It was invented to extend C into the OOP world, not make life easier for assembly programmers :-)

Seriously, though, if you want to crank out Q&D programs using assembly with a HLL-like ease of use, take a look at HLA. It allows you to work in low-level assembly to your heart's content and then jump up to a higher level of abstraction when you want to crank out some code real fast. And you can do all that without having to learn a new language.
Cheers,
Randy Hyde
Posted on 2003-06-13 10:32:07 by rhyde
Originally posted by randall.hyde
Who said that?

Some internet pages, at least one book (which I unfortainly don't recall the name off), and an programmer I used to know (he worked with C++ and other languages). Maybe thay knew a lot of C++?


(not that I know VB that well, but...)

You speak basic english, you can do basic basic programming :)

You just don't know enough C++ (actually C); that's all. Someone else has posted the solution to this problem so I won't repeat it. It *is* possible to think in assembly and code it C/C++. This is the best way to write code that is high-performance in C++. It does take, however, quite a bit of study to achieve this level and thinking you can pick up a C++ compiler one day and crank out code to your satisfaction is about like some C++ programmer thinking they can write optimized assembly code because they've got an Intel instruction reference handy. In both cases, it takes considerable experience that is gained through a lot of hard work with the language.

I might be facing a choice in some months/weeks time, either to start doing some C++ or stick hard to asm and attempt to master it (mastering a language takes time, so better not wait till to morrow). A few weeks ago I was dead sure on the last, but I've spend some more thinking on the issue. What I need is some more time to think of this matter, and some more sales talk on C++ ;), seriously, what I need is some explanation what I can do with C++, OOP and such, I'm talking what "real" stuff I can dow with it, that I can't do easier/more effective with asm.

Which is a real shame (abandoning C++). Because had you stuck it out and seen it through, you might have learned how to do this in C++ so that the next time you wanted to crank out a Q&D solution in C++, you would have known how to do this operation. (And, hopefully, you've read the posts that have followed so that you have seen the right way to do this).

I abandoned C++ becuase sitting and fighting the IMO, stupid error wouldn't help me get the darn idea out of my head any fasten than me "going asm".

It was invented to extend C into the OOP world, not make life easier for assembly programmers :-)

Well, what is OOP good for, and excatly what is it? Except getting quick head aces (that's my experience with it)? what can I use it for, except some fancy tech show off?

Seriously, though, if you want to crank out Q&D programs using assembly with a HLL-like ease of use, take a look at HLA. It allows you to work in low-level assembly to your heart's content and then jump up to a higher level of abstraction when you want to crank out some code real fast. And you can do all that without having to learn a new language.

I'll take a look at it, and see if I understand it :)
Posted on 2003-06-13 18:03:48 by scientica
I might be facing a choice in some months/weeks time, either to start doing some C++ or stick hard to asm and attempt to master it (mastering a language takes time, so better not wait till to morrow). A few weeks ago I was dead sure on the last, but I've spend some more thinking on the issue. What I need is some more time to think of this matter, and some more sales talk on C++ ;), seriously, what I need is some explanation what I can do with C++, OOP and such, I'm talking what "real" stuff I can dow with it, that I can't do easier/more effective with asm.

You probably made the right choice :-)
The advantage of OOP (which C++ doesn't really get right, btw) is that it makes it a whole lot easier to write generic code that you can reuse. However, unless you've got some really good class libraries, you're not going to enjoy the benefits of OOP without a *whole* lot of up front work. And understanding, really understanding, OOP is something that takes years, not weeks or months. If you're not committed to learning it over a long period of time, it's probably not worth the attempt at all.


I abandoned C++ becuase sitting and fighting the IMO, stupid error wouldn't help me get the darn idea out of my head any fasten than me "going asm".

That's why I went back to C from C++. C++ is a gross language from a language design point of view. For every good idea present in C++ there are three bad ideas. Most of them cannot even be justified by the argument of backwards compatibility with C. Oh well, too late to do anything about it now.


Well, what is OOP good for, and excatly what is it? Except getting quick head aces (that's my experience with it)? what can I use it for, except some fancy tech show off?

OOP is really good for code reuse. OOP makes it possible to write generic subroutines that process different data types with ease.



I'll take a look at it, and see if I understand it :)

Just keep in mind, HLA is two languages - there is the low-level assembly stuff that you already know (though in a different syntactical form) and then there is the high level language. Start with the stuff you're comfortable with and work you way up.
Cheers,
Randy Hyde
Posted on 2003-06-13 18:29:54 by rhyde
First, I'll say why I like C.

The most annoying thing about ASM is you have to juggle registers around. Push this, pop that, lea whatever. In C, there is no register juggling. You can focus on the problem that is at hand. Push's and pop's and lea's also clutter up the code.

I like C++ better than C because it adds more features to the language. In C++, I don't have to use classes to encapsulate everything; the C++ parser C as far as I know. C++ still has all the hearty trickery that is used in C. You can set a float variable to the value of an unsigned (unsigned u = 0x123; float f = *(float*)(&u);). You can even change the pointer to a classes vtable pointer at runtime if you wanted to using casting.

OOP is not a bad thing if you keep it from turning into a juggernaut that requires UML (::shudders::) for even the simplest program. I use classes to simplify programs.

Finally I like C++ because it looks prettier. You might think that sounds weird, but it helps alot when debugging. When I am writing a parser that has lists and trees with nodes connected with edges, I really don't want to worry about registers.

But that's just my oppinion. I can think in both C++ and ASM, but, ironically, I usually write in ASM when I want to reuse code.
Posted on 2003-06-18 16:58:26 by Paulicles the Philosopher
Scientica,
I suggest instead of trying to read a book on C++, read a book on Java and C# and read a book on oop .

C# and Java are both much better languages as far as OOP is concerned.
Remember its a completly new way of thinking when you start programming in OOP, and you will begin to see the advantages only after a while.

As far as oop and software design is concerned i would suggest you to read this book, which is also one of my favorites-

    [*]Applying UML and Patterns by Craig Larman


    You will have to know some uml before you start reading this book, but its an excellent guide as to how to use oop in your programs.
    Most books you will see on C++,C#, Java will just teach you how to use the oop constructs in the language. Like how to inherit a class and what are public, private memebers etc and their funcionality, and they will give you highly stupid examples of shapes,etc.

    But these books dont teach you how to apply oop in real world programs (which the above book does).

    So my advice to you would be that once you get the basic hang of HLL read a book on OOP not something like "Teach yourself C++ in 24 hours", cause just by knowing how to write a class in C++ and how to make an object of it, you wont be able to apply it to a problem.
Posted on 2003-07-03 13:19:31 by clippy
I hate C-style conversion. I hate having to press Shift so many times. I hate those {} brackets. I hate being told that HWND cannot be converted to dword, or that I might lose some data when I store a double into float. I hate my need to check the asm output of C compiler to see whether it does it right. I hate having to trick the compiler all the time, so that it works right.
In other words ... I hate C
Posted on 2003-07-27 16:40:39 by Ultrano
Originally posted by Ultrano
[...]I hate being told that HWND cannot be converted to dword,

And why would you need to do that in C?

or that I might lose some data when I store a double into float.

How can you not loose data when you convert a double to a float? A double is 64-bit, a float is 32-bit (usually on x86 compilers).

I hate my need to check the asm output of C compiler to see whether it does it right.

It's a matter of trust, compilers actually do very well most of the time and when you know this (some need to see this to believe it) you can blindly trust the compiler will do its job. Sure, it will not optimize like a professional asm programmer but it definitely does it a lot faster and most of the time it doesn't really matter the code isn't fully optimal.

I hate having to trick the compiler all the time, so that it works right.

You don't have to trick the compiler if you just trust what it does. You only need to trick it if you want it to work *your* way, but that's just the wrong way if you're using a compiler. You need to think in a C(++) way, not in an asm way. I think that's the main reason asm programmers don't like it.. C doesn't work like asm, if you can't accept that fine but don't complain about the language then.

Thomas
Posted on 2003-07-28 02:39:01 by Thomas
About the double-float - I usually get a warning. I hate it :)
Hwnd - I had some compiler that always wondered how to convert dword to hwnd.
I do not like thinking in C.
C/C++ are great languages, but personally I don't like coding in thm. Mostly for the Shift stuff.

btw, I have to trick the compiler when I need to get the cycles count an iteration takes. If I do not do so, most times my tested function just gets replaced by "mov Something,7" . But this inconvenience is created by the power of the C/C++ compilers.
And, anyway, I have strange taste in coding - I dislike syntax highlighting, and I use nothing but my own text editor, with which I can hide huge parts of the code.
Posted on 2003-07-28 03:32:13 by Ultrano
The thing about HLLs such as C++, Java and C# is that they try to keep you on your toes, by making sure you write EXACTLY what you want.
So yes, if you assign a double to a float, it will warn... That way it forces you to think about whether you actually wanted to do this, or if you perhaps made a mistake, and should be using a double for that variable aswell.
You may not like it, because compilers constantly remind humans of the fact that they make mistakes, but in the end, it will generally make development faster and with less bugs...

As a side-note, there was a horror-story about a medical laser-system... The firmware for it was written in asm, and as it turned out, there was a bug in the code... But since it was in asm, the bug had gone unnoticed. The bug was something like this... after certain movements of the laser, the timer accidentally got reset, and the laser would stay on way too long.
It wasn't found out until it was too late, and people had been badly injured and/or died by the laser (it would just burn straight through them).

And because of that sort of thing, it's good that a compiler reminds you of the fact that you might make a mistake. Assembly puts too much of a responsibility on the coder (can you blame him for the accidents that happened, or not? That was the main question... Did he have the right to choose asm for this device, with the risks involved?).
Posted on 2004-01-25 06:33:14 by Henk-Jan
As for portability... if 90% of your code is dealing with GUI, your application is not going to be very portable almost no matter what you code it in - you will be limiting yourself to the availability of a GUI framework. If you have an application doing some "real" work, however, there's a good chance you can do something pretty portable. I think people tend to focus too much on the portability aspect of C/C++ though, as if that was the only benefit those languages have.

As for constant compiler warnings - design your code properly, and you won't see them :). This is somewhat hard when dealing with the windows API - if you insist on doing direct API calls everywhere, that is. That's a design error anyway, though. You shouldn't be interfacing with the OS at every level of your program, try to keep that to the "edges", clean modular code instead of spaghetti intertangled junk. It's a lot of bother writing a full class library, though :)

I'm glad I can keep the major parts of my programs in clean C/C++, speed-critical or 'dirty' code in asm, and that I don't have to deal with too much GUI stuff ;). Yes, I do need to find something nice & efficient for GUI coding...
Posted on 2004-01-25 07:34:33 by f0dder