next »

[Sushi]

How does c# compare to delphi? That would be interesting to know considering the same guy designed both languages.

Well, the main difference one is native and with manual memory management and the other the opposite, non-native & garbage-collected. There are other differences of course, but that is really the biggest ones 

[Geti]

Surely the difference in syntax is reasonably important to note as well?

[Sushi]

Ah, sure, I guess I'm too used to both. But... the sintax is not really that different, to the point that converting code between a pascal dialect and a C dialect can be done easily by search & replacing a few keywords.

Both have good and bad things I guess 

[WoldenDans]

C++ undoubtedly. That's also the language I hate the most. We are in a passive-agressive relationship. It's one of the most powerful and complete language I know, but also one of the ugliest and deeply complex.

Just try CRTPs: http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern

[Quarry]

I like Java, bring the executioner

[Geti]

I like Java, bring the executioner

I think Java is certainly usable (and doesn't suffer as much slowness as some would have you believe, I've seen bad cpp rub just as slowly as bad Java) but I've grown to hate the way it forces OOP onto everything a lot over the past 3 years quite a lot.

That and the constant ask toolbar nagging on desktop is terrible

[InfiniteStateMachine]

and the damn forced exceptions, many of which are in the standard library

[Geti]

Oh yeah that too, though I see that more as a library problem than a language problem (doesn't prevent me from being annoyed by them every time I need to use java though, haha). Particularly insidious are a lot of standard lib close() functions that potentially throw and as such require trys within finally blocks.

Dacke is a java fan iirc, haven't seen him around here so much recently though.

[Sik]

Particularly insidious are a lot of standard lib close() functions that potentially throw and as such require trys within finally blocks.

Oi, while I can see the logic (e.g. closing a file can fail if the hardware breaks or connection with the hardware is lost or anything like that), yeah it probably could have been handled better... though I guess it'd be inconsistent with the rest of the API. For example, in C fclose can fail (many people don't know this!) for pretty much the same reasons I mentioned, but regardless of what happens the file will be closed - the error code is just to tell you if the file became potentially corrupt or missing.

[Geti]

Yup, and you're not forced to check for failure if you don't really care (like if you just wanted to make sure it's closed to avoid file handles leaking) - in java this could have been implemented the same way as in C but I guess they decided exceptions were the best way to check errors and really went for it.

[nikki]

on those c# java exceptions: I am starting to get a little in the D language, for that case they've made a very clean alternative : scope()

from some stackoverflow example

with exceptions

Code:

sqlite3* db;
sqlite3_open("some.db", &db);
try
{
    sqlite3_stmt* stmt;
    sqlite3_prepare_v2(db, "SELECT * FROM foo;", &stmt);
    try
    {
        // Lots of stuff...
        try
        {
            make_changes_with(stmt);

            // More stuff...
        }
        catch( Exception e )
        {
            rollback_to(current_state);
            throw;
        }
    }
    finally
    {
        sqlite3_finalize(stmt);
    }
}
finally
{
    sqlite3_close(db);
}

same thing using scope()

Code:

sqlite3* db;
sqlite3_open("some.db", &db);
scope(exit) sqlite3_close(db);

sqlite3_stmt* stmt;
sqlite3_prepare_v2(db, "SELECT * FROM foo;", &stmt);
scope(exit) sqlite3_finalize(stmt);

// Lots of stuff...

scope(failure) rollback_to(current_state);
make_changes_with(stmt);

// More stuff...

return;

the biggest problem it solves imo are those nested try catch things, they always hurt my brain and litter my screen otherwise.

[MorleyDev]

I prefer unchecked exceptions, especially since in general think exceptions should only be for the exceptional situation. There for when you need to "fail" fast, and whilst handling the exception is possible they are best used when the default operation of someone integrating against a function that throws will generally be to back out completely and fail (InternalServerError in a server, CTD in a program). It's a complex topic, but in general:

If failure is an expected or likely result of an operation, return.
If failure is a result of incorrect pre-conditions and should not happen, throw.

So if you are trying to get an item a user requests from a database, that item not being there is not an exceptional situation and the return code should encode the fact that the item could be returned empty (I like to use something like Scala's Option class for this, and

return null).

But the Database being down is an exceptional situation and as such some sort of "DatabaseNotFoundException" should be thrown.

Functional languages have the best support for ideas like "Option" and "Either" since they come from the functional world, but other languages are adopting them into their standards because they are useful.

[Sik]

Yup, and you're not forced to check for failure if you don't really care (like if you just wanted to make sure it's closed to avoid file handles leaking) - in java this could have been implemented the same way as in C but I guess they decided exceptions were the best way to check errors and really went for it.

If you opened a file for reading then something really needs to screw up for closing to damage the data (to the point you probably have much bigger problems way beyond your scope). When writing it may be a good idea to check for it even if just to warn the user that something may have gone wrong.

Probably the worst case I've seen is with PhysicsFS: if there are any files opened you can't deinitialize the library, but closing can potentially fail (and will stay open in such a case!), and this means you can actually become unable to deinitialize (by having some file that keeps failing to close). I don't think I need to explain how bad it is, especially considering how the condition can be pretty easy to trigger (just tell the program to open a file over a network and then kill the connection, suddenly closing will fail since the program can't tell the network to close it).

[selvin]

Java for enterprise application.

C# for game dev.

[Geti]

@Sik: not sure what part of the quoted text you're responding to there, but that seems like a really bad design choice in PhysicsFS.

@MorleyDev: I agree with you in principle but find myself annoyed by exceptions in almost 100% of the cases I use them in. I tend to compile cpp with them turned off completely (and have started turning off RTTI as well).

[vinheim3]

C++ no doubt, simple to use/understand/work with, only really gets ugly when dealing with things like pointers, but I heard they came up with something called smart pointers that makes it easier to deal with.

[oodavid]

Javascript for everything.

I deserve to be punished.

[InfiniteStateMachine]

C++ no doubt, simple to use/understand/work with, only really gets ugly when dealing with things like pointers, but I heard they came up with something called smart pointers that makes it easier to deal with.

My secret shame. I still use raw pointers. I haven't really every been bitten by pointer issues.

That said I dont use pointers super often and I'm really paranoid when I do use them.

[Ashaman73]

For enterprise application java.

For game dev C++.

For scripting lua.

[Boreal]

Personally, I'm quite comfortable with pointers and pointer arithmetic.  Getting into data-oriented design and cache-friendly code has really shown me how fundamental and simple pointers are.

I think the problem most people have with pointers is that they're not used to thinking of everything as it is stored in memory.  Only languages like C and C++ allow you to do this.