flat assembler
Message board for the users of flat assembler.

Index > Heap > Next project FLAT C++ ? :-)

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
repne



Joined: 19 Jul 2006
Posts: 2
Location: Moscow, Russia
repne
I writting OS and need CPP BIN raw format .
Using FASM and want to write cpp code too.
But cpp compilers make bad exe with many unused
bytes. Tomasz, have are you idea to write Flat CPP in the future? Smile

Sorry for baaaaaad english, i dont known language. Sad

_________________
AMD forever Wink
Post 19 Jul 2006, 16:48
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
i think he is not going to write C++ compiler. Maybe he would design some low-level OOP language, but surely not write C++ Smile

In my opinion, C++ is extremely ugly language, which could have been done much clearer way.
Post 19 Jul 2006, 17:47
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
repne



Joined: 19 Jul 2006
Posts: 2
Location: Moscow, Russia
repne
C++ is extremely ugly language

whhhhhhhhhattttt ????????
C++ is superb system language !!!


---------------
developers , developers... (Steve Balmer) Very Happy
Post 19 Jul 2006, 18:22
View user's profile Send private message Reply with quote
JMGK



Joined: 26 Aug 2005
Posts: 27
JMGK
c++ ├╝ber alles
Post 19 Jul 2006, 19:24
View user's profile Send private message Reply with quote
okasvi



Joined: 18 Aug 2005
Posts: 382
Location: Finland
okasvi
I think we are getting offtopic here in Feedback, anyway, D ftw!
Post 19 Jul 2006, 19:29
View user's profile Send private message MSN Messenger Reply with quote
mattst88



Joined: 12 May 2006
Posts: 260
Location: South Carolina
mattst88
If you want a 'flat C++' compiler, you must know nothing about how C++ actually compiles.

Read up on vtables, for instance.
Post 19 Jul 2006, 21:59
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
i dislike C++ for being unclear and unpredictable (it becomes somewhat more predictable if you know assembly, but still)

what i mean: when you look at some construction, you can't say how it will beheave just from knowing general principes, you need to know this exact case to predict behavior.

even C suffered from this, in more complicated constructs (try to declare pointer to function which returns pointer to function, like in case of GetProcAddress, you will find out how many tries you will need). but in case if C++ it becamed worser (well, what the hell does clear language need 4 casts for?!?)


Last edited by vid on 21 Jul 2006, 05:04; edited 1 time in total
Post 19 Jul 2006, 22:04
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
Well, people still write in C++ (see small list of examples), so I don't think it's going anywhere.
Post 21 Jul 2006, 04:52
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Quote:

even C suffered from this, in more complicated constructs (try to declare pointer to function which returns pointer to function, like in case of GetProcAddress, you will find out how many tries you will need).

typedefs help *a lot* there.

Quote:

but in case if C++ it becamed worser (well, what the hell does clear language need 4 casts for?!?)

Safety... Smile
You don't really need typecasts for clean C++ code anyway. The problem is interfacing with legacy code, especially something as ugly as the PlatformSDK headers.
Post 21 Jul 2006, 08:42
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
f0dder: another C's problem is it's unsuccessful try to be multiplatform. Making C code multiplatform (over architectures) requires too much effort, because of different treating of things depending on platform.
Post 21 Jul 2006, 09:05
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
vid wrote:
f0dder: another C's problem is it's unsuccessful try to be multiplatform. Making C code multiplatform (over architectures) requires too much effort, because of different treating of things depending on platform.

It's not necessarily bad.

A friend of mine has a project that builds (and works) on 32- as well as 64-bit versions of linux, windows, solaris, Mac OS X, HP-UX, not to mention itanium and... what was that other weird he bought? Try doing that with assembly Smile

Everything is hard if you don't know how to do it. Same goes for writing portable code.

PS: I should add that there's even support for various compilers - at least GCC and MSVC.

_________________
Image - carpe noctem
Post 21 Jul 2006, 13:58
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Quote:
A friend of mine has a project that builds (and works) on 32- as well as 64-bit versions of linux, windows, solaris, Mac OS X, HP-UX, not to mention itanium and... what was that other weird he bought?

ask him how many data accessing macros and ifdefs he needs, in language which claims itself as made-to-be-portable

Quote:
Everything is hard if you don't know how to do it. Same goes for writing portable code.

but it could be much easier if C had other design
Post 22 Jul 2006, 09:06
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
RedGhost



Joined: 18 May 2005
Posts: 443
Location: BC, Canada
RedGhost
i don't recommend C++ for OS development
Post 22 Jul 2006, 10:35
View user's profile Send private message AIM Address MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Quote:

ask him how many data accessing macros and ifdefs he needs, in language which claims itself as made-to-be-portable

Almost no #ifdefs sprinkled all over the place (~10 of them in more than 200 files), encapsulating OS-dependant functions in one .h + one .cpp file. Typedefs for when it's necessary having exact size variables. A few macros. No use of exceptions. Writing CLEAN code.

Structure alignment and endianness can be a bitch.

Quote:

i don't recommend C++ for OS development

Why not?

There's some pretty nice things you can do with it. Of course I wouldn't use libc or STL, but write my own stuff. And I wouldn't use exceptions either. But there's benefits Smile
Post 22 Jul 2006, 16:22
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
f0dder wrote:
write my own stuff
That's exactly what I do in C -- I try to see it as a "half-way between asm and HLL". I mean, it's still structured, but I don't use too many headers/libraries (in fact, I don't even use the Standard library, I think it's tooo waaay bloated).

C is the only "acceptable" HLL I like because it's closer to asm than any other Wink. Of course, C is not C++.

I'm the kind of guy who really doesn't like OOP at all. First of all, it's always easier for me to think "exactly" in "computer terms" -- that is without nonsense (at least for me) like: Dog is inherited from animal, animal is inherited from creatures, from organisms, from sh**. This is really not the way computers think, and it really bugs me to read some code and not being able to predict what it does (like "mind compiling", etc.)

vid: I agree C++ has an unpredictable behavior, but C can be predicted if written well (and it has only one cast). For me, being an optimization-freak, C is the only HLL that is acceptable because it allows "some" low-level control, though of course not as asm. And C can be used to learn how compilers work too, since I pretty much compile all the code in C I see with my mind, and predict "most" behaviors.

p.s: Just imagine how crazy anti-traditional C (and more asm-oriented) I am because I use something like "ptr a, b" instead of "byte *a; byte *b;" to be fully sure how everything goes on internally. I declare ptr: "define ptr unsigned long int", and voila. Of course I change it if there's another architecture pointer size, but usually it's left as that Smile

