Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Allegro Naming Conventions

This thread is locked; no one can reply to it. rss feed Print
 1   2   3 
Allegro Naming Conventions
Niunio
Member #1,975
March 2002
avatar

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.

-----------------
Current projects: Allegro.pas | MinGRo

Inphernic
Member #1,111
March 2001

Quote:

SCUMM to write adventure games

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

Quote:

Allegro's name cames from Atari-ST Low-Level Game ROutines.

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

Niunio
Member #1,975
March 2002
avatar

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.

-----------------
Current projects: Allegro.pas | MinGRo

23yrold3yrold
Member #1,134
March 2001
avatar

Quote:

About the name of Allegro, the key is the ll/Low_Level.

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.

--
Software Development == Church Development
Step 1. Build it.
Step 2. Pray.

Carrus85
Member #2,633
August 2002
avatar

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.

Zaphos
Member #1,468
August 2001

I'm late ... but anyway:

a j said:

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

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.

Matthew said:

You are shallow minded if you think C++ is always better than C. There's more out there than just high-end PCs

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

Carrus85
Member #2,633
August 2002
avatar

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.

Kitty Cat
Member #2,815
October 2002
avatar

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.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Carrus85
Member #2,633
August 2002
avatar

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

23yrold3yrold
Member #1,134
March 2001
avatar

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 ;D

--
Software Development == Church Development
Step 1. Build it.
Step 2. Pray.

Matthew Leverton
Supreme Loser
January 1999
avatar

Quote:

Having the Allegro Library be object oriented would make your job much easier.

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.

 1   2   3 


Go to: