It is currently Wed May 24, 2017 4:17 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 39 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Wed Mar 15, 2017 12:52 am 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 2954
Location: Nacogdoches, Texas
I've been very unproductive toward SNES programming recently (I don't even know the last time I programmed for it; I got stuck on something that I wasn't able to work on due to school, and I'm almost scared to make another attempt) and I thought I wanted to look at the M92 again for shits and giggles, but really, I know I'll just run into a brick wall due to poor documentation (I never even got the sprite DMA resolved). I really didn't want to hunt people down who know what the MAME code actually means again, which left me with nothing to do, but one thing I know I'll need to do at some point is create tools.

Because there's no way in hell I'll ever try to learn modern x86: https://en.wikipedia.org/wiki/X86_instruction_listings, partially because I know anything I'll try to make has a good chance of being less efficient, as I could ever keep track of that many instructions, along with the fact I don't even know if Microsoft made it feasible to interact with Windows in assembly by giving any documentation necessary or whatever, I decided to bite the bullet and try and learn a higher level programming language. However, I still wanted something clean and efficient that I could reason how it would be translated into machine language. C seemed to fit that better than anything else and has been around for seemingly forever, so I looked for Windows C related stuff, but I couldn't find anything; only Visual Studio C++. From any especially knowledgeable programmers, (you guys here, and a few other people I know) I have not heard a single good thing about C++ and have fallen under the impression whatever tweaks that were introduced by it ruined everything else.

Maybe I'm missing something, but shouldn't there be no difference between something between a program written in C vs. one written in C++ but with no C++ specific features? If true, wouldn't C have no advantage over C++ (and could be worse, even, maybe aside from a psychological factor)? What is bad about what C++ added too? Is it cluttered looking, or is it actually more inefficient? I can understand how something a little more high level could be more efficient by having hardwired solutions to complex problems that could only otherwise be taken step by step, but I don't know if that's happening here. Maybe I didn't search Google hard enough, but it didn't look like many others were asking the same questions, and if they did, got lame, ambiguous answers. :?


Last edited by Espozo on Wed Mar 15, 2017 7:27 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Wed Mar 15, 2017 1:25 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7035
Location: Jongny, VD, Switzerland
Wow, is your <RETURN> key broken or something ?

As for the debate, I think C vs C++ (and vs something else) is an endless debate, so it's no use agruing, there will always be people advocating one in favour of the other. It's something extremely though to estimate that language A is more efficient than language B, because in order to affirm so you'd need to code :
  • Something significantly large, so that you can know the difference of efficiency is not due to change
  • Code something from the ground up every time, without looking up the existing code in the other language, or else your coding style will be biased
  • Repeat the process a dozen of time to solve different problems, in order to be sure that language A is not just more efficient for a particular problem.

As you can see, it's no trivial task, and doing such a comparison would be a research domain in itself. As for myself, I belive that although C++ is a convenient language, it is a huge mess and has way too many features. Every time a feature existed in *any* language, they felt that they had to incorporate it in C++, which can be seen as a bonus or a major problem depending on what you're doing.


Top
 Profile  
 
PostPosted: Wed Mar 15, 2017 7:44 am 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 2954
Location: Nacogdoches, Texas
Bregalad wrote:
Wow, is your <RETURN> key broken or something ?

I don't have a <RETURN> key. I do, however, have an <ENTER> key. :lol: I just fixed it now; On my computer, it was only a couple of lines.

Bregalad wrote:
I belive that although C++ is a convenient language, it is a huge mess and has way too many features. Every time a feature existed in *any* language, they felt that they had to incorporate it in C++, which can be seen as a bonus or a major problem depending on what you're doing.

