Allegro or SFML?

[Disch]

There's nothing wrong with a good C library and to be quite frank, they seem to be much more straight forward and simple.

I disagree.

I fail to see how a C version of SFML could be any simpler than the C++ version. The only difference I can imagine is that you'd have to manually do your own cleanup in the C version.

[N36fSL3A]

I like C libraries better. I don't know why, it's just preference.

[Disch]

C libs are certainly easier to link to due to lack of name mangling.

That's a pretty huge selling point, but as far as I can tell it literally is the only selling point unless you just prefer C as a language over C++.

[S6k9GNh0]

I believe a C interface is more simple, not so much the implementation. Rather, a lot of my C libraries actually have C++ implementations (well... anything to do with networking since I only use ASIO as of right now).

If I wanted C++ candy, I can always wrap around a C library and inline.

[Disch]

I believe a C interface is more simple, not so much the implementation.

I don't follow.

How is this typical C-style lib interface:

Type* obj = lib_CreateObject();

//...

lib_DestroyObject(obj);

simpler than this typical C++ style interface? :

lib::Type obj;

//... 

EDIT:

(A typical comparison which fits the above example would be SDL_Surface vs. sf::Texture)
(and cstdio's FILE vs. iostream's fstream)

[N36fSL3A]

It isn't.

I like the C interface a lot.

But if I wanted a C++ interface, simple.

class Derp
{
    public:
        Derp()
        {
            derpData = LIB_CreateDerpDat();
        }

        ~Derp()
        {
            derpData = LIB_DestroyDerpDat();
        }
    private:
        derpdat* derpData;
}

[S6k9GNh0]

It's not the verbosity that is simple in my opinion, it's actually how explicit it is. I don't mind RAII but it's not always the best solution when it causes things to be unobvious like certain things being destructed without you knowing about it. Often a time, a C++ library can be deep into C++ style coding that you have to read into how that general concept works like PIMPL, types of template programming, etc.

If you've ever started trying the Boost Spirit parser, most people look at that and just leave because they can't make heads or tails of it. Although, to be fair, it isn't possible in C. So there's a tradeoff and it comes down to preference in my opinion. With feature comes complication of the exponential degree. That's what my experience seems to be telling me right now but I do see exceptions.

[Duthomhas]

Nah, y'all are just pushing your evangelism for C over C++.

All the stuff you are claiming as reasons for the better-ness of a C library over a C++ library is straw man.

Comparisons with other libraries, especially monstrosities like Boost.Spirit, are also not a useful criticism of SFML's C vs C++ library.


The fact remains that there is a C wrapper for the C++ SFML library that looks and behaves just like any other C library. It compiles and links and works with any proper C compiler, and it doesn't suffer any of the anti-C++ problems with name-mangling, coding style, etc.

Quite simply, y'all're just biased for C against C++.

And while you may certainly have any bias you want, you cannot take that bias and claim any degree of objective reasoning as you are attempting to do.

@Lumpkin
How is writing your own interface for a library that already provides you an interface simple? It is never simple to do more work. Your argument does not apply to SFML or its choice of C++ with a C wrapper.

Laurent seems to prefer to write his library in C++, as is his prerogative. And he also seems quite happy to provide a C interface to it as well.

When you write your library, do it in C and let your users wrap it in C++ for themselves.

Then let the masses decide which library they like better.

[S6k9GNh0]

Duoas, I'm mildly disappointed by your post. It seems you completely ignored the posts regarding what you're trying to dispute and almost seems like blind faith. I do agree with you're end statement but claims about biased-ness is short of thought.

[Abramus]

The thing is… you can use a C library In C, C++, and basically any other self-respecting language without much trouble. On the other hand, you can use a C++ library in… not even C++ as you need the same compiler, and maybe even the same compilation options. That’s the reason there is a C wrapper for SFML. You don’t need any wrapper to use a C library for example in Python. You just import functions directly from dll via ctypes and that’s it. Try that with a C++ library…

[Disch]

Abramus: You are absolutely correct. That's what I was saying before about ease of linking being superior in C due to C++'s name mangling.

That is a very legitimate reason to prefer C libs.

But that's not what these other guys are saying.

[Duthomhas]

