I was reading through the discussion of the api-style (draft two) for Allegro 5. And if I'm correct, Allegro 5 will be prefix functions with al_, Al_ or Al. I personally prefere the first, but that's beyond the scope of this thread.

The problem I see with this, is that OpenAL already does this. Exactly. So this could create some confusion couldn't it?

OpenAL prefixes functions with "al" and constants with AL_. What happens if Allegro does the same and someone uses both libraries together? (Which is not as far-fetched as you would think.)

What's your thoughts on this?

namespaces

It's pointed out in the article that Allegro 5 will have no C++ (unless I missed something) and will therefor have no namespaces.

[edit]

Took me a sec to find it again (it's quite big).

That's a pretty old file, have you been reading the alleg5 list? From what I recall there was a push to more c++ in version 5.

As for namespaces, I was joking. Obviously.

Marcello

There will only be a problem if OpenAL and Allegro have an identically named identifier. No problems otherwise.

Oh, and one of the UWIP's (Uber Work In Progress) for Allegro 5 uses C++ in the core for the driver system. but exposes a C and C++ compatable API to the user.

The Alleg5 mailing list? I forgot about that. I'm talking about the documents in the "Allegro's future proposals" section.

Most aren't that old.

[edit] 1 post hit while I was writing.

TF: I'm mostly talking about readability (which the document was about).

The C++ thing is for internals only. The Allegro API will remain C only.

Yes, we do know prefixes still have issues: OpenAL uses the same ones, and so do several other libraries. It's not something we can really avoid - there simply is no way to isolate expoerted C code.

(edit: s/OpenGL/OpenAL/)

"C only" <-- Really? The C++ won't be exposed at all?

all my wisdom tells me C++ internal and C extern is a REALISTIC WORKABLE SOLUTION.

those 3 words are VERY important.

as for AL_ i suggest alg_ much better chance of it avoiding name conflicts.

Wouldn't "all_" work?

Just to be sure, it should be allegro_game_programming_library_. No confusion could possibly arise from such a prefix.

OpenAL and Allegro may both use the "al" prefix, but the function naming conventions beyond that are different (mixed caps vs. underscore mania). I wouldn't sweat it ...

Bob! Let's just port Allegro to C# and only support C# that way, EVERYONE is happy! Namespaces! Circular dependances! It's heaven!

Back to sanity:

I don't think it'll matter much either 23, but to be sure, I thought I'd ask here, just incase is hasn't been thought about.

I've been thinking about this... wouldn't it be possible to encapsulate the contents of allegro.h in something like

namespace allegro {

extern "C" {

// stuff

}

}

depending on __cplusplus being defined and some preprocessor flag to indicate we Allegro wrapped up in a namespace (making it the default will break older code)? Alternatively, one could make a seperate header file that does this.

If it works at all (and due to the way Allegro mangles some things through #defines and inline functions, I'm not at all sure that it would) this would solve the namespace issue only for C++, not for C, but it has the advantage that it could be done now and quickly. And some solution is probably better than none.

I still don't understand the aversion to C++ to begin with. Clearly people who use C ONLY won't be able to use C++ code. But who is so hardcore C that they don't use C++? Is there really anyone out there who refuses to use C++? (which has been standardized as of 2 years ago) If these strange and illusive people are out there maybe someone should slap them back to reality.

Well, C is "faster" then C++. Which is actually true, but the fact that John Carmack has given C up for Doom 3 should say something about the overhead being not a real issue.

I think nowadays, it's just a preferance issue, except on embedded systems (not consoles, actual embedded systems).

Though I wish I could get some of those circular dependances (a C# feature) in C++...

[edit] Was that directed at me, Matt?

I prefer to use C over C++ for any project that I'm going to be doing solo. If I wanted C++ Allegro, I could create a wrapper of sorts around any features that I really cared to have as OOP.

You are shallow minded if you think C++ is always better than C. There's more out there than just high-end PCs, and there's more than just large scale projects that benefit from OOP.

I've said it many times. but its not a "hardcore" thing. I prefer C, as I over engineer when coding in C++, designing an API takes me way too long in C++, so I do C, and C works perfectly fine. I don't need any of the C++ features. (some of them even slow me down...)

Can I slap you? Please? No really. Don't assume things about people, it tends not to be too accurate.

Question:
The, a C++ compiler will be required to compile Allegro, even if I only want to use it for C coding (and thus, I don't have the C++ stuff) ?

I mean, for example, If I only have installed GCC, but not GPP, it will still be possible to compile Allegro?

Nope, you will require a C++ compiler.

Btw, none of this is set in stone. We're just experimenting with some things. For example, my version of the code only uses C, and implements Java-style dynamic binding. Peter's C++ version requires that add-ons and user code be compiled with a common ABI to share Allegro internals.

I hardly use C++ at all. The only reason I'm writing C++ code at the moment is because I had a good use for object inheritance and constructor/destructor functions.
I still prefer to use C or C-like constructions for a lot of things though.

It being standardized is not an issue. FORTRAN has been standardized over twenty-five years ago, and I don't actively use that either.

I think we should leave the c coders alone.
IMO allegro works fine without any c++ interface.

I think it would be stupid to make separate versions to please both sides.

Matthew: Don't forget that OOP is available in c too, struct, DIALOG object...
It's just that in c you need more guns to blow your leg off.

anyway, what can C++ do that C cant ?

In a sense, nothing, in another sense, a lot.

C and C++ both compile to machine code, so either language can do what the other does from the machine's point of view. C++, however, offers functionality to the programmer that C does not: operator overloading, namespaces, polymorphism.

C++ is offering some higher level coding, what you use depends on what suits you best.
Some people don't understand some of this stuff, and others just don't like the way it's done.

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 don't mind if someone invests his time in making a c++ something for allegro, just don't mess the original up for those who like the classic allegro style, like me.

I am a c++ coder, but like how the way allegro is used. Though if you can make something that is much easier to use...

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?

Well, once again, you guys and your bickering seem to have offically derailed the original thread.

10 points!

...

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

A J: Not to forget templates, which are not only ultra-safe C++ equivalents of using void*s, but you can also overload them to do specific things with different types.

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 don't like C++ And C++ doesn't like me. And I'm fine with that.

Not quite. More like, the C API is just going to be an interface to the internals which "may" use classes for the driver system. The internal code will likely not be anywhere near as simple as the external API... If Allegro5 does go the way of C++ internals, theres nothing stopping anyone from writing a C++ interface to the internals. And I for one, see no reason as to why it wouldn't be included in allegro IF it was clean and simple enough. But then, I'm not really a developer

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

Would you mind me asking what the big issue is? Just curious.

You have a lot of anger for something that doesn't matter that much.

And one more point I was thinking about during work... Every cross-platform windowing api in existence (Glut, SDL, Cpw, Glfw, etc..) is written for C only (asside from wrappers) it would be nice to see an alternative.

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.

I'm not angry, I just don't want Allegro's API to use that MixedCase stuff! Every time I see code like that, it makes me very upset!

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.

I had a similar problem when first started learning C++. My first mistake was to put everything in objects, and try to form complex heirarchies of inheritance.

"I can have an object for everything, make it totally modular, and not have to worry about how they communicate". Man was that ever a waste of time. But we learn from our mistakes I guess, and I wasn't about to claim defeat. I'm now quite fluent with C++ and I'm glad I stuck with it.

Actually you said the "al" prefix had a confict with other libraries, and you said you were reading the other thread when you thought of it not that this was based on it (and I have read that other thread). And that function is hard to read because it's way too long. There's nothing wrong with camel notation.

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

I find that style of design way too limiting. In C++ that design starts locking you away from your own code. Everything get's black-boxed (a term I hear a lot from other programmers).

I changed my approach to software design because of that. Eventually I learned that there was much more to C++ than classes. In fact I avoid using classes in C++ unless their necessary. I have a friend doing programming at University right now, who is making the common newb mistake of abstracting everything in objects. He won't take my own failure experiences as warnings either.

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

What other thread? Unless your talking about the document, which I'd like to quote:

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?

When your goal is to make a program that has objects, it's best to use a language that helps you organise the objects.
C works perfectly well with objects and C++ has just added some higher level helpers.
Why do I always get the feeling that very few understands what OOP really is about?

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.

if you dont like this sort of thing:
AFunctionLikeThisIsActuallyHarderToRead();

then just write a set of wrappers
a_function_like_this_is_actaully_harder_to_read();

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

write a wrapper for your global vars too.
there is absolutely no reason to argue about the name of anything, you can write wrappers, use MACROs etc. typedef etc..

so stop whinging about naming... your arguments just go to show how little you know about C/C++.

lamers!

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.

I know I'm late, but I want to give my opinion about that C Vs. C++ in Allegro's API.

I don't want to boast myself but I must say that I have a lot of years of experience coding applications and I can code both C and C++, as well than other languages. So, I know about that.

You must know that: each programming language was designed to resolve a single problem. Some examples: FORTRAN was designed to resolve mathematics problems, COBOL to build business applications, BASIC was designed for educational purposes, LOGO for sightly different educational purposes, SCUMM to write adventure games, etc.

C was designed to write operating systems (more specifically, it was designed to write THE operating system named UNIX-I). So C is one of the best languages to code low-level operations.

C++ was designed to make the Object Oriented Programing philosophy applicable in a C environment in a more easy way (the key is more easy, since you can apply OOP using only plain C). Now, the OOP philosopy was created for fast coding and fast reuse. Those concepts was encouraged from the coding on demand, that is, to write end-users applications in short time (that's why most of actual on-demand enterprises uses ObjectivePascal (Delphi) and Java). So, OOP was created to write final applications. So C++ was designed to write final applications. So C++ wasn't one of the best languajes to write low-level operations.

Allegro's name cames from Atari-ST Low-Level Game ROutines. So (you guessed it) I think the Allegro API must be writed and designed in plain C.

Of course you can argue that some of the newest operating systems are OOP-oriented so OOP would be good to write lo-level things. Even more, an OOP operating system is much better since they have encapsulation, inheritance and all that.

That's wrong. A low-level operation needs a low-level acces through a low-level languaje and OOP specifies that the low-level code must be encapsulated and keep inaccesible. That's why I think that code an OS with an OOP philosophy is't the good way.

Anyway Allegro is very object oriented now. Just see the BITMAP or the GFX_DRIVER structures.

Write a C++ wrapper is stupid, I think. A different thing would be to write a C++ game engine using Allegro as base. That's wat I did: wrote a bunch of classes that are more than simple wrappers. An example: I created a dirty-rectangle engine and my sprite class' method Draw also puts the sprite's rect inside the dirty-list.

That was my opinion.

SCUMM doesn't exactly count as a programming language in my opinion.

"It is also a recursive acronym which stands for "Allegro Low Level Game Routines".

As far as I know SCUMM is a virtual machine, so it need a language even if it's a byte-code language. Aniway I can be wrong. I never used it but there are a SourceForge's project to create an Open-Source SCUMM interpretor.

About the name of Allegro, the key is the ll/Low_Level. Don't worry about if the A means Allegro or Atari.

Assembly it is then.

The idea of "low level" is the abstractness of the API. If it had it's own animation system or tilemap system or 3D modeling API, it would be high(er) level. But it's not. The language doesn't really enter into it.

Whoever said that C++ wasn't low-level?

In a perfect world, you would be able to keep the core API down to ASM...

Something like this hierarcy tree...

<code>
Core ASM
DLL/Shared Lib interface *
/ \
INTERFACES C C++, etc.
<code>

Using this hierarcy of inheritence it shouldn't be difficult to support other programming languages such as python even.

If we are going to break compatability, we might as well do it right.

I'm late ... but anyway:

Why, functional programming, of course!

About the low level comments: This becomes a definitional issue, but it is definitely a stretch to call allegro a low level library, ESPECIALLY in the content of OS/systems programming.

I somehow doubt allegro is being used on embedded systems so underpowered that they cannot support C++, but powerful enough that they can support allegro in its current form. But aside from that, since the context of this discussion is that the allegro internals may already be written in C++ circa version 5, it seems more than a little silly to site performance reasons for choosing C.

I really doubt there is serious technical justification for making the exposed interfaces C. It's a style issue and should be treated as such. That said, as a C++ user I have no problem hooking in to C interfaces, whereas as a C user it would be somewhat more annoying to use a C++ interface. And clearly allegro has C users. For this reason alone I think the choice to have a C interface seems reasonable enough.

About namespaces, to return to the original discussion, I think Evert's suggestion earlier in this thread is a good one; it solves the problem as much as it can be reasonably solved

Honestly people, what is it with the myth that C++ doesn't function as well as C on older machines? Seriously people... C++ is essentially C with a bunch of added convienences that you should learn to enjoy. Welcome to the 80's... get with the C++ program already. If C++ doesn't work on "old" computers... get off of your 8088 that (how the heck your getting internet access on that thing beats me... but comeon people, your not running a rock with an electrical plug.

C++ can be just as fast as C, in the hands of a skilled programmer. Seriously, everyone is always complaining about how C is better than C++ because it is faster. Says who? Seriously... if you want to stay in the dark ages with you and your pet dinosaur rex, go ahead. I'm all for a completely rewritten Object-Oriented Allegro.

I think the "myth" that C++ is generally slower than C has it's merits. Especially on smaller programs. Note that I have never tested myself, but this is my logic behind it: C++ has added features that C doesn't have, so as a result the compiler can make fewer assumptions about the code. Also, C++ code tends to be more object-oriented, and programmers tend to put different "objects" in different source files in such an environment, so this blocks some possible compiler optimzations(at least until more compilers start supporting link-time code optimizations).

A basic example(by no means indicive of how C++ can be slow, but an example non-the-less):

some_struct a, b;
a = b;

In C, this would probably invoke some kind of optimized memcpy() equivilant, which would probably be inlined. But in C++, it'd have to search the struct's/class's vtable and call the apropriate(maybe, maybe not unoptimized) copy routine, which can only be inlined if the code happens to be in the same source file that it's it's trying to be copied in(on some popular compilers).

Granted that's only a theory of mine, possibly wrong, and not indicive of the possible slowness of C++ as a whole... but yeah. That's my 2 cents.

That may be true. But let us think about the application of our particular library. Who, in their right mind, is going to write a 2 line application using allegro? Lets please take into consideration what exactly we are programming this library for... Games. Games are by no means a simple task. Having the Allegro Library be object oriented would make your job much easier. Perhaps C is faster in small applications; KC, Games are not small applications. Consider the target audience please.

Here, I'll write some quick test applications...

Yes, it's known that virtual functions can be slower. But there's nothing stopping a C++ coder from inlining that function if he can

I think a C++ Allegro would be great. But locking out the C users is a bad idea. Us C++ guys should be writing wrapper classes for our graphics that transparently use OpenGL, Allegro, and DirectX anyway

No, it would make me not use it.

You may take your C/C++ war in private elsewhere. Neither is better than the other. Just live with that fact, even if you don't ever learn it.