Index
> High Level Languages > C++ or ASMGoto page Previous 1, 2, 3, 4, 5 Next |
| Author |
|
|
kohlrak 27 Jul 2006, 20:20
but i am right, right? It is nothing more than sending EAX data which is never used or looked at, just eventually written over.
|
|||
27 Jul 2006, 20:20 |
|
|
okasvi 27 Jul 2006, 20:37
f0dder wrote: if you're going to use a language that has a standard, better follow the standard. Agreed. kohlrak wrote: If "the program crashes" it's the same as a program that "crashes" using "int" type. No, the program should have enough error-checking/use SEH to prevent crashing, and instead of crashing try to fix the problem on it's own(alloc more mem or something like that), and if it doesnt work maybe printf/msgbox and return false to indicate that it was _not_ successfully ran. _________________ When We Ride On Our Enemies support reverse smileys |: |
|||
|
27 Jul 2006, 20:37 |
|
|
vid 28 Jul 2006, 08:30
f0dder: there is absolutely straightforward analogy between calling function about which you know that doesn't return anything, and calling app about which you know it doesn't call anything.
Behavior is undefined SAME way as within application using void funcs. Caller should know what his child returns. It would be something other if system, or somebody who awaits something exact returned, would check your apps returns code, but can you give me some real-world example where this happens |
|||
|
28 Jul 2006, 08:30 |
|
|
f0dder 28 Jul 2006, 11:29
vid wrote:
I already did - make.exe when processing makefiles. If an application returns a non-zero code, the make process will terminate. Fortunately, both MSVC and GCC work around broken code(!) by making "void main()" returning 0, but there's no guarantee that all C compilers will do this. And for C++, it's actually a violation of The Standard(TM) to have main return anything but int (GCC enforces this, MSVC doesn't even give a warning). |
|||
|
28 Jul 2006, 11:29 |
|
|
kohlrak 30 Jul 2006, 07:40
okasvi wrote:
Then the program would go through it's error checking and such and close, then having not point to the return code anyway. Quote: Behavior is undefined SAME way as within application using void funcs. Caller should know what his child returns. It would be something other if system, or somebody who awaits something exact returned, would check your apps returns code, but can you give me some real-world example where this happens You mean runtime, correct? Quote: I already did - make.exe when processing makefiles. If an application returns a non-zero code, the make process will terminate. Fortunately, both MSVC and GCC work around broken code(!) by making "void main()" returning 0, but there's no guarantee that all C compilers will do this. But you don't compile the app at runtime do you? You just use the EXE. He means runtime, i do beleive. So can you provide an example during runtime that is waiting for the return value? |
|||
|
30 Jul 2006, 07:40 |
|
|
vid 30 Jul 2006, 16:12
kohlrak: it IS valid example, think about writing some utility that will be used in makefile
btw, "void main" is discussed here by some guy   |
|||
|
30 Jul 2006, 16:12 |
|
|
f0dder 30 Jul 2006, 19:45
Hehe, "some guy"
|
|||
|
30 Jul 2006, 19:45 |
|
|
kohlrak 31 Jul 2006, 00:24
Well, then, if you're not using the makefile, nothin' wrong with it, eh?
|
|||
|
31 Jul 2006, 00:24 |
|
|
f0dder 31 Jul 2006, 01:45
Read the link vid posted, kohlrak. The text is by the guy who made C++.
|
|||
|
31 Jul 2006, 01:45 |
|
|
vid 31 Jul 2006, 11:39
Quote: Well, then, if you're not using the makefile, nothin' wrong with it, eh? well, if you are not using your program from tools that await return value. but you never know who will use your tool, and he can stick to standard. but this hole is IMHO finely fixed by making "void main()" always return 0. You don't care what it returns (thus "void"), and if caller cares he always gets 0 |
|||
|
31 Jul 2006, 11:39 |
|
|
rwalt 20 Aug 2006, 20:16
The vast majority of all software is written in C++. Learn C++. Get really good at reading and writing C++ programs.
With the rise of Mac OS X's popularity (it just blows Windows away), another language to consider is Objective-C. _________________ DarkStar |
|||
|
20 Aug 2006, 20:16 |
|
|
Maverick 21 Aug 2006, 08:24
Objective-C IMHO is inferior than C++. I see no point in learning Objective-C when you have access to good quality ISO C++ compilers.
|
|||
|
21 Aug 2006, 08:24 |
|
|
rwalt 22 Aug 2006, 05:27
Yes, I agree that C++ is better. The Cocoa.Framework for OS X is implemented in OC, you can use C/C++ for the Carbon.Framework though, it's more like the Win32 API in how you build .app files for OS 10.4.
Xcode is a really nice IDE. _________________ DarkStar |
|||
|
22 Aug 2006, 05:27 |
|
|
Maverick 22 Aug 2006, 06:41
Yup, and it's free and, even better, comes with every Mac.
Recall the 8bit home computer days when you got a BASIC manual (sometimes even the manual for a built-in assembler/monitor!) with the machine! Per contra, on Windows the more the user is ignorant, the happier the selling company is. I guess that if every user was more or less a programmer would cut the earnings of many companies selling small, stupid programs. |
|||
|
22 Aug 2006, 06:41 |
|
|
f0dder 22 Aug 2006, 11:48
Humm, what's the "new" GUI layer in OS X? Cocoa or Carbon?
/me forgot |
|||
|
22 Aug 2006, 11:48 |
|
|
rwalt 22 Aug 2006, 18:30
Probably Cocoa, not sure on that.
You know, it would be cool if you could get FASM to work on the new Intel Macs, but at the Darwin Unix layer the system is 64 bit. _________________ DarkStar |
|||
|
22 Aug 2006, 18:30 |
|
|
f0dder 22 Aug 2006, 21:46
It doesn't have a compatibility layer for 32bit apps?
I guess it's not that high priority for Apple... just like it's not high priority having lots of hardware support (actually you could say it's high priority NOT having lots of hardware support, until they give in and let people run x86 OS X on 'standard' PCs). |
|||
|
22 Aug 2006, 21:46 |
|
|
rwalt 23 Aug 2006, 05:15
Your right, they need to give in and package X for PCs
On the Darwin thing, this is what I get trying to link fasm.o using gcc... $ gcc fasm.o -o fasm /usr/bin/ld: fasm.o bad magic number (not a Mach-O file) collect2: ld returned 1 exit status At the Unix level X is 64, Cocoa and Carbon are 32. The release next year of 10.5 Leopard promises fully 64 bit up thru the GUI layers, with 32 bit compatibility. And again I agree, they need to package it for PCs too. The next release would be a good start to do just that. _________________ DarkStar |
|||
|
23 Aug 2006, 05:15 |
|
|
f0dder 23 Aug 2006, 10:49
The default format for OSX is Apple's Mach-O format, not ELF... dunno if there's a compatbility layer for elf? Or if you could build a cross-compiler version of GCC that supports ELF input but can build Mach-O output.
Btw when saying "At the Unix level X is 64", I hope you're not meaning X11, but rather the "core" of OSX |
|||
|
23 Aug 2006, 10:49 |
|
| Goto page Previous 1, 2, 3, 4, 5 Next < Last Thread | Next Thread > |
Forum Rules:
|