next »

[JoeHonkie]

I don't think there's any excuse whatsoever having to write everything twice.

I have been looking into objective-C and this scares and angers me.  I like the C++ model better.

[Average Software]

I don't think there's any excuse whatsoever having to write everything twice.

I have been looking into objective-C and this scares and angers me.  I like the C++ model better.

What?  Objective-C and C++ have the same model.

Code:

//C++
class Widget
{
public:
    Widget();
    ~Widget();
    void Draw() const;

private:
    unsigned x_pos;
    unsigned y_pos;
    std::string text;
};

Widget::Widget()
:x_pos(0)
,y_pos(0)
{
}

Widget::~Widget()
{
}

void Widget::Draw() const
{
}

// Objective-C
@interface Widget : NSObject
{
    unsigned x_pos;
    unsigned y_pos;
    NSString *text;
}

- (id) init;
- (void) dealloc;
- (void) draw;

@end

@implementation Widget

- (id) init
{
    self = [super init];

    if (self != nil)
    {
        x_pos = 0;
        y_pos = 0;
        text = @"";
    }

    return self;
}

- (void) dealloc
{
    [text release];

    [super dealloc];
}

- (void) draw
{
}

@end

[JoeHonkie]

What?  Objective-C and C++ have the same model.

I meant C#/Java.  I'm tired & It's my bad.

[Core Xii]

You only write the names twice.

Don't you need the return and argument types for functions as well?

[Average Software]

You only write the names twice.

Don't you need the return and argument types for functions as well?

The argument types are part of the name of the function in languages that support overloading, the return type is as well in languages that support overloaded returns.

[BorisTheBrave]

It's not the repeating that is in excusable - you shouldn't want all your function bodies inside the class if your language doesn't enforce it - it's the fact that you are forced to lay things out in an odd way. You'll get linker errors or unreasonable compile times if you put the wrong things in headers or source files files.
I understand that many of C++'s excellent features (such as perfect memory layout), wouldn't be possible otherwise, (given the compiler/linker setup) but that doesn't mean you have to like the consequences.

[Klaim]

Agree with BorisTheBrave.

[Average Software]

It's not the repeating that is in excusable - you shouldn't want all your function bodies inside the class if your language doesn't enforce it - it's the fact that you are forced to lay things out in an odd way. You'll get linker errors or unreasonable compile times if you put the wrong things in headers or source files files.
I understand that many of C++'s excellent features (such as perfect memory layout), wouldn't be possible otherwise, (given the compiler/linker setup) but that doesn't mean you have to like the consequences.

This why I say that C/C++/Objective-C/(Fortran?)'s headers are a good idea with a bad implementation.  None of the these languages actually know anything about header and source files, they only know translation units.  Header and source files are just a convention that everyone uses and they do take some knowledge and effort to get right.

Ada's headers got this perfectly, since the languages specifies precisely what can and can't go into one.  If you try to put code in an Ada header, the compiler won't take it.  Most of the gripes with C family headers come from the weak compilation model, which I really do wish they would fix.

[Klaim]