Call the kettle black, then.




I hate doubletalk

[Disch]

I don't think I've been speaking double talk =P I thought I made my standpoint pretty clear before:

I wrote:

C libs are certainly easier to link to due to lack of name mangling.

That's a pretty huge selling point, but as far as I can tell it literally is the only selling point unless you just prefer C as a language over C++.

[Disch]

Double-posting here... I felt like actually responding to computerquip:

computerquip wrote:

It's not the verbosity that is simple in my opinion, it's actually how explicit it is.

I wouldn't equate 'explicitness' to 'simplicity'. But I see your point.

That said.. there is literally no reason why a C++ interface could not be as explicit as a C interface. Remember that any style you adopt in C could be adopted in C++ as well... and you're talking more of a style standpoint than a language standpoint.

Furthermore, if you want to have explicit construction/destruction of an RAII object in C++... the C++ interface is still just as simple/explicit as the C interface:

// C interface
    type* obj = lib_Create();
    // ...
    lib_Destroy(obj);

// C++ interface (verbose)
    auto* ptr = new lib::type;
    // ...
    delete ptr;

So I still fail to see where this claim of simplicity is coming from.

I don't mind RAII but it's not always the best solution when it causes things to be unobvious like certain things being destructed without you knowing about it.

How can you not know if something has been destructed? It's destructed when it goes out of scope. If anything it's harder to know when an object hasn't been destructed (ie: memory leak).

And I'd say that RAII literally IS the best solution (in a non-GC language) for anything which requires allocation of resources that must be deallocated at a future time.

Especially in C++ where you have exception safety to consider.

(but no... exception safety is not a C-lib vs. C++-lib issue... it's a C vs. C++ language issue... so yeah if you prefer C because it lacks exceptions, then that's one thing.... but don't try to pin that thing on a lib interface because it's totally unrelated)

Often a time, a C++ library can be deep into C++ style coding that you have to read into how that general concept works like PIMPL, types of template programming, etc.

If you want to compare the most complex C++ libs against the simplest C libs, that's completely unfair.

If you want, I can find and show you plenty of C libs which are frustratingly complex, even without templates.


And BTW.. the PIMPL idiom is practiced more often in C than it is in C++ (as it is the only way to hide access to 'private' members in C)... so I don't know what you were trying to get at with that point.

It also has nothing to do with the lib interface, because the impl is the implementation not the interface. The whole point of pimpl is to hide the implementation from the interface.

If you've ever started trying the Boost Spirit parser, most people look at that and just leave because they can't make heads or tails of it.

Yes, boost is a hornet's nest of complexity. I never said otherwise. But again you are picking unfair examples.

Let's stick with Apples to Apples comparisons here... and since the original topic was about libs like SDL.... explain to me how SDL's interface is simpler than SFML's interface... because these are two very comparable libs and it's a reasonably fair comparison.

[N36fSL3A]

Disch said

// C++ interface (verbose)
    auto* ptr = new lib::type;

I actually just do this.

type* ptr = new type("parameter");

[Disch]

Well it has to a pointer, so must at least be doing type* ptr = new type(...); (you forgot the '*') ;P

But yeah you can do that. Although I prefer auto when I can use it... especially if the type name is long.

[N36fSL3A]

D: Nothing gets passed you :P

[Disch]

*passed

;P

[N36fSL3A]

Ugh, :(

As for SDL v SFML.


SDL is smaller than SFML from what I've read. It also has more platform support.

[Disch]

Neither of those points have to do with the interface... which, according to computerquip, is "simpler [snip] because it's C".

So let me rephrase my question:

How does being a C lib make SDL's (or Allegro's) interface any more simplistic than SFML's C++ interface?

I'm asking specifically about the interface because this is [thus far] the only reason proposed by computerquip as to why C libs are preferred over C++ libs.


The only reason I'm really pursuing this is because Duoas called him out for being a C fanboy. He then proceeded to say he was "disappointed" in Duoas' response, and accused him of not reading the thread.

Well I've been reading the thread. And I think the points I've been making are pretty sound... (or at least they're not disappointing). So I'm trying to give him a chance to put some substance behind his view so that he can show he isn't just being a fanboy... but rather actually has a logical reason for his position.