With that said, C is not perfect, but can be clean if written correctly. Personally, C++ is waay to bloated in design, it has so many features. But maybe because this is coming from a guy that finds OOP illogical (and most probably I'm right, since computers do not think this way, and computers are pure logic).
Post 22 Jul 2006, 16:53
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
RedGhost wrote:
i don't recommend C++ for OS development


Unixlite was written in C++.

Quote:

Is c++ suitable for system programming?
We only use plain c++ functionality: member function, single inheritance, and virtual function. That's enough. We think there is no essential difference between c and c++ without using the following c++ features:

* exception handling
* multiple inheritence
* run time type identification
* operator overloading except new and delete
* template magic
Post 22 Jul 2006, 17:14
View user's profile Send private message Visit poster's website Reply with quote
Vortex



Joined: 17 Jun 2003
Posts: 318
Vortex
Right tool for the right job, that's the golden rule Smile

_________________
Code it... That's all...
Post 22 Jul 2006, 21:54
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
The_Grey_Beast: operating systems are object oriented by nature... at least anything remotely similar to unix or NT is. For instance, consider that read/write works on files, pipes, sockets, (and unix: arbitrary devices). That's polymorphism for you.

The ability to overload new/delete on a per-class basis is useful. Some objects have special alignment or memory-area requirements. Instead of calling a few different allocation and deallocation routines, you override new/delete on the special classes, and use don't have to do special-case shit in the client code.

Relying on objects for resource acquisition gets rid of multiple exitpoints or "jmp possibly_do_cleanup" because destructors are called automatically. This makes code safer and less error prone, and less tedious to write.


Quote:

I'm the kind of guy who really doesn't like OOP at all. First of all, it's always easier for me to think "exactly" in "computer terms" -- that is without nonsense (at least for me) like: Dog is inherited from animal, animal is inherited from creatures, from organisms, from sh**.

So, you don't like crappy-textbook OOP introduction, and never bothered to read better texts or think about the subject yourself - fair enough. Car and animal examples generally show that the author sucks.
Post 22 Jul 2006, 22:50
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
f0dder wrote:
The_Grey_Beast: operating systems are object oriented by nature... at least anything remotely similar to unix or NT is. For instance, consider that read/write works on files, pipes, sockets, (and unix: arbitrary devices). That's polymorphism for you.
But the CPU is not.. and the way you explained is how you think. Personally, I prefer to think from the CPU's side. But anyway, this is just a matter of opinion. I won't judge anyone for that. I didn't say OOP sucks, I just said that I don't like it. But that doesn't mean it sucks, for example for people like you. I understand that you find it easier, but I do not Wink
f0dder wrote:
The ability to overload new/delete on a per-class basis is useful. Some objects have special alignment or memory-area requirements. Instead of calling a few different allocation and deallocation routines, you override new/delete on the special classes, and use don't have to do special-case shit in the client code.
But that just "hides" it from you (i.e abstraction) -- you don't know that they are special, and thus unable to compile it yourself with the mind.

f0dder wrote:
Relying on objects for resource acquisition gets rid of multiple exitpoints or "jmp possibly_do_cleanup" because destructors are called automatically. This makes code safer and less error prone, and less tedious to write.
Yes, but that makes it almost impossible to "mind compile" the code, meaning to compile it with your mind, because it is abstracted from you. I like to mind compile my code so it doesn't wind up in errors (note: bugs might still arise from improper functionality). OOP has it's own prons and cons, of course. Though the majority of the people prefer it since it's how they "naturally" think.


f0dder wrote:
So, you don't like crappy-textbook OOP introduction, and never bothered to read better texts or think about the subject yourself - fair enough. Car and animal examples generally show that the author sucks.
Hey man, that was only the sh**iest example I wrote. Of course I know about, for example, the Serios Engine in Serious Sam (in fact, the SDK they give). It's OOP if you look at it, and of course it's not with dog. But, honestly, I can never TRULY understand what goes on internally (EXACTLY what goes on, I mean). Sure I understand that "monsters" and "enemies" are derived from "entities", etc etc.. but that doesn't help the CPU at all -- it's simply not the fault of the compiler in such cases, it's the fault of design (and I'm talking about efficiency). Of course there are some garbage virtuals there because once you begin to write OOP you usually forget how the computer works (guess what, you don't even need to know how virtual works). The overhead of the virtual table is useless there, and this is only the beginning. Much of the design could've been improved with little or much effort, depending on the changes. I meant that OOP is bad because it restricts you to think "naturally", when it simply blocks your other perspectives on the desgin. Sorry for that example, but I meant it as a joke Wink

Of course, I don't judge you as you have different preferences. I didn't mean to flame or offense you in any case, because I understand the others who are simply not like me. I only gave my opinion about OOP. Smile

_________________
Previously known as The_Grey_Beast
Post 22 Jul 2006, 23:00
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
I find that "thinking from the CPU's side" is a waste of time in most situations. It's the same as writing; I don't think in terms of sentences (or letters Razz), but in overall action and content. Sometimes a lot of thought can go into a few sentences or even which word to use, but most of the time I don't.

While most of my programming is still hobby based, I skipped programming just for the sake of the code a long time ago. I generally want to get a job done, without spending too much time on it, but still getting a good result. I want code that just plain works, without having to bother with trivialities all the time.

I generally don't care about the exact machine code that is generated from a piece of logic, as long as execution speed and code size is reasonable. It's much more important that the logic is correct and clear. The typical C style of trying some 3-5 resource allocations and doing partial cleanups (or "goto error") generally results in ugly code, whereas the object-based-acquisition is clear, short and lets you focus on the important details. "mind compiling" is IMHO irrelevant, as long as you understand the logic and have a general idea of the efficiency of what you're doing.

A lot of class hierarchies in C++ (and other languages) have been really shittily designed, so it's not wonder that people oppose it. Heck, often inheriting is a bad idea, and composition works out much better.

Quote:

Of course there are some garbage virtuals there because once you begin to write OOP you usually forget how the computer works (guess what, you don't even need to know how virtual works). The overhead of the virtual table is useless there, and this is only the beginning.

Ho humm. Show me a situation where an indirect call gives you measurable overhead, and I will show you a flawed design Smile - it's just like when people are trying to optimize PutPixel, instead of doing a better DrawBitmap design.

Besides, virtuals (or jumptables, if you wish) can be extremely useful. For instance, the file/pipe/socket example from before. It's more flexible and clearer to use a virtual instead of switching on a typecode. Having write_file, write_pipe, write_socket would be a poor option, since your code would be less generic, and in this example there's a lot more benefit from being generic than running a few cycles faster.
Post 22 Jul 2006, 23:27
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.