Ok maybe my post came off a little aggressive.

But I'm not saying everything should be wrapped in objects and use every C++ feature, that's just silly. What I am saying is that C++ does have some nice features that could be useful, and it is still (more or less) C compatible if you prefer C coding.

I'm not challenging C here. I have used C, but when an almost identicle language exist which has way more features, doesn't it make you feel C is lacking? There's one project in particular that I'm working on in C, but if I felt for one second that I could benefit from using C++ I would change over.

Having a new library wrap C++ functionality over a library that is exposed as C but uses C++ internally. Does anyone other than me feel this is a little redundant? A long time ago (I think during the 3.x code) I was looking at how allegro worked, and I couldn't help but think how much it would benefit from using C++. It just seemed there was a lot of stuff that would be much simpler to write in C++. And even now (in this thread) there are issues being discussed that could easily be solved by enbracing C++, yet we turn back to an older language. Why? It seems to me we embrace C out of convention more than anything else.

I dont think ive used this little rant before, and one of these arguments hasnt come up for a while so here goes..

C++ is not more powerful than C anymore than C is not more powerful than assembler. Power is defined as the limit of your capability. Perl is more powerful than sh. C is more powerful than perl. C++ is more convienent than C for some things much like C is more convienent than assembler.

I use C for small projects, but C++ for anything of mild size or larger. I understand that alot of you like C, but for the same reason you program in C as opposed to assembler( other than the fact that you dont know assembler very well ), why cant you use the same reason to use C++ over C?

To tell you the truth, C++'s extra strict type checking pisses me off.

To start, it was compatibility, for allegro 5? Useability. Not everyone uses C++, or even knows C++.

From my perspective, if addon's can access the C++ internals, why couldn't a C++ api layer? same diff no? In fact, theres no saying that a fancy Alleg++ header couldn't pretty up the internal API and forward it allong (no doubt the internals won't be suited for direct use by most people... so some form of API on top will be needed.)

That's exactly what I wanted to say, but I couldn't have put it so successfully. I was actually thinking of this a lot while I was at work today.

So if the library is C++ internal and exposed as C, rather than have someone wrap the api in C++ (like I said, it's highly redundant) why not expose the library as C++ and create a standard C wrapper. It seems to me this is what is being done already, but without explicity exposing the C++ code. Perhaps it would work somewhat like DirectX (COM) does in C. Would this appeal to both languages?

Maybe this similar to what Thomas was getting at.

And if I havent' made this point already: sorry if offended vanilla C fans.

I really don't care what language or prefix anything is in as long as allegro doesn't go to that crazy UpperLowerCase crap!! I hate that about windows API. I pretty much learned most of my programming alongside of Allegro, so I have been brainwashed with the under_score_style!!

Incorrect. Did you even read the original document that this thread was based of off?

AFunctionLikeThisIsActuallyHarderToRead();

Which was one of the main points of the document.

Maybe my skill as a programer? Not totally sure, It just takes me WAY to long to design and code a C++ OO api. And when I do get something, I usually find its not flexible enough... So its all me. me and C++ don't play well with eachother.

Funny.. Thats how I code in C for the most part.

I put things in a box if needed... In my VM, the baisc "value" thing that holds variables, objects, etc is its own "box", that is a "value_t" with the appropriate api for accessing its value. The VM has its own "vm_t".. The language lexing/parsing stuff is a bit more involved..

The Assembler for the VM is layed out similar to:

buffer_t->lex_t->script_t

then after that, if you wan't to run the assembled code in the vm, you can either just give it to the vm_t or run it through the optimization function (which will likely make use of the buffer_t thing...), then give it to the vm_t.

Note though, thats not completely accurate... I've been reworking the VM, so the lex_t, buffer_t, value_t and vm_t is all new... it used to be for the parser, just regular C io, and the vm: class_t, prop_t, script_t, runner_t...

If you wonder about the layers in the parse code.. That lex_t api is flexible enough to allow switching rules in the middle of parsing.. so say I write a C/C++ like language for it, I can implement a asm() like instruction just by adding a new rule, and have that rule hand off the lexing to the lex_state_t for the current assembler

edit1: Programs are like Onions. Onions have layers. Or are Programs like Ca3k?

edit2: The prefix is not "al", its "al_" and "AL_".

Ok "document" pardon my error, but you don't have to be smug about it. And regardless of what the document was about this thread still implied nothing about underscore vs. camel notation.

Thomas, sounds like you got some cool stuff. Very object oriented for not being written in an OO language. Whatever works. I use Lua for my VM. Very cool language. What's Ca3k?

It does what I need Keeps the code in neat little testable parcels

Never much liked lua.. Can't remember why...

Um... Its like a Parfait.. Everyone loves a Parfait!

j/k. Sorry. too many cartoons

What I mean to say, a program has layers (in my book). You build it up from various bits of code till you get to the top.. Or I do

My VM and the language parser for it all start at libc, then build on it.. the parser starts with the buffer_t layer that holds buffers of stuff to lex, then the lex_t layer lexes the buffers, (adding and/or removing them as it goes) then in the actual parser, it starts building language structures... (I haven't got to the higher level languages yet, so far the assembler just builds a binary opcode stream ) The VM builds from the vm_t which deals with types.. int, string, double and value_t's (which can be hold int, string, double, reference to value_t, or it can be a higher level 'thing', like a "class/object", or just a way to add another base type to the VM.)

So really, it looks OO, it kinda is, But I view it all in layers. Where each next layer builds on the layer before.

p.s. Ca3k bythe way is Cake.

That's not really a good reason to WriteInMixedCaps. Better to not do that to begin with if you don't want to use it.
Besides, it won't work very well for global variables. (Yes, I know... it could be argued that a well-designed API has no or at least as few as possible global variables).

You can use a #define to make an alias for the variable name, but that isn't pretty and it could potentially cause problems as well.

Now, all I was saying that the argument that you can make a wrapper anyway renders any discussion on the naming scheme irrelevant is false and some thought should go into it.

Please refrain from posting offensive remarks and resort to name calling, ok? It just makes it look like you are unable to carry on a decent conversation.