OSNews

I agree, Robert have just limited the development on SkyOS to just C++ type languages. Effectively removing a lot of the developer community ... Way to go I was looking forward to developing on SkyOS, now Robert made that impossible.

Aren't most languages nowadays Cplusplus-like, anyways?

No, particularly not at a binary level. On many platforms C++ code isn't even compatible with that generated by other C++ compilers on the same platform.

The object model of most OO languages nowadays is single inheritance with interfaces, not multiple inheritance like C++. Many of the newer languages are even more interesting than that, but in completely different ways than C++ on a semantic level. Even on a syntax level most languages that supposedly are derived from C++ have more in common with each other than they do with C++, having fixed many of the glaring mistakes of the C++ syntax in similar ways.

Still, the C language is so semantically weak that it really is a poor foundation for an API. C has mostly been used as a least-common-denominator language, both its strength and its weakness. A strength, because its semantics can be a subset of most languages, so it can be possible to write code to interface to C libraries. A weakness, because the language is so limited and unsafe that you have to write lots of wrapper code around those libraries just to be able to use them safely and easily.

At least with C++ you can write a powerful API that does most of the work for you, as long as you are careful in the design of that API. If you are careful enough the API can even be designed with easy interoperability in mind. We'll have to see if that is the case here.

On many platforms C++ code isn't even compatible with that generated by other C++ compilers on the same platform

The cross-vendor C++ ABI solved that problem several years ago. Unless you are using old compiler(s), but otherwise it's a non-issue these days.

If you know C++ well enough and design correctly, it is actually entirely possible to create a C++ API that's compatible with every language that can call C linkage functions, and it won't look significantly different regardless of which language is used. However, most C++ people are too purist to have considered it, or think it's ugly, whatever...

I gave a presentation on the solution I proposed at WalterCon 2006 in reference to solving the Fragile Base Class problem, which is something that's likely to sooner or later become an issue with the SkyOS C++ API. It requires a major change in the API, of course, so there's no backwards compatibility with existing code.

Do you have a link to your presentation or the material you presented?

I'm not aware of any videotape of my presentation, and I did it off of a few notes I wrote up, which are not a full formal document, sadly. The best I can do is without typing everything fresh as a dump of my brain is provide links to others that commented about it that were there, and IIRC there's only really one person that posted that online.

Look under the heading for Sunday, October 29th, second paragraph, here:

http://haiku-os.org/news/2006-11-01/my_experience_at_waltercon_2006

WalterCon is a rather informal affair, with just a hint of organization of cats attempting to herd cats

The point is, if Robert wiped out half the development community, or did what you suggested above. I have not found anything on the site yet, to convince me that he did as you have suggested.

Not every. Just to mention the better known ones: MFC for Windows is C++, so is the whole BeOS (plus Haiku, Zeta) API.

Surely, there are darker and lighter sides of a decision like this. This one lets the coders do more powerful coding, while enshorting the list of compatible platforms. It may be worth.

Edited 2007-05-07 20:06

As both a BeOS developer and a Windows developer (amongst other things) let me clarify:

MFC is not an API, but rather a fairly thin C++ wrapper/frameworks around the C API of Windows.

Also, not the entire API of BeOS/Zeta/Haiku is pure C++: there are quite a few things in them that are straight C, even in the GUI API, but most definitely anything that talks to the kernel is straight C.

Not every. Just to mention the better known ones: MFC for Windows is C++, so is the whole BeOS (plus Haiku, Zeta) API.

Although you are right on BeOS, it is most definitely the exception, not the rule. And even then it is not a pure C++ API. Be's API is a C++ wrapper around a C based kernel. Technically, it could be considered a framework, but since it is the _primary_ programming interface for the OS calling it an API is entirely appropriate.

As for MFC, it is not an API at all. It's a framework and the 2 are not the same thing. Windows has a C API (Win32) just like Linux (and just about every other unix variant). MFC is conceptually equivalent to GTK++, it is a wrapper around a C API.

I personally think replacing a C based API with a C++ one is a bad decision, and I dont think that is really what we are talking about here. Although the article states this is a C++ API, Im pretty sure it is actually a wrapper around the existing C API.

I could be wrong but if I am I question the sanity of the development team as throwing away a working C API and replacing it with a C++ one is essentially starting over - EVERY piece of software written for this OS would be instantly rendered incompatible. Im pretty sure that is not the case here.

(also @ JonathanBThompson)

Yes, there are exceptions for BeOS, although the main concept is having a C++ API for the OS which practically forces any not strictly low-level software to be developed in cpp.

Due to the meaning of the term we are talking about (Application Programming Interface), MFC is an API which - of course - does not cover the whole OS API (= is not the Windows API), but in some ways quite important part of that and also is an "official" push to go with C++. I admit, I was not properly clear while mentioning, sorry for that.

And yes, I would also be interested to know if the announcement is about a whole replacment or just a new layer - or somehow combined. I also think an all-radical decision could be very confusing for the whole development process.

I am a C++ programmer my self and I would have to say that in my opinion C++ is a better way to go. Having class-based API or to be more precise, Object Oriented API is more powerful and flexible than pure C based APIs.

Edited 2007-05-07 20:36

Many C APIs are object-oriented, they just don't require an object-oriented programming language in order to be used.

The idea of needing an OOP language to write in an OOP fashion is a fallacy I thought had died out a decade or so ago.

If anything c++ as a language allows the compiler to be more "anal" and also allows the code to be more self documenting than 'c'. However it requires a bit of experience and a ton of discipline to make this a reality.

Compilng c++ using max warnings and keeping away from templates (stl), and multiple inheritance should result in fast compiling, fast executing and very portable code.

Templates really aren't that bad, but c++ is hurt with scoping issues where closures aren't allowed, which would be awesome for writing understandable stl adapters.