Notice that the problem might be solved in some years for C++, the "module" feature have been raised some years ago and the commitee plan to have a final word on it (and on -optional- garbage collection) for the next revision of the language (theorically for 2013). (about modules, see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2073.pdf I don't think it's the last revision but couldn't find any other recent versions of the paper)

C++ have time for it as it allow us to use old and new code together. Anyway C++0x will simplify a lot of things (but not all) if you focus on using the new features instead of the old ones (because the new ones simplify the old ones...).

D lack of rock-solid real-world base that C++ had from the start (C softwares) but I really think the two languages could happily work together in the game development world - at least.

[Ryan]

Edit: DON'T DO THIS!
(Unless you want all of your methods to be inline)

I hate the header / source file split so much that in small projects, I do the "bad" thing and use one cpp file for main, and put all my other classes + implementations in header files.

A.h

Code:

#ifndef A_H
#define A_H

class A
{
        private:
                int   x;
                float y;

        public:
                A(int x, float y) : x(x), y(y)
                {
                }

                void DoSomething()
                {
                        x *= 3;
                        y += 0.5;
                }
                ...
};

#endif

main.cpp

Code:

#include "A.h"

int main(int argc, char* argv[])
{
        A a;
        a.DoSomething();

        ...

        return 0;
}

If you don't mind in participating in bad practices it's at least a temporary solution. 

[Average Software]

I hate the header / source file split so much that in small projects, I do the "bad" thing and use one cpp file for main, and put all my other classes + implementations in header files.

A.h

Code:

#ifndef A_H
#define A_H

class A
{
        private:
                int   x;
                float y;

        public:
                A(int x, float y) : x(x), y(y)
                {
                }

                void DoSomething()
                {
                        x *= 3;
                        y += 0.5;
                }
                ...
};

#endif

main.cpp

Code:

#include "A.h"

int main(int argc, char* argv[])
{
        A a;
        a.DoSomething();

        ...

        return 0;
}

If you don't mind in participating in bad practices it's at least a temporary solution. 

I hope you know that defining functions in the class body in C++ makes them inline.  You might not want that.

[Ryan]

I hope you know that defining functions in the class body in C++ makes them inline.  You might not want that.

 

How embarrassing; I've been programming in C++ off and on for 7 years and I wasn't aware of that. It looks like you're absolutely right. Luckily I've never done that in production code, just when I needed to throw little things together- but I'm sure it would have bitten me at some point. Thanks! I've put a disclaimer on my previous post.

[Zaphos]

It's not that big a deal -- inline is just a compiler hint anyway, and easy to change later on.  I often write code in the header file while I'm developing, then move it to the cpp file later on.

[FatHat]

D is really good at what it does, although I feel like the C family of languages has sort of run its course in a sense. Features like pointers are actually harmful when you get to the point where you need to make things massively parallel. What's more interesting to me are languages like Haskell and Erlang that can handle multicore processing a lot more gracefully, although they both feel very awkward to work with (but perhaps that's just inexperience?). I don't think our current languages are well prepared to handle the problems that we should really be concerned about, at least with regards to performance.

(I say all this as a huge python fan, whose bitter that the GIL still exists )

[moi]

Indie wannabees, use D and all your games will be in D.

[muku]

What's more interesting to me are languages like Haskell and Erlang that can handle multicore processing a lot more gracefully, although they both feel very awkward to work with (but perhaps that's just inexperience?).

I don't know if you have read the entire article, but D2 is taking a lot of ideas from the purely functional world in order to facilitate massively parallel software. All global variables are thread-local by default for instance, and there are pure functions.

That said, yes, Haskell is a very nice and interesting language, I'm just not sure how it would perform in a game development setting; that's a part I'm a bit wary about. Stephen (increpare) has done some work in that area though, he would be the right one to ask.

Also I've done some experiments with OCaml, which is faster than Haskell as well as less dogmatic in its functional approach, and it was promising at least, but in the end I didn't pursue that further for whatever reasons. In the end I grew up with C-like languages and it's probably just laziness to stick with them, but hey.

[bateleur]

Also I've done some experiments with OCaml, which is faster than Haskell as well as less dogmatic in its functional approach, and it was promising at least

One of the most complex programs I ever wrote was in OCaml (not a game). Its raw development speed for algorithmic stuff is hard to match (assuming you understand functional programming).

However, the downside for parallel programming is that you have to be quite disciplined in OCaml not to use imperative-style side effects everywhere. This, of course, breaks the inherent advantage that a language like Haskell brings to parallel programming.

Also, most games are naturally imperative in nature (dynamic user input!) and as such true functional programming isn't a very good fit. These days I'm happy enough using any language with good support for closures. That allows me to write in a very functional style when I want to without most of the costs.

[Ina Vegt]

There's Functional and Purely Functional.

I know there's F# for functional programming on .net, and Clojure for the JVM, any other functional languages that make use of a cross-language JIT framework?

[muku]

I know there's F# for functional programming on .net, and Clojure for the JVM, any other functional languages that make use of a cross-language JIT framework?

Scala on the JVM is a very enticing language, but it's more a multi-paradigm thing leaning towards functional.

[goshki]

I'm a huge fan of D myself and I'm fully aware that the following links may be a major repell for many people but to be quite honest with newcomers they should read some of these:

The Case for D - the other side of the coin by leonardo-m,
The Present of D by Jarret Billingsley, the creator of the MiniD library,
Re: The Present of D by h3r3tic, member of a very active polish D developers' team,
D - Good, Bad, Ugly, Pretty by Clay Smith, creator of the Arclib library

I'll stress it once more: I'm not trying to bash D here neither does any of the aforementioned writers because the language itself is very interesting and worth investigating and finally adopting. It's all about letting people know about the current state of D as a whole and I guess it's quite obvious that Andrei's article caused some of the hardcore D developers to actually express their opinion about it all.