flat assembler
Message board for the users of flat assembler.

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

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Quote:
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.

Most of times when error occurs, and complicated cleanup is needed, this auto-destructor-calling isn't able to properly cleanup, because same destructor routine is called regardless of where did the error happen.

generally, i think OOP is useful for things that are object-oriented in their nature. But when i see "static object" i have to laugh. I used OOP in FASM myself without knowing something like that exists, and without thinking it needs special name.

But i was not talking about OOP, it is of course useful many times, and can be straightforwardly implemented in structured code, i was talking about clearness of C++.

Quote:
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.

I lack something about handling little / big endian. Also how much data from external source is he processing?
Post 24 Jul 2006, 07:14
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:
Quote:
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.

Most of times when error occurs, and complicated cleanup is needed, this auto-destructor-calling isn't able to properly cleanup, because same destructor routine is called regardless of where did the error happen.

The trick is to write good code Smile

Sure, there might be things it's not appropriate for, but memory (de)allocation, mutex/critsec/syncstuff, file close, etc. are things where it works really well, and helps you avoid leaks.

vid wrote:

But i was not talking about OOP, it is of course useful many times, and can be straightforwardly implemented in structured code, i was talking about clearness of C++.

The clearness has a lot to do with how skilled the programmer is. It's possible to write some very ugly-looking and hard-to-follow C++ code. OTOH it's also possible to write stuff that's almost self-documenting.

vid wrote:

Quote:
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.

I lack something about handling little / big endian. Also how much data from external source is he processing?


Data from external source = not fun when you deal with non-ascii data. Endian-ness is one issue, data alignment requirements are another. But it's doable; either write in/out operators for iostreams, or have class member functions to loadfrom/storeto FILE* objects... or your own file/stream abstractions.

Yes, C++ requires some work to make portable, especially if you aren't going to stick to lowest common denominator... and you have to work around vendor bugs. But show me a language that's more/easier portable AND achieves the same level of performance... Smile

_________________
Image - carpe noctem
Post 24 Jul 2006, 11:36
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
fodder: your arguments and opinions seem right Wink i just dislike that C++ is too much everything-oriented :], thus ALLOWING people to write ugly code, which most of times means they WILL write ugly code.

almost all people are too much idiots with using every possibility, learn someone polymorphism, and you can be sure he will use it in his next interactive hello world project. So i like languages that are so clear that they force people to write more "proper", even at cost of power. Something like @ff in FASM Wink
Post 24 Jul 2006, 12:15
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
Quote:

fodder: your arguments and opinions seem right Wink i just dislike that C++ is too much everything-oriented :], thus ALLOWING people to write ugly code, which most of times means they WILL write ugly code.

That is, unfortunately, right - too many people who shouldn't be using this language are in fact using it, creating some bad code and bloated applications. Not that it'd be much better if they used any other language, though Smile

C++ is a pretty good language because of it's power, and all the research that has gone into it, producing some pretty high-quality compilers. It takes a long time to master though (and I'm not claiming I'm there yet), and IMHO it's not until the 2000's before people have really learned taking advantage of it and write good code. Unfortunately that means a lot of bad legacy code.

I think C++ is better than C in all ways, anyway - even if you're just using it as a "glorified C compiler". And if you're going to use just a few C++ features, things like std::vector have very little overhead, but makes your code a lot safer than "raw" memory allocations.

I'm not really sure what I think of STL in general though; it can be a nightmare to debug, there's some problems if you want to distribute closed-source libraries, and not all implementations are good. It can speed up development though, and some implementations can provide very good code.

I probably wouldn't use STL for "really critical" stuff, but it's nifty enough for "common stuff". For instance, a book index program I whipped up for my museum, using a combo of MySQL and STL and win32 API, was easily able to handle ~100k items on a pmmx-200 box with 64 megs of ram, with decent performance. And it should be noted I'm one of those people that bitch if programs take more than ~750ms to load, including browsers ^_^
Post 24 Jul 2006, 12:28
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 Previous  1, 2

< 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.