pouët.net

+"to know"

That is all good and dandy, but all those 1970s idiosyncrasies and the sheer uglyness of it all is barely defendable today.

@kb_: how do you see C++ as functional?

tomaes: But in many cases the only real alternative is C. And that's even uglier.

Lord Graga: True, C++ doesn't offer much in terms of the functional paradigm, but it also doesn't try to keep you from doing it yourself. Some rather unknown person has written about it better than I could here, worth a read.

(And srsly, the moment when you realize that some things _do_ have state is the moment Haskell et al. completely fall apart and get waaay uglier than faking FP in C++ ever could ;)

I consider C to be more concise than c++, and thus less ugly. I consider C++ to be a hack to add some kind of pseudo object orientation to C.

@skomp Let's do some linear algebra in C and C++
C=> Matrix_scaledAdd(alpha, Matrix_dot(M, u, v));
C++ => v = alpha * M.dot(u)

Concise ? Ugly ? Your move :D

Well yeah, C++ is all about op overloading and making the most of statements. That part is very powerful and actually sort of not-terrible (and if you need it or think you need it a real advantage over the likes of Java and ECMAScript dialects). ;)

In Wolfenstrad CPC demo, since I started crossdeving in C I had this idea. Apart from the original C project with SDCC, add a second build target in codeblocks which compiles natively on PC with SDL simulating the single graphic mode and other necessary things I was working this demo on. I had also to simulate things like memory switching, video screen switching, pallete emulation, getting a pointer that either shows to the CPC memory provided or an array of CPC memory, depending on code definition of whether it's the CPC binary or PC executable. While, I was arguing to myself "Are you sure? This is gonna take all my time!" I at least only did the bare minimum, screen simulation for only Mode 0 CPC screen with 64byte width and 200 lines high, then added additional functionailities when I was on the extra 64k and decided to use double buffering on the CPC side. I didn't simulate the whole CRTC and also never wrote a z80 emulator for the critical assembly parts. I simply had #ifdef PROJECT_CPC some assembly code SDCC will compile, #elseif PC code that does practically the same thing so that I can see it in the simulator. It was very convenient, testing and debugging things directly on my PC, scripting the demo and just one key and see it, instead of always doing the most tedious work of compiling, transfering the binary to dsk (even if automated), opening the emulator, running it. It's funny, I run wolfenstrad on a PC sdl screen (without borders, music and the logo I put in the very last time though), make changes and see them directly, and only in the single case when I want to to test it on CPC, I compile once for SDCC target. I will use and evolve this framework slowly along the needs of my next projects.

I did the same thing with my GP32 demo years ago. A project that simulated the basic graphic functions I was using in the GP32 SDK, same function names and arguments but with SDL code showing how the result would be on a real GP32. I did this for both 8bit paletized and 16bit modes. It's not like building an entire framework, it's just simulating the very essential parts you are using so that development is accelerated, since you don't need to after every compile to transfer and test to the real GP32 (I know though there is another way to develop and test directly on switched on GP32 with some kind of cable, but I don't have it).

As for the rest of my projects I am totally disorganized, most of the times I scrap a new SDL or OpenGL project with nothing just a blank screen and start from there. Not even having a standard set of libraries ready, but where I need a vector class I wonder which was the last project I had used one for and rip it :)

@kb_: not true!
Thats what Haskell has monads for.

@marmakoide
maybe it feels more natural due to the usage of operators. still that's one thing oprator overloading hides: a function is called for that in the bg. i use it in my own languages as well. but for c++ i never know what's actually going on and thus prefer to stick to function calls and some strange pointer constructs, abusing the memory layout.

quasimodo: yeah, monads. Most comprehensive concept EVER. Interesting how the only way to get it under control was introducing a syntax that lets them look like simple procedural programming.

kb_: yeah, so what?
Its a way to handle state, so why should it look different than procedural code?
Thats just syntactic sugar above well typed (and in most cases pure) functional behavior.

This is a common gripe with C++, but it's not actually a criticism of C++. If you understand the added features of C++ such as operator overloading, exceptions or templates, they're not mystical or random at all. They're just tools that may or may not help you write the code you're trying to wriite.

In this thread there hasn't been any criticism of C++ beyond "I don't like it" anyway (kinda exactly like my "criticism" of Haskell, but yeah, animals can't recognize themselves in mirrors and such. I should stop doing that).

A friend of me compared C++ with a martial art. If you are a master, you are practically invincable. But it takes you many years to become good at it, and if you want to master it, you have to devote your life to it.

I just didnt have that patience :)

Being critical of a language that insists on a functional paradigm is still a lot more valid than dismissing C++ because of all the optional features it provides over C. I've heard it often enough that "sure, this feature of C++ is useful, but overall I don't like how C++ does all kinds of stuff in the background." Which of course is just wrong. It's an explicit, low-level language and it does nothing in the background that you don't ask it to. If you like only one of its features, then treat C++ as if it were C with just that one extra feature that you like. Perfect, right? (Well, at least in a demo coding context where projects don't comprise contributions from dozens of coders, each with his own opinion on what's awesome about C++.)

You might be wrong to criticise Haskell, but that depends on the merits of functional/stateless programming and all that, which is all debatable. It's not debatable that C++ is still a low-level language which does exactly what C does, except with lots of added possibilities for automation, abstraction and syntactic sugar.

♻: Again, this isn't a rant against C++ per se, just against exceptions and constructors. The argument presented here is "I don't want a language that presents me features that I don't need". Kinda valid but highly subjective and nothing that a stringent code style guide can't fix. To reiterate my swiss army knife metaphor: If you want to use the screwdriver and decide to flip out the knife too, it's your own goddamn fault. :)

(and btw, exit functions that can fail? HELLO? These things are supposed to clean up after all work has been done, they simply must not fail. Again, code style).

♻: That article is full of fail, though. ;)

Also, what Doom said. If you write C-style code in C++ it's perfectly valid and in the end more often than not faster because of the stricter type system and the resulting optimizations opportunities. Just ignore the zealots screaming that you haven't been employing The One True School Of Writing C++ Code which is a different thing for everyone.

Haha, there we go. :) A nice little gem in the comments. From the OP, no less.

C++ => let's try to be 100% backward compatible with C, to add an object model to the language, templates while we are at it, and zero cost for stuffs the coder won't use (thus, minimal runtime).

With all those objectives in mind, well, C++ works quite well. Actually it's close to optimal in that regard, I believe so. Maybe it's me lacking imagination. The price for this is complex syntax (write a parser for C++ and feel the pain...) and very complex behavior for the compiler.

Others attempt to enrich C with an object model... Objective C. Butt-ugly syntax and significant runtime behind the scene. Probably ok for many usages, maybe not for super-edgy-1337-demo code.

I just found it interesting from someone who was a true C++ believer and finally decided to ditch his project and rewrite in C

that's about it. no strong opinion apart from: here at work our core tech is in C and well I realize most coworkers doing C++ don't understand half of what they're doing

of course classes are nice, so we have our own "objective-c", full of ugly macros, with no compiler help on the syntactic side. that's verbose and error prone and tedious but makes our tech work on every platform from micro controllers to powerful desktops

again no strong opinion, no evangelism from my part, just saying what works for us

bump