If there only were a "perfect" language...

"Comment locking" has been around since v3 rolled out, there just wasn't a way to show it in the UI. Future comments about moderation will be voted down. If you want to discuss it, create a conversation on v4 beta.

Adam, this makes it an absolute mockery of peer moderation: either you have it or you don't (I was never in favor of peer moderation to begin with).
I'll boycot posting in this place and I'll make a hell of a fuss everywhere else until this issue is solved.

There's no issue, AP. When certain posts are modded to -5, they get *automatically* locked (most of the time, it doesn't even take an admin to autolock a post, the system knows when a comment is that bad based on certain factors). It's always been that way, and it that certainly doesn't make a mockery of anything.

This is, and always has been, an admin controlled site. So, although we allow our readers to do 95%+ of the moderation, some comments we intentionally lock down. And in those cases, I don't think we need to justify our actions.

That said, I'll remind you, it's been this way for 3 years now, and no one has complained because it wasn't transparent. If it's only a problem now that we've shared more of how the site works, that's certainly a convincing reason to lock it down further and keep our readers in the dark.

"That said, I'll remind you, it's been this way for 3 years now, and no one has complained because it wasn't transparent."

Then I am missing something, because till today I had always been able to mod up a post with a -5, and I did it quite often.

Not all of them. There are MANY locked posts, and like I said, the algorithm means most of them were locked by the system, not an admin. If you want to discuss, please open a "conversation" on v4 beta and we can continue this. I don't want to have a major subthread in this SkyOS article.

It's a rather asinine thing to do. "We know what's best for you."

Repeat after me: The Internet is NOT a democracy. Moderators are not fascists or dictators. Your civil rights are not in danger.

Now I can't say about this board, but trust me, certain moderators are indeed quite fascistic, once i was banned from a history forum because the moderator didnt like my references to historic facts, I was unbanned by the admin and other moderators immidiately, I can only pitty that not many forums are like that one.

Edited 2007-05-08 20:57

No; I posted on the beta forums, and was told it wasn't a goal of SkyOS.

If that was wrong, I'll post a bug report.

partially. For instance the FileManagement/Query/Process/Date/Time/DesktopCommunication etc. classes make use of the native C libraries where appropriate. Obviously the new API doesn't replace the standard C library at all.
GUI classes as well as a few new Utility classes are "native" C++ implementations, meaning that they will replace to old libskygi C library completely.

Er, yes, of course you can export symbols as extern "C", but only functions which are compatible with a C-style calling-convention: you can't export class members, or for that matter whole classes, let alone namespaced symbols (without losing the namespacing). If every API was declared extern "C", there wouldn't be any sense in calling it “a C++ API", it'd just be "a C-style API that happened to be written in C++ [entirely an implementation detail]". Producing "a C++ API" ceases to be an implementation detail, because it dictates the language bindings you must use unless you're incredibly careful. And yes, BeOS's APIs were all C++, but aside from projects like Haiku it's not really had a lot of longevity; it would be stretching the truth a little to say that BeOS's API was a good example of a successful C++-only API.

As has been said, the C bindings are typically the greatest common factor between languages (which is both a strength and a weakness, of course), which is why they're provided. There are methods—such as (XP)COM—that you can use to make C++ classes callable from non-C++ code, but you really have to plan ahead for it. Inevitably, as soon as you create bindings for any sort of interpreted language, you'll find that you're having to encapsulate your classes in very C-like wrappers.

Unless your language is either open-source (or extensible with native-code extensions like REBOL 3), at which point your wrapper code will only be as C-like as your language's underlying source code (or plugin API). A well-designed modular language implementation can wrap C++ code with ease, particularly if it already needs to on other platforms and so is prepared for the task.

Hey, if the last comment didn't deserve it, this one certainly did. Look what your peers did to you: they handed you a big fat -5 in minutes.

Wow. I've officially lost any hope for this site comments if that's the case then.

I've staved off the ridicule i get for reading this site from coworkers, now I'm off of it completely.

they handed me a -5 for proactively trying to stem the impending flamewar?

i'm at a loss for words...

See ya. Apparently this site is overly moderated, and thus, useless.

It's been fun osnews. I've been reading here for like 5 years or so. It was good until you started allowing comments.

You were modded down, and I think everyone knows why: you started your comment daring people to reply, and then you posted an off-topic comment ranting about the mod system that YOUR FELLOW READERS applied to you. That's against the forum rules and you were properly penalized. There ARE portions of the site where you can discuss it, you chose the wrong venue, and you were dealt with. Those are the site rules, always have been. I'm sorry you're upset with them, but if your mind is made up -- see ya.

I'm not upset with the rules, I'm not upset at all. What is annoying is that yet another site has been ruined by it's moderation system, and the abuse of it. If you really think that my post was flamebait, then it's clear why the quality of articles posted, and comments have continued to decline. Additionally, I didn't start anything about the moderation system until it was used stupidly.

Sheesh, I remember when the internet still had an actual purpose, other than being full of people trying to make themselves feel important.

Ok... ok. The mod system is what it is, for better or worse. It seems to work fairly well and keep most of the trolls at bay. At this point, I guess I'd ask you to

1. Take it offline with me or anyone else. If you want: adam at osnews DOTCOM.

2. Take it to the conversation here http://www4.osnews.com/conversation/463fdd2d which is already about moderation

3. Accept that peer moderation has its downsides and move on

or

4. Actually leave.

I hope you choose one of the first three, but if we continue on here, you're probably going to get modded down again, as am I.

A suggestion if I may:
Don't get hung up on the modding system. It's fundamentally flawed as people can't be trusted. Just ignore it. Who cares if some loser didn't agree with what you wrote and decided he would flout the modding rules? Just pity him/her and move on.