Yeah, I'm getting that a lot of the problem is for the programmer. I know how too much can be a problem, because if you're like me, you want to use everything available. This is why there's no way I could deal with the modern x86 instruction set; there are so many different instructions you could never be sure you are using them all, which would likely come at the cost of speed, and again is why I'm going to try C (because I probably can't beat any modern x86 compiler at that mess). I know I'm being irrational about the whole thing (efficiency really doesn't matter much at all here), but I don't care. :lol:


Top
 Profile  
 
PostPosted: Wed Mar 15, 2017 7:55 am 
Offline

Joined: Sun Mar 27, 2011 10:49 am
Posts: 139
C is, at least on some conceptual level, a fairly thin veneer (i.e. abstraction) over the average modern general-purpose CPU (by modern I basically mean anything with orthogonal registers and reasonably efficient stack addressing). It handles the hassles of register allocation and stack frame management, does some basic sanity checks to make sure you're not mixing up different types of data, and provides a nice notation for mathematical expressions and compound data access (arrays and structures) but beyond that isn't really doing anything to hide the machine from you.

Higher-level languages, by contrast, do a bunch of stuff to make code safer and to help you conceptually model things. C already does some of this: checking your types is an example of making things safer, and even the idea of a function in C is an abstraction over the jump and return and stack operation instructions used to implement it at the CPU level, in a way that helps you break up your program and think more about the logic of the algorithm you're implementing and less about the machine operations used to implement it. But there's lots of stuff C could do along these lines that it doesn't. For instance, C doesn't check your array access: if you index an array past the end of it, you'll just read whatever memory is past the end of the array, exactly as if you were programming in assembly (on modern computers this often does get caught by the CPU/OS though); in a higher-level language like Java, every time you access an array element, it checks to make sure that the index is in bounds, and if it doesn't it throws an exception - a way of modelling errors that abstracts over a bunch of stack manipulations at the assembly level that let you prematurely abort a computation.

C++ falls somewhere in the middle: it has a tons and tons of higher-level language features, but they're all optional - most C code can compile under a C++ compiler with few, if any, modifications. You can index an array, just like in C, and access undefined memory; or you can use a custom array class that'll do the Java-style checking. C++ has tons and tons of features that you can use to code at pretty much as high or low a level as you'd like: classes with encapsulation to hide implementation detail, multiple inheritance with virtual functions for ad-hoc polymorphism, function and operator overloading, templates for parametric polymorphism and Turing-complete compile-time code generation, exceptions for error handling, lambdas, implicit conversions, move and copy constructors, a fairly rich standard library with smart pointers and hash tables and more, and on and on and on.

While this sounds great - the more features the merrier! - in practice it can actually be a problem, because these features often interact in tricky, leaky ways. While abstractions are supposed to hide away details, with C++ you often need to remember all the details anyway to avoid mysterious bugs; and because your code looks simpler, it's easy to be lulled into a false sense of security, to think you know about everything that's going on when you don't.

That said, used judiciously, there's a ton of stuff in C++ that can be extremely helpful. In particular, life with the standard library of data structures is a hell of a lot nicer than without.


Top
 Profile  
 
PostPosted: Wed Mar 15, 2017 7:56 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 811
Location: Pennsylvania, USA
I'd pick C over C++ just because it is a lean language. It is easier to remember most features of the language. With C++, I always feel like I'm barely scratching the surface. I have no idea which is more efficient, but yeah, worrying about that is not productive most of the time, especially these days. I was able to write an "NES-like" emulator in Java. I started out worried about efficiency and put the cpu on a background thread. I later learned that actually caused worse performance than putting it on the render thread (on mobile devices, particularly Android). Worrying about efficiency up front is really not worthwhile, I think. Just pick languages that make you happy. If a giant clusterfuck of language features excites you, pick C++. Otherwise, pick C. ;)


Top
 Profile  
 
PostPosted: Wed Mar 15, 2017 8:19 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18344
Location: NE Indiana, USA (NTSC)
Espozo wrote:
shouldn't there be no difference between something between a program written in C vs. one written in C++ but with no C++ specific features?

A program written in the common subset of C and C++ should usually compile to the same machine code.*

Espozo wrote:
If true, wouldn't C have no advantage over C++ (and could be worse, even, maybe aside from a psychological factor)? What is bad about what C++ added too?

The <iostream> library is a pile of ass because it predated templates. Hello world with GNU libstdc++ on a Game Boy Advance took roughly 180,000 bytes last time I tried because it kept trying to initialize objects associated with date, time, and currency formatting despite that the program doesn't use any of those objects. This already uses a majority of the system's 262,144 bytes of bulk RAM.

C++ has no counterpart to C designated initializers.

For what it's worth, there exists an article on my wiki whose title is C++ vs. C. I'd summarize here, but I've already been ninja'd twice.

Bregalad wrote:
Wow, is your <RETURN> key broken or something ?

Found the Mac user.

Espozo wrote:
On my computer, it was only a couple of lines.

I normally resize my web browser to 960 to 1024 pixels wide. For one thing, reading text with lines that expand to fit the entire width of a monitor 1920 pixels wide or wider is difficult because the eye ends up skipping or repeating lines. Typographers tend to recommend lines no wider than 80 characters for body text. For another, one of my computers is a netbook with a 1024x600 pixel screen, and another has a 1920x1080 pixel screen into which I "snap" two windows to half the width.


* So long as it doesn't depend on those few semantic differences between C and C++ that C++ language lawyers like to regurgitate to prove their e-penis.


Top
 Profile  
 
PostPosted: Wed Mar 15, 2017 8:23 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7035
Location: Jongny, VD, Switzerland
Espozo (several times) wrote:
modern x86 instruction set;

The x86 instruction set is anything but modern. Back when it was invented Intel thought it was cool that their processors could do with one instruction something other processors can do in several. The problem is that if you're not coding in assembly this is completely pointless - and even if you're coding in assembly it makes remembering useful instructions harder (as you apparently already figured out).

Quote:
What is bad about what C++ added too?

By itself, nothing, exept that standard libraries will be bloated and make a "hello world" program several hundreds of kilobytes already (something which is fully reasonable today, but not if you want to develop for small systems).

Quote:
Yeah, I'm getting that a lot of the problem is for the programmer. I know how too much can be a problem, because if you're like me, you want to use everything available.

Then you'd want to either change your philosophy, devote your life to C++ or abandon C++ completely. C++ is the most feature-creeped language ever made, so if you want to use everything available even once you'll have to go through a dozen of huge 500 page books, each one dedicated so some obscure features of C++.
Quote:
This is why there's no way I could deal with the modern (sic) x86 instruction set; there are so many different instructions you could never be sure you are using them all

It's much less complex than C++ by far. Even in 6502 assembly, the eor (ZP,X) instruction is very unlikely to be used.


Top
 Profile  
 
PostPosted: Wed Mar 15, 2017 8:39 am 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 141
I wouldn't ever use C when C++ is available. You just have to pick and choose the right language features to use.

As a starting point, use these from C++:

  • std::unique_ptr
  • std::vector
  • std::array
  • std::sort

And avoid using these:

  • inheritance
  • iostreams

The first four happen to be zero overhead (or close to it), so you should not worry about performance with them.


Top
 Profile  
 
PostPosted: Wed Mar 15, 2017 9:07 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5178
Location: Canada
I feel like a lot of discussion on this topic was set off by Linus Torvalds about 13 years when he wrote some famous screed about why the Linux kernel was C, and his main reason seemed to be that he thinks programmers that can write C++ but are unwilling to conform to plain C are shitty programmers, so a personnel filter based on his opinion of the existing pool of talent. (A selection bias, since more people know C++, but people who use dedicated C often are more specialized?) Even that reason is kinda dumb to me, but the rest of his reasoning is a bit dubious/outdated too, IMO, but based on some bad experiences he'd has a long time ago.

For a more useful and a bit more recent opinion on the subject, I'd actually recommend some of the lectures given by Mike Acton, who is a very high-performance oriented programmer working in games for a long time, and he used to advocate working in mostly assembly well into the PS3 era. Well, guess what, he now uses C++ primarily and has given some great talks on how to write high performance C++ code. He's not ideological about any of it, he tries things and analyzes the problem and goes with what works, and currently he thinks C++ is the most practical thing to use for games. (And I'm sure he'd use something different if he thought it was better.)

If you're wondering why we don't have a C++ compiler for NES (yet), it has nothing to do with efficiency, just complexity. It's hard to write a C++ compiler. It's a lot easier to write a C compiler; it's a tiny language by comparison. CC65 being a hobbyist and unpaid work keeps its goals small enough to achieve.

Espozo wrote:
I looked for Windows C related stuff, but I couldn't find anything; only Visual Studio C++.

Most (or maybe all) C++ compiler toolchains include a C compiler somewhere. In the case of Visual Studio, it will compile .cpp or .cc files with its C++ compiler, and .c files with its C compiler. There a bunch of other compiler sets you can use for Windows if you like (clang/LLVM, MinGW, etc.) and they all can do C as well.

Espozo wrote:
Maybe I'm missing something, but shouldn't there be no difference between something between a program written in C vs. one written in C++ but with no C++ specific features?

Yes, this is mostly true. Some would like to argue that you're not actually writing C++ if you're doing that, but I think this is not a useful hair to split. Not all C++ features are bad or inefficient or evil or whatever. You can create problems for yourself in any language, and C++'s complexity gives you quite a lot of rope to hang yourself with, but it's a perfectly good language for high performance and/or maintainable code. If you want to take the time to learn how to use it efficiently, there's tons of features of C++ that can be used well that are completely alien to C.

Espozo wrote:
I have not heard a single good thing about C++ and have fallen under the impression whatever tweaks that were introduced by it ruined everything else.

I'm under the impression that it's one of the most widely used and practical languages, especially for high performance work like game programming. There are endless things to complain about, but I think it's perfectly fine to use for a lot of applications, and tons of software comes out every day proving this.

Also, you're asking on a forum oriented towards writing in assembly for 35 year old hardware, so there's probably a strong bias here... not that a bias is bad, you should probably try to gather knowledge specific to the domain you want to work in.

FWIW I think C is a pretty good language too, but honestly if the choice was up to me at this point I think I'd only use it over C++ because C++ was unavailable (like on the NES), or because it was continuing a project that was already started in C. In professional situations it's usually a moot argument anyway, because the choice of language is forced on you. If it's for a personal project, you should use the language you think would be best for that project's goals. If the goal of the project is learning, it can be very worth picking a language you're unfamiliar with.

If you're asking which ones to learn, I'd say learn both. (I actually learned C++ before C, but this was largely due to what books I had easy access to before the internet existed. Most of the examples I learned from were old examples written in C, though, so once I learned C I wrote only in it for a few years, even though I could have used C++.) Most of what you'll learn about C applies to C++ as well. Less so vice-versa.


Top
 Profile  
 
PostPosted: Wed Mar 15, 2017 9:24 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7035
Location: Jongny, VD, Switzerland
rainwarrior wrote:
I feel like a lot of discussion on this topic was set off by Linus Torvalds about 13 years when he wrote some famous screed about why the Linux kernel was C, and his main reason seemed to be that he thinks programmers that can write C++ but are unwilling to conform to plain C are shitty programmers, so a personnel filter based on his opinion of the existing pool of talent. (A selection bias, since more people know C++, but people who use dedicated C often are more specialized?) Even that reason is kinda dumb to me, but the rest of his reasoning is a bit dubious/outdated too, IMO, but based on some bad experiences he'd has a long time ago.

I don't think this guy's opinion should be taken in account at all. He just profit of his person/status and behaves like a jerk, insulting every one on forums and being mediatized for doing so. If he'd be anyone else, he'd just be banned, but since he's Linus Torvalds, we can now have news like "Linus Torvalds called XXX a fucking supid thing".

Quote:
Well, guess what, he now uses C++ primarily

That by itself doesn't mean much. The question is : "Which of the billion of C++ features does he use primarly ?"
Quote:
If you're wondering why we don't have a C++ compiler for NES (yet), it has nothing to do with efficiency, just complexity. It's hard to write a C++ compiler. It's a lot easier to write a C compiler; it's a tiny language by comparison. CC65 being a hobbyist and unpaid work keeps its goals small enough to achieve.

I'm pretty sure C++ to C converters exists, so technically you could try to fit CC65 with the output of one of those... although personally I think it sounds like a terrible idea.

Quote:
FWIW I think C is a pretty good language too

Stuents and professors in the computer science section where I studied/work are almost unanimous that both C and C++ are awful. C because of it's complicated and extremely inconsistent syntax, and C++ because it inherited the major flaws of C, is feature creeped and even worse when it comes to syntax consistence. However, if you are ready to write ugly code anyway I don't think you'd care.


Top
 Profile  
 
PostPosted: Wed Mar 15, 2017 9:44 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5178
Location: Canada
Bregalad wrote:
rainwarrior wrote:
(Mike Acton) now uses C++ primarily

That by itself doesn't mean much. The question is : "Which of the billion of C++ features does he use primarly ?"

The lecture I linked should give an idea of that. It's a lengthy answer, but it's not a simple question either. (The lecture isn't specifically about C++ features, though, really more about compilers and effective data structures, so it might not answer your question directly, a lot of the examples are using various C++ features but he's not trying to demonstrate those features themselves.)

My main point mentioning Mike Acton wasn't that some die-hard assembly holdout finally "converted", it was to link that talk where he gives some really good information about effective/practical code design in a C++ context.

Bregalad wrote:
I'm pretty sure C++ to C converters exists, so technically you could try to fit CC65 with the output of one of those... although personally I think it sounds like a terrible idea.

Yes, I intentionally omitted that possibility.

Bregalad wrote:
...if you are ready to write ugly code anyway I don't think you'd care.

I think all code is ugly. ;P (Except maybe gandalf.c.)


Last edited by rainwarrior on Wed Mar 15, 2017 12:58 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Wed Mar 15, 2017 9:52 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3844
C++ itself is tiny and with very little overhead compared to C. Using C++ properly shouldn't add more than a couple kilobytes to the size of an executable.
The only thing that makes that different is when the runtime or libraries suck.
So if you're getting 1MB executables for an otherwise 4k-size program, look at the stuff that got imported in there. Usual culprits are exception handling code, global variable constructor/destructor code, RTTI, and the incredibly bloated IOStream library.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Wed Mar 15, 2017 10:08 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3844
Espozo wrote:
Because there's no way in hell I'll ever try to learn modern x86: https://en.wikipedia.org/wiki/X86_instruction_listings, partially because I know anything I'll try to make has a good chance of being less efficient, as I could ever keep track of that many instructions, along with the fact I don't even know if Microsoft made it feasible to interact with Windows in assembly by giving any documentation necessary or whatever

Yes, you can still write programs in X86 assembly. Not really all that useful though, it's more useful for hacking existing programs.
You need to output a valid PE (Portable Executable) EXE file, which includes defining a IMPORT section that includes all the functions from Windows that you want to import.
You can call Win32 API functions, as long as you obey the stdcall calling convention. If you prefer C standard library functions, you can also call functions from msvcrt, those usually use the cdecl calling convention instead.
It's even theoretically possible to have a program that doesn't import anything. Windows always loads Kernel32.DLL into memory whether the program imports it or not, and it's possible to find out the address of the DLL file, then look through RAM to find imported functions. This can be used to find GetProcAddress and LoadLibraryA even if they aren't explicitly imported, and those two functions are the first step to hacking your own code into another program.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Wed Mar 15, 2017 11:05 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5178
Location: Canada
Dwedit wrote:
C++ itself is tiny and with very little overhead compared to C.

I think a lot of 4k PC demos are written in C++. (I wrote one myself, a few years ago.) There's lots of ways to keep the executable size down if that's your goal, but most compilers are not set up by default to optimize for size like that. They shouldn't, either, because it trades off for convenience (or other factors) and most applications aren't going to care about an extra 100k of overhead in their executable. It's not so much "bloat" as something that literally doesn't matter to most people, and often has a tangible benefit.

Dwedit's example about DLLs is very relevant (or "shared libraries" in Linux, etc.) because they already provide a solution for the "big fish" of code reuse. The CRT overhead is relatively small compared to the problem already being solved by DLLs, but MSVC does in fact put most of its CRT in a DLL by default. If you want it statically linked, though, there's an option for that. (I actually prefer to statically link the CRT, even though it increases file size, to keep people from having to find and install those MSVCRT DLLs which Windows should just come with, but doesn't.)


Just as a quick test, MSVC 2013 Express, compiling a windows console application with the default release settings. I wrote a "hello world" as a C program (using printf), and a C++ program (using std::cout). The printf version was 6656 bytes (whether compiled as C or C++ it made no difference in size), and the std::cout version (C++ only) was 11776 bytes. Is either of these really a problem?

(I don't really like std::cout or iostream in general, but it's not even a language feature of C++ anyway, merely a library feature. Only using it here because otherwise there wasn't even a difference in the compiled code.)


Top
 Profile  
 
PostPosted: Wed Mar 15, 2017 12:18 pm 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 141
An innate problem with C++ programmers (especially myself) is that they love to add complexity to everything. Rather than simplifying the problem, they choose instead to complicate the code, and end up writing 300% as much code to gain 10% more features.

For example, see this "enum.hpp" file I wrote three or four years ago. I think the original intent of this file was to allow enums to be used as ranges and flags, but wow, is such a simple idea complicated. In C, you'd just use for-loops and casts and the thought of writing such filth would never even enter your mind.

The FORTH manifesto:
Quote:
Don't Complexify

Simplify the problem you've got or rather don't complexify it. I've done it myself, it's fun to do. You have a boring problem and hiding behind it is a much more interesting problem. So you code the more interesting problem and the one you've got is a subset of it and it falls out trivial. But of course you wrote ten times as much code as you needed to solve the problem that you actually had.

Ten times code means ten times cost; the cost of writing it, the cost of documenting it, it the cost of storing it in memory, the cost of storing it on disk, the cost of compiling it, the cost of loading it, everything you do will be ten times as expensive as it needed to be. Actually worse than that because complexity increases exponentially.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 39 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Garth and 2 guests


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 post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group