This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
46
Announcements / Re: Bugtracker
« on: April 18, 2010, 10:40:15 am »...Is mimetic really the word you were looking for?Sign up link on the top rightThis definitely needs to be changed. That thing is mimetic.
47
Off-Topic / Re: Challenge
« on: April 14, 2010, 02:04:35 pm »D: That took me a whole 20 seconds.
Also, raw data = original data, not encrypted data.
Steps:
1. Base64 decode.
48
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 11, 2010, 11:24:31 am »
God damn miky, just write a program and get it out of your system.
49
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 08:47:41 pm »The second sentence is an opinion.PHP: All web languages are interpreted. PHP is the best one.Both of those statements are completely false.
Oh, it doesn't agree with your opinion? Special case! Then it's *completely false*!
50
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 10, 2010, 05:48:11 pm »If every segfault takes two minutes to fixIf every "null pointer exception" in Java takes 2 minutes to fix...
51
Announcements / Re: Anaphase
« on: April 09, 2010, 04:47:00 pm »Dude, honestly I could care less about the code editor.
I could care less about the code editor.
I could care less
I could care less
I could care less
52
General ENIGMA / Re: ENIGMA on iPhone - Now legally impossible
« on: April 09, 2010, 04:45:45 pm »
iPhone app store's T&C are worse than ridiculous.
53
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 08, 2010, 10:00:01 am »When I need to make a bot to do some mundane task, I use gm.When I need to make a bot to do some mundane task, I use PHP or Python.
When I need to make a small lightweight RAM filler, I use c++.
When I need to solve projecteuler problems involving GIANT integers (like 2 to the thousandth power), I use my TI-89 Titanium calculator with it's BASIC style language.
When I need to make a powerful game engine, I use c++.
It all depends upon what you're doing.
When I need to make a small lightweight RAM filler (o_O?), I use ASM.
When I need to solve (projecteuler?) problems involving GIANT integers, I just look it up on Wolfram Alpha.
When I need to make a powerful game engine, I use C.
I doubt Rusky uses haskell for everything, too.
54
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 07, 2010, 11:02:54 pm »And real programmers use it.Oh for jesus' sake, please at least attempt to quote me on this.
Entirely. I'm talking about objective flaws here, as time really doesn't phase me that much.It's perfect enough that I haven't found any genuine flaw with it yet.Are you serious?
55
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 07, 2010, 04:31:12 pm »
Actually, power kept going out and I couldn't be bothered to write another overly-complicated response.
Not arguments:
Not arguments and flawed anyway:
Flawed:
Actual arguments:
Etc.:
Not arguments:
I did program in ASM, and I just f***ing said C is too low-level, and you want me to code in Assembly?
If that's the point, then you should be doomed to code for eternity in Lisp, without ever being able to go back to C.
Different languages have different advantages. I *AM* able to code efficiently in Assembly and in C. I can code in multiple paradigms(the only one that's relatively hard for me to use is functional paradigm like what Haskell and Scheme use, but I am still able to code in Scheme!).
Not arguments and flawed anyway:
In contrast, you are so blinded by C that you are unable to see that there is anything useful beyond it. You use C in problems that are best solved in C, and I agree with you there, but you also try to put C in problems that would be better solved in C#, PHP or Lua. I think that's not being a good programmer. A good programmer uses the right tool for the right job. You use a sledgehammer for everything - fixing tables, opening doors, traveling to other places, everything - and indeed sledgehammers can, with some creativity(somehow) do all that, but the right tools for the right job is still the best choice.Supporting C doesn't mean I use it for everything.
Flawed:
And apparently, 90MB GCC API aren't very good. So it appears Java and .NET make better use of its space.Now, assuming you're using C++ with GTK, what can Java do that C++ can't?
Also, we're talking about convenience here. It's not about being just sloppy. A sloppy programmer can be a bad C# programmer as well(although arguably less dangerous?)Yet you never took this into account in most of your arguments against C++.
I am a C programmer and I am able to code it efficiently without memory leaks, but that isn't the only thing that matters. Because, like it or not, C isn't perfect.It's perfect enough that I haven't found any genuine flaw with it yet.
Actual arguments:
but programming a field that responds badly to throwing more people at a problem, so managing human resources efficiently is critical. And having programmers(even brilliant programmers) spend 10x more time to do the same is NEVER efficient human resource management. Not except in the few relatively rare situations I mentioned above.
Etc.:
Different problems are better handled differently. I can choose the language that fits the problem better. And, in fact, I have picked C++ in the past, I currently use it, and I will probably continue to pick it in the future when the problem I am faced with are best solved in C. However, I have used, I am using, and I will use in the future other languages(including Java and C#) when the problem is best solved in them.Example of when Java is better than C++?
56
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 07, 2010, 03:27:55 pm »
Cool story, bro
57
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 07, 2010, 02:40:02 pm »
Let's sum up your arguments against C:
1. Sloppy programmers can cause undefined behaviour using a strangely contrived statement.
2. Sloppy programmers can forget that a pointer exists and cause a memory leak.
3. The ~90MB worth of API (in GCC's case) is not enough.
I'd love to see you program in ASM, just because it'd be funny to watch.
(No APIs, behaviour is always defined but never forgiving, and no garbage collectors at all).
1. Sloppy programmers can cause undefined behaviour using a strangely contrived statement.
2. Sloppy programmers can forget that a pointer exists and cause a memory leak.
3. The ~90MB worth of API (in GCC's case) is not enough.
I'd love to see you program in ASM, just because it'd be funny to watch.
(No APIs, behaviour is always defined but never forgiving, and no garbage collectors at all).
58
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 07, 2010, 01:58:18 pm »In theory yes, but in practice it's always executed the same.Code: [Select]int x[5];
Causes a -Wall warning: "operation on 'i' may be undefined"
for (int i = 0; i < 5; ++i)
x[i] = 0;
int i = 1;
x[i] = i++;
printf("0=%d;1=%d;2=%d\n", x[0], x[1], x[2]);
getc(stdin);
On a lower warning level, you can get the warning "warning: no newline at end of file" - doesn't mean that your code is going to break on some random compiler.
Also, who the hell codes like that anyway?
You want C undefined behavior? This, for instance:Right, let's see:Code: [Select]int x[3];
Different compilers may give different results. In fact, the same compiler may give different results for that same code.
int y = 0;
x[y] = y++;
x[y]=y++;
That means "set x[y] to y, then increase y".
y is zero at the time this command is executed.
Let's see what we get from different compilers.
Code: [Select]
int main()
{
int x[3];
int y = 0;
x[y] = y++;
printf("%u,%u,%u\n",x[0],x[1],x[2]);
}
GCC:Quote
0,4199264,2359160BCC:
Quote
0,256,1MSVC++:
Quote
0,3435973836,3435973836
59
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 07, 2010, 09:18:15 am »While Java and C# have bigger runtimes, they are not necessarily bloatedJust big-boned, eh?
Different computers have different hardware. Some processor-specific optimizations fail when you switch computers.Yes, there are processor-specific optimizations, but then there are the optimizations that actually matter: common-sense optimizations.
At one point in the DirectX 9 code, it uses this gem:
Code: [Select]
add esp,0x10
mov esp,ebp
Now, not only does that not use the shorter "leave" command, but it performs arithmetic and then just deletes the result!Any good optimizer could spot that right away.
Also, on prediction of C and Java, consider this code:Anyone who doesn't set a variable to NULL after freeing, if other functions are still using that variable, is really lacking foresight. As I see that, you're telling the computer to check if a variable equals zero, and if not then attempt to access memory a few bytes after where it points to if it doesn't. "x" is an abstraction, it doesn't exist. If you take away the foundations behind this abstraction, it's no surprise that it no longer works. The behaviour is perfectly predictable.Code: [Select]//C++
if (x != NULL) x->someField = 2;
//Java
if (x != null) x.someField = 2;
In Java, I can predict that someField of x will become 2.
In C, I can predict nothing. In spite of the check, the application could still crash(segfault) if, for instance, x was free()d.
When I write code in C, the spec states what happens. Ok, that's predict. But - guess what? - the same applies to Java.OK, give me an example of undefined behaviour. I'd be happy for it.
If nothing else, Java is MORE predictable than C because there is less *undefined behavior*(which C has plenty).
So, I said it and I'll say it again - as a language, C is great for low-level tasks. For high-level tasks, it is basically the same as Brainfuck(where everything is technically possible, just like in C).Have you actually written in brainfuck? I'd like to see you create a window with it.
You're complaining that Java/C# are too high-level when it's their greatest advantage. This is not 1970 anymore. Most tasks no longer require such low-level tools.I don't care that it's not 1970 any more. Have you noticed that as hardware gets faster, software is staying the same? Ever wondered why? It's because of that mindset, "The technology nowadays can take it, I can afford a little slack".
You can theoretically dig a 100km-wide hole, but nobody does it. The right tools for the right job. Possibility is irrelevant. What matters is viability.
EDIT: Just found this gem in Wikipedia:I was complaining against the applications themselves.QuoteNgen pre-compiles (or "pre-jits") bytecode in a Common Intermediate Language image into machine native code. As a result, no runtime compilation is needed. .NET framework 2.0 shipped with Visual Studio 2005 runs Ngen on all of the Microsoft library DLLs right after the installation.So it appears that even your beloved .NET DLLs are compiled. Worse - they combine the optimization advantages of JIT with the minimum startup delay of AOT!
Also, I checked my .NET DLLs in Olly and most of it is still .NET, not native.
There was a time where people said C was too slow that it was unusable.(asm programmers)C programs generate about the same amount of instructions per function as someone with about average skills in ASM. It's because of that amazing thing called the "optimizer". Optimizers have been evolving, they haven't remained the same throughout the time. In fact, GCC's -O3 option is great at optimization. You should try it sometime.
[For the record, I do program in ASM too]
60
Off-Topic / Re: The grand c++ vs everyone else debate
« on: April 06, 2010, 09:38:17 am »C#/Java: Rarely interpreted. Usually compiled.Excuse me for being a little ignorant on the subject, but every time I've seen something written in Java, it's been a ".class" file, and every time I see something written in C#, it has a CLR header (containing the CIL bytecode to the entire program) and a dependency on the .NET-interpreting DLLs.
C++ is much LESS predictable than Java/C#. Undefined behavior is EVERYWHERE. Weird interactions occur. Stuff like buffer overflows make code pretty much impossible to predict.C is predictable to me.
Java pretty much FORCES code to be predictable.
Your idea of predictable is "do what I mean", and mine is "do what I say". If I want a program to be able to write 500 bytes to a 400-byte-long buffer, then I will do that. If I don't, I'll put the necessary checks in place.
(Saying that, MSVC++ usually puts a check in place to make sure that a program will "abnormally terminate" instead of returning from a function if it sees the the return address has been smashed - it pads the return address with a few encrypted values to verify that nothing has overwritten it).
Also, nobody [in their right mind] uses gets(). At all. They might as well rename it crashme().
In other words, C++ is a low-level language, where everything is possible but nothing is simple. C/C++ are BRILLIANT languages for low-level programming.I do have rather a thing for low-level programming.
Java is a high-level language, where low-level things are more complex(and therefore hardly worth the effort to replace C), but things that were insane in C are very easy to handle in Java.Actually, low-level tasks are completely impossible in Java, but high-level tasks are just difficult in C. Tried writing an OS kernel in Java? Not possible. In C, it's just difficult.
Low-level tasks -> Low-level language(C)
High-level tasks -> High-level language(Java/C#)