ENIGMA Forums

General fluff => Off-Topic => Topic started by: RetroX on May 18, 2010, 03:55:06 PM

Title: c++0x
Post by: RetroX on May 18, 2010, 03:55:06 PM
I should have looked the standards up ages ago

This is wonderful

idgaf if it doesn't work in VC++, but it works with G++
Title: Re: c++0x
Post by: luiscubal on May 18, 2010, 04:13:26 PM
VC++ 2010 has partial support for C++0x(auto, for example)

Main new features:
In vectors, >> is now correctly identified as close template arguments twice as expected(and when not ambiguous);
Code: [Select]
vector<vector<int>>
//vs
vector<vector<int> >

Type inference:
Code: [Select]
for(auto i = vect.begin(); i < vect.end(); ++i)
//vs
for(vector<vector<vector<Xyz>::iterator>::iterator>::iterator i = vect.begin(); i < vect.end(); ++i)

Basic UTF-8/UTF-16/UTF-32 support

Lambda

It has a couple extra stuff, but what I mentioned above is the most noticeable of it.
C++0x was also meant to include something named "concepts", which I'm not quite sure what it means, but it was postponed.
Title: Re: c++0x
Post by: RetroX on May 18, 2010, 04:20:56 PM
Basically that, yeah.

It also had a pseudo-foreach:
Code: [Select]
int x[5];
for (int &i : x) { std::cout << x[i] << " "; }

and a pseudo-typeof:
Code: [Select]
int x;
decltype(x) y;
Title: Re: c++0x
Post by: Josh @ Dreamland on May 18, 2010, 05:35:40 PM
GCC's had and whored most of those for a while now.
It's not like template<> wasn't already ambiguous in some cases.
Fortunately, I believe lambda is the only exception to this not being a problem. I believe they introduced a couple more syntax quirks that I was going to add to ENIGMA anyway... I imagine it will all blow over well.
They've had typeof for a while. __typeof, it was. I just defined it as int for ENIGMA, because expression types don't really matter to my parser, as they are all just abstract names to it. I may need to fix that as they start pulling shit like typeof(something awful) :: some_member... Hopefully that never really happens, or by the time it does, a project I've had my eye on that can tell GCC to export XML reaches fruition.
Or becomes unnecessary as GCC decides to implement an alternative, which is even less likely.
Title: Re: c++0x
Post by: RetroX on May 18, 2010, 06:21:15 PM
I had to include it along with cstdint, so, I just got into the habit of including -std=c++0x on compile.  I never looked into it, though. :/
Title: Re: c++0x
Post by: Rusky on May 18, 2010, 06:45:54 PM
C++0x is "let's take this really complicated language with lots of weird details and add more weird details along with any possible good ideas we can mangle." Seriously, "decltype" and "nullptr" as keywords? Ah well, they can't do too much more damage and we get closures!
Title: Re: c++0x
Post by: RetroX on May 18, 2010, 06:58:39 PM
That is, implying that C++ is an incredibly complicated language.
Title: Re: c++0x
Post by: Rusky on May 18, 2010, 07:26:50 PM
Which it is, unless you're blind.
Title: Re: c++0x
Post by: RetroX on May 18, 2010, 07:31:04 PM
Which it is, unless you're blind.
I seem to have pretty good eye sight, and it looks quite simple to me.
Title: Re: c++0x
Post by: Josh @ Dreamland on May 18, 2010, 07:48:14 PM
C++: It is easier when you are blind


:troll:
Title: Re: c++0x
Post by: Rusky on May 18, 2010, 08:03:30 PM
You don't need to understand all of C++ to use it, which is why it's usable. But the whole thing is far more complicated than most other languages. I'm not saying C++ is needlessly complicated, just that it's complicated.

Compare the K&R book to Stroustrup's C++ book. The C++ one is several times longer. Look at C++ FAQ Lite (http://www.parashift.com/c++-faq-lite/)- with that many non-trivial language questions, there's obviously some complication going on. References v pointers, virtual destructors, the comma operator (O_o), bla bla bla. Then look at some of the things the C++0x committee feels (or felt) are necessary- rvalue references, "uniform" initialization, new return type syntax, the delete keyword and concepts/axioms.

It's complicated.
Title: Re: c++0x
Post by: RetroX on May 18, 2010, 08:14:41 PM
POINTING to MEMORY!?!?!?

I don't get it.


Yes, there's a few *somewhat* complicated things in C++, but it's not nearly as bad as you make it out to be.  It's not that hard to learn.
Title: Re: c++0x
Post by: Micah on May 19, 2010, 08:48:52 AM
In comparison with Lisp, or Ruby, or Python, or Lua, or Go, or many other languages, yes, it is that hard to learn.
Title: Re: c++0x
Post by: luiscubal on May 19, 2010, 10:02:03 AM
Complication means that any "half-decent" C++ specification is several hundreds(thousands?) pages long.
You don't know C++. You know a very small subset of C++. For instance, digraphs and trigraphs. Are those trivial? No. They may be simple, but they are an unusual detail of the language.
Don't say they are useless and nobody uses them. That's kind of the point. C++ includes lots of useless things(which might have been useful some time in the past) nobody uses anymore.
Compare C++ to Java. You may hate Java, you may hate garbage collection, but if you were to compare a complete C++ language spec with a complete Java language spec, you'd see Java spec is smaller.

Also, in defense of nullptr, the problem is:

Code: [Select]
void f(int x);
void f(void* x);

...
f(NULL); //Will call f(int)
f(nullptr); //Will call f(void*)
Title: Re: c++0x
Post by: Rusky on May 19, 2010, 12:26:02 PM
Retro: References and pointers. Two ways to point to memory. Yes, they're both useful. No, they're not simple. Learning to use C++ isn't that hard, I agree. But understanding all of its little details so you never run into weird situations is extremely difficult.

luiscubal: NULL should never have existed that way in the first place, and it's all caps. nullptr could easily be null without causing problems with NULL. It's stupid to call it nullptr no matter how it came to be that way. Besides, that's the point.
Title: Re: c++0x
Post by: MahFreenAmeh on June 02, 2010, 08:01:19 PM
Retro: References and pointers. Two ways to point to memory. Yes, they're both useful. No, they're not simple. Learning to use C++ isn't that hard, I agree. But understanding all of its little details so you never run into weird situations is extremely difficult.

luiscubal: NULL should never have existed that way in the first place, and it's all caps. nullptr could easily be null without causing problems with NULL. It's stupid to call it nullptr no matter how it came to be that way. Besides, that's the point.

hi my name is NULL and i am a macro

 :troll:
Title: Re: c++0x
Post by: RetroX on June 02, 2010, 08:12:57 PM
Yes, they're both useful. No, they're not simple.
What's not simple about them?  The pointer is where the variable is in memory.  The reference is that variable, not its value.  Yeah, there are a few operators to convert between them that don't make much sense, but you can still learn what they do.
Title: Re: c++0x
Post by: luiscubal on June 03, 2010, 05:46:36 AM
Compare it to Java, where stuff just magically goes around and people getting started don't even think about what's a pointer.

Is it stupid to be like this? Maybe. Will they risk getting trouble later due to incorrect assumptions? Maybe.
However, it IS simple.

So in Java: There are objects which are passed around.
In C++: There are objects which can be referenced, copied or accessed through their memory address.

Maybe you like C++ better than Java, but it is indeed more complex.

And pointers aren't the worse part of C++. You can code in C++ for a long time and still miss important details. C++ is easily one of the most bloated programming languages ever(C is not, though).
Title: Re: c++0x
Post by: RetroX on June 03, 2010, 02:39:00 PM
C++ can be used exactly like Java.  Object can be used to access any type, which can be coded in C.  It's just that C doesn't force you to use it.  Same thing with length and jagged arrays and other random, useless features that Java has.  You can do them in C++, but they're not forced.

How is C++ bloated?  It's "more bloated" than C, yes, but Java is far more bloated than either.  I don't quite understand your logic, here.

"Bloated" would mean "has more features than reasonable" in my opinion, and as far as Java goes, a lot more features are default than necessary.  Yes, it has several extra, useful functions that aren't in the C++ standard libraries, but the default functions that Java automatically uses are way too much.
Title: Re: c++0x
Post by: luiscubal on June 03, 2010, 03:37:55 PM
It's not a matter of what you use. It's a matter of what it has.
Sure, I might avoid pointers in C++, but C++ has pointers. Pointers are part of C++ obesity.
I might avoid trigraphs in C++, but C++ has trigraphs. Trigraphs are part of C++ obesity.
I might avoid friend classes and functions in C++, but C++ has friend classes and functions. Friend classes and functions are part of C++ obesity.

C++ has grown too big. Layers on top of layers on top of layers on top of layers, for the sake of legacy. C++'s age is noticeable, even more so because it kept so much from old C.

Sorry to say this, but C++ has become obsolete. Is it worse than C? I'm not sure. It has decent features C hasn't, but does all the crap it adds worth it?

And it's a shame. Because we could really use a low-level programming language with a few high-level features. But almost nobody cares. C++ is mostly for legacy. Languages like D never became "the next big thing", because programmers meanwhile discovered better alternatives such as GC-able/JIT languages(that, and the fact that D libraries suck).
Title: Re: c++0x
Post by: RetroX on June 03, 2010, 03:59:17 PM
Java has loads of extra stuff, too.

I don't understand why having the ability to do stuff is worse than having too much that is forcibly included.

In C++, I can code terribly and make a class for every group of functions, but it's not forced.  In Java, you're forced to.

In C++, I can create a base object class that all other classes inherit, but I don't have to.  In Java, it's done automatically, whether or not that you need it.
Title: Re: c++0x
Post by: luiscubal on June 03, 2010, 04:14:27 PM
The "extra stuff" of Java is less than the "extra stuff" of C++. Although that gets a little ambiguous if you count the API.

Grouping functions in classes isn't bad. It's organized. If anything, it solves C++'s problem of having no decent auto-completion.
C++'s lack of basic "forced stuff" means it's horribly inconsistent.

But we weren't talking about C++'s inconsistencies and brain damages. We were talking about how bloated it is.
Title: Re: c++0x
Post by: RetroX on June 03, 2010, 04:20:51 PM
It seems unlikely that you'll change your opinion, so, I'll stop arguing with you.

You're still wrong, though.
Title: Re: c++0x
Post by: retep998 on June 03, 2010, 04:23:57 PM
"C++ is designed to give the programmer  choice, even if this makes it possible for the programmer to choose incorrectly" -Wikipedia
"C++ does not incur overhead for features that are not used (the "zero-overhead principle")" -Wikipedia

C++ is great because it lets you do anything you want, while at the same time not slowing your game down with extra stuff you don't want. If you don't use something, it's as if it never existed.
Sure the bloat can be a bit of a burden for someone learning c++, but it's also a burden having to learn all the many languages and their programming styles which c++ easily covers.
C++ puts everything together, while giving YOU the choice of what you want to do.
If you don't like c++, then don't use it.
I think it's quite obvious that the c++ supporters here aren't going to change their mind, so there's not much point arguing.
Title: Re: c++0x
Post by: RetroX on June 03, 2010, 04:32:12 PM
And of course, I'm one of the worst ones to argue those kinds of points.

Thanks, retep.
Title: Re: c++0x
Post by: luiscubal on June 03, 2010, 05:23:56 PM
I have no doubt that if we could just forget legacy and design C++ from the bottom up, we could come up with something really good.
Unfortunately, C++ is not that language.

Even though I don't think C++'s feature set is needed for the vast majority of applications, one can actually see how it can be useful. But just not C++. C++ has so much legacy that adding anything to the language is painful.

Also, C++ isn't infinitively extensible. At some point, it's better to just design a C++-made VM and use something else. Garbage collection(yes, it is useful) is notably bad in C++. Although I heard they intend to add it to a later version, I just don't see any way to add it nicely.
Title: Re: c++0x
Post by: RetroX on June 03, 2010, 06:26:23 PM
Again, I'm no longer arguing with you.  You can't make a valid argument.
Title: Re: c++0x
Post by: Rusky on June 03, 2010, 08:52:09 PM
"C++ is designed to give the programmer  choice, even if this makes it possible for the programmer to choose incorrectly" -Wikipedia
"C++ does not incur overhead for features that are not used (the "zero-overhead principle")" -Wikipedia

C++ is great because it lets you do anything you want, while at the same time not slowing your game down with extra stuff you don't want. If you don't use something, it's as if it never existed.
Sure the bloat can be a bit of a burden for someone learning c++, but it's also a burden having to learn all the many languages and their programming styles which c++ easily covers.
C++ puts everything together, while giving YOU the choice of what you want to do.
If you don't like c++, then don't use it.
I think it's quite obvious that the c++ supporters here aren't going to change their mind, so there's not much point arguing.
These ideas are completely orthogonal to being bloated.
Bloat is a problem for everyone- you can't just ignore features others use.
Nobody's arguing against C++ anyway. Just that it's bloated.

We all use Windows at some point or another- I'm fairly sure everyone here agrees that while it runs nearly everything you want in some form or another, it's got a lot of stuff you don't want and a lot of stuff that's designed stupidly. It's the same with a lot of useful systems- nothing is perfect, and bloat is a pretty popular problem to have.
Title: Re: c++0x
Post by: Josh @ Dreamland on June 03, 2010, 09:04:16 PM
As a language, C++ is fairly bloated. That bloat doesn't really get in your way unless you are trying to parse it. The output is typically far from bloated, though there are slight amounts of overhead if you utilize more than C would give you alone.
Title: Re: c++0x
Post by: retep998 on June 03, 2010, 09:29:26 PM
There IS a way to add GC to C++.
Just create a special smart pointer class, and have a bunch of methods so they keep track of their memory and stuff.
This way you can just #include the smart pointer stuff when you want to use it, and when you don't want to you can just use normal pointers. You can even mix them in the same line of code.
This is the beauty of C++, you can do anything you want.
Title: Re: c++0x
Post by: luiscubal on June 04, 2010, 11:19:47 AM
Yes, I know. I have created a reference counter for my C++ code.
But the fact is, GCs for C++ will always have less quality than GCs of languages specifically designed to use GC.

Also, you can do anything you want in Brainfuck.

Finally, don't call somebody arguments invalid just because you're too closed-minded to understand them. Is this a fallacy? Not any more than your arguments, so you can't complain.
Title: Re: c++0x
Post by: Rusky on June 04, 2010, 11:34:11 AM
There IS a way to add GC to C++.
Just create a special smart pointer class, and have a bunch of methods so they keep track of their memory and stuff.
This way you can just #include the smart pointer stuff when you want to use it, and when you don't want to you can just use normal pointers. You can even mix them in the same line of code.
This is the beauty of C++, you can do anything you want.
You can make a reference-counting GC for C++. You can make an inaccurate GC for C++. What you cannot do without language and/or compiler modifications is a GC that takes advantage of the techniques that make GC just as good as manual memory management. Those techniques require that you know what is a pointer and what is not, and that is impossible in C++. The reverse of this problem is not true for other languages- it is possible to have a memory-safe language with manual memory management, but not a memory-unsafe language with accurate GC.
Title: Re: c++0x
Post by: Josh @ Dreamland on June 04, 2010, 12:58:43 PM
"Is this a fallacy? Not any more than your arguments, so you can't complain."
That final clause itself was a fallacy. You're both spouting little but fallacies.

"know what is a pointer and what is not, and that is impossible in C++."
I'm going to assume you meant something other than how that reads; otherwise, that's the biggest lout of bullshit I've ever heard.

Anyway, C++ is not meant to be a garbage collected language. It implements something wonderful over C in the direction of memory management, being constructors and destructors. Google V8 is one to really whore that system. In an ExecuteString wrapper, I can say so little as
Code: (C) [Select]
{
  v8::HandleScope handle_scope; // Constructor allocates and integrates a new scope
  ExecuteString(String::New(line), "(shell)", true, true); //Operates in the newly constructed scope
  return 0;
} // Destructor automatically disposes the new scope

People get used to strings; I myself have become spoiled by them, and feel so every time I use them. C gave no way of returning new strings, save allocating them yourself. With C++, std::string is a great example of how the annoying bits are handled for you. String keeps its own reference count at the beginning of the char* in memory. When you return a string in C++, the constructor of the new string increments that count, the destructor of the old string then decrements it, and a string is returned with no manual allocation.

I had a leak once, and I used ctors and dtors to keep my own count, and to help me isolate where they were allocated that they weren't being freed. It was greatly convenient; had I wanted, I could have turned it into a garbage collector on my own. Thing is, I prefer the program to be geared correctly to take care of such itself.

Is it possible to get C++ to wipe all the memory management ickiness off your ass for you? No. What I think Rusky was trying to convey is that C++ introduces no system of reference tracking. Personally, all considered, I prefer it that way.
Title: Re: c++0x
Post by: luiscubal on June 04, 2010, 01:43:17 PM
Quote
know what is a pointer and what is not, and that is impossible in C++.
You disagree with this, Josh?
Tell me, how many variables are pointing to 0x043030FE in your program. You can't ever be sure in C++. In Java, you can.
So you're left with few options:
1. You use something like Pointer<T> instead of T*. It's ugly, you still need to figure out circular references(which somehow means you need the stack trace too, yet another problem C++ makes hard to solve). You can of course just have a simple reference counter and somehow hope nobody messes around with it. Possible and I've used this method (http://code.google.com/p/pinedl/source/browse/pinevm/headers/pinevm/reference.h) before. Still, templates mean worse compile times, harder-to-read code, and it's still unable to deal with cyclic references.
2. You iterate through the whole memory and build a conservative memory collector. Less painful to handle since you can use ordinary pointers, but it's still vulnerable to circular references and it can't be sure whether something is a pointer or something else. Say, if an integer has value 0x043030FE for some unrelated reason, a leak occurs.
3. You use macros or something else to register the stack.
Code: [Select]
void myfunction(StackPosition& pos) {
  pos.push();

  Pointer<int> p(pos, new int(5));

  pos.pop(); //p is released here
}
that plus several more tricks could possibly solve, but it's simply pain ugly and makes code readability worse.
4. You use something like a C++ preprocessor to automatically generate solution 3 in a pretty way. At this point, you can barely call it C++.

Destructors are useful, and garbage collectors could be built to take advantage of them. However, while destructors can simplify some memory management, they aren't enough by themselves to replace GCs.

Quote
People get used to strings; I myself have become spoiled by them, and feel so every time I use them. C gave no way of returning new strings, save allocating them yourself. With C++, std::string is a great example of how the annoying bits are handled for you. String keeps its own reference count at the beginning of the char* in memory. When you return a string in C++, the constructor of the new string increments that count, the destructor of the old string then decrements it, and a string is returned with no manual allocation.
Shame on them. They dared to automatically dispose of strings in C++? BUT THAT'S SO INEFFICIENT!!!
That aside, strings in C++ are often much better than const char*s, for similar reasons that GCs are often much better than manual memory freeing system.

Quote
Is it possible to get C++ to wipe all the memory management ickiness off your ass for you? No.
Therefore, when it comes to wiping out the memory management ickiness, other languages are better.

Quote
Personally, all considered, I prefer it that way.
For some use-cases, that indeed is the best way.
For most applications, memory management is not the problem we're trying to solve. We're trying to render a document, to figure out what 3D position the 2D mouse click refers to in the computer game or what GM version the read file refers to. In those cases, memory management is an obstacle.

Either way, regarding bloatness, a quote from one of Go's designers:
Quote
it wasn't enough to just add features to existing programming languages, because sometimes you can get more in the long run by taking things away.
Title: Re: c++0x
Post by: Josh @ Dreamland on June 04, 2010, 03:04:59 PM
"Tell me, how many variables are pointing to 0x043030FE in your program"
"What I think Rusky was trying to convey is that C++ introduces no system of reference tracking."

"They dared to automatically dispose of strings in C++? BUT THAT'S SO INEFFICIENT!!!"
How so? The idea is a garbage collector that can linearly assume you are done with it because the entire scope's life is ending. My argument was never that all convenient things are inefficient; it's if you start periodically iterating through everything to make sure nothing's just kind of waiting there that shit becomes inefficient.

"Therefore, when it comes to wiping out the memory management ickiness, other languages are better."
...Okay. For the most part, this has worked for a few large projects. You'll probably notice that the more the language does for you, the less large projects are successfully written in it. Openoffice is a shining example, in my opinion. Only a few of its aspects have been reported as being slow (the one I am thinking of is Calc, being 12x slower than Excel at something or another). I look at Haskell, and I see things like Geordi. Marvelous little toy; not ultimately very big.

Ultimately, it's a nice thing to have a low-written runtime at your disposal in a high level language; it gets you the speed of the low with the simplicity of the high. The more things the low level system does for you, the better off you'll be. Like GM. Sprites and collisions are acceptable because something coded in a real (not GML) language handles them. Java has a few aspects of it that are "faster than C"... usually large libraries such as compression that are written in a lower level language.

If you want anything sizable that runs fast, you'll need something lower level at some point, even on our constantly improving hardware. Haven't heard anything on Singularity. But I know that the more Microsoft develops, the slower their output becomes. It is nice to swim in the high level end and have simpler-to-read code with the ugly parts handled. Microsoft's been trying that for a long time. It isn't always an option. C++ is always an option.

Maybe some day, Microsoft will fix that. C++ being an option, I mean. In the meantime, it's a true dilemma between whether you want your time to be consumed in development by your team or in execution by all users. And since programmers get paid by the hour, not by the output...

Either way, the majority of these posts is fluff. Every language has its purposes; I wouldn't want Geordi written in anything other than Haskell, because Haskell got the job done far faster and probably far more cleanly than C++ would have. It simply doesn't need that speed. I would kind of like OpenOffice to not be Java, because Java acts up on this machine sometimes, but whatever; it's free. I wouldn't have ENIGMA coded in any other way.
Title: Re: c++0x
Post by: luiscubal on June 04, 2010, 03:59:16 PM
String reference counting is a type of garbage collection. So I guess that means C++ STL does have GC. Too bad it's so limited.

Quote
You'll probably notice that the more the language does for you, the less large projects are successfully written in it.
Are you seriously suggesting that languages such as C# are unable to deliver?

Quote
Either way, the majority of these posts is fluff. Every language has its purposes; I wouldn't want Geordi written in anything other than Haskell, because Haskell got the job done far faster and probably far more cleanly than C++ would have. It simply doesn't need that speed.
Glad you will admit that.

Quote
Maybe some day, Microsoft will fix that.
False dichotomy. If it is efficiency you want with some minimal high-level tools, then why are efforts such as D so rare and why have they all failed to get any success?
The number 1 reason C++ is so widely used is legacy.
Had Excel started been developed today, would its team still pick C?

Quote
If you want anything sizable that runs fast, you'll need something lower level at some point
Which is why we have P/Invokes, JNIs and optimizers.
Eventually, something will be written in C(the kernel, perhaps?). Heck, there are things that should really be written in C(or at least have a public C ABI), such as system libraries. However, this does not apply to applications.
The "go fast or go high level" is another false dichotomy fallacy.

Quote
And since programmers get paid by the hour
Then you should pick the most productive tool, which is definitively not C++.

Quote
I wouldn't have ENIGMA coded in any other way.
Will you at least admit C++ has lots of legacy junk nobody needs anymore? Because that's what this discussion was about - the claim that C++ was bloated.
Title: Re: c++0x
Post by: Rusky on June 04, 2010, 05:01:25 PM
"know what is a pointer and what is not, and that is impossible in C++."
I'm going to assume you meant something other than how that reads; otherwise, that's the biggest lout of bullshit I've ever heard.
From the point of view of a GC, you don't know if some word in memory is an integer or a pointer cast to an integer. If casting between pointers and integers were impossible, you could place GC roots at compile time; as it is you can't.

Is it possible to get C++ to wipe all the memory management ickiness off your ass for you? No. What I think Rusky was trying to convey is that C++ introduces no system of reference tracking. Personally, all considered, I prefer it that way.
Reference counting is not good enough in many cases. You can implement it yourself fairly easily in C++ anyway.

How so? The idea is a garbage collector that can linearly assume you are done with it because the entire scope's life is ending. My argument was never that all convenient things are inefficient; it's if you start periodically iterating through everything to make sure nothing's just kind of waiting there that shit becomes inefficient.
GC has come a long way from stop-the-world collectors. And as I've said before, it mostly just moves the processing required. Allocation in a GC system is just incrementing a pointer; in your favorite manual systems it is much more than that.

...Okay. For the most part, this has worked for a few large projects. You'll probably notice that the more the language does for you, the less large projects are successfully written in it. Openoffice is a shining example, in my opinion. Only a few of its aspects have been reported as being slow (the one I am thinking of is Calc, being 12x slower than Excel at something or another). I look at Haskell, and I see things like Geordi. Marvelous little toy; not ultimately very big.
Haskell has Darcs and Yi. It has GHC and Cabal. It has Xmonad and seL4 and House. It has compilers for Perl 6, Lisp, bla bla bla look at Hackage. Do some research before making things up.
Title: Re: c++0x
Post by: Josh @ Dreamland on June 04, 2010, 09:51:22 PM
"Will you at least admit C++ has lots of legacy junk nobody needs anymore? Because that's what this discussion was about - the claim that C++ was bloated."
Do you read what I write?
"As a language, C++ is fairly bloated. That bloat doesn't really get in your way unless you are trying to parse it. The output is typically far from bloated, though there are slight amounts of overhead if you utilize more than C would give you alone."

"From the point of view of a GC, you don't know if some word in memory is an integer or a pointer cast to an integer. If casting between pointers and integers were impossible, you could place GC roots at compile time; as it is you can't."
From the point of view of Escherichia coli, your garbage collector is indistinguishable from a string of bits in memory. :troll:
Now, when you're done raging over the bluntness of that statement, consider its implications. ISO C++ forbids void* arithmetic, it forbids implicit casts between pointers of non-inherited types, and it forbids implicit cast from pointer to integer. The question isn't of whether a separate garbage collector can be slapped on to the output of any old C++ program; that kind of thinking leads to output bloat instead of C85 language bloat that can be ignored.

Also, you can't pretend that a garbage collector alleviates all allocation problems. Specialized ones, knowing the size of everything up front, can be used to alleviate allocation headaches and just increment a pointer. There's nothing a garbage collector can accomplish that manual can't if given equal thought. Garbage collection has come a long way, and it's typically not an O(N) clusterfuck anymore. That doesn't mean that they are programmed with magic that fixes all our resource problems.

"Haskell has Darcs and Yi. It has GHC and Cabal. It has Xmonad and seL4 and House. It has compilers for Perl 6, Lisp, bla bla bla look at Hackage. Do some research before making things up."
I don't see any of those as being exceptionally large... Looking at Xmonad, it's built off of X, which only serves to help my point. The rest are little things like RapidSVN that I kind of take for granted because really, they're just nice wrappers to what I'd otherwise be doing in a terminal.

Also, I can be missing a huge, huge project made in Haskell without "making things up." I'm reporting my findings. I indicated what would "probably [be] notice[d]," based off of my findings. Quit accusing me of making things up simply because you disagree with my point.

"Eventually, something will be written in C(the kernel, perhaps?). Heck, there are things that should really be written in C(or at least have a public C ABI), such as system libraries. However, this does not apply to applications."
I hinted earlier at Microsoft Singularity. I'm glad you agree that there are some things that just had ought to be C. Much of Singularity is C,  but the rest is C#. There are benefits to having garbage collection in some of the system resources that applications will be accessing. I think, however, you'll agree that Singularity oversteps the boundaries. If not, maybe you'll agree that integrated circuitry designed to implement a garbage collector is. (Or, hell, maybe you'll think it's a great idea, who the hell knows). I was reading about ATMs that have their own integrated garbage collector. I wanted to puke, personally.

"The "go fast or go high level" is another false dichotomy fallacy."
I wasn't citing that as a mathematical truth. There are a lot of brilliantly efficient high level things.
Title: Re: c++0x
Post by: score_under on June 05, 2010, 06:55:45 AM
Also, you can do anything you want in Brainfuck.
Try opening a file.
Title: Re: c++0x
Post by: luiscubal on June 05, 2010, 07:15:19 AM
Quote
As a language, C++ is fairly bloated. That bloat doesn't really get in your way unless you are trying to parse it. The output is typically far from bloated, though there are slight amounts of overhead if you utilize more than C would give you alone.
The first sentence is pretty good. The bloat doesn't usually get in the way but it exists. Also, that same bloat can get in the way of adding new features to C++.

When a language has too many things in it, optimizing becomes problematic. Just look at the restrict keyword. Usually, adding features harms writing optimizers, and then you have to add yet more features to opt-out of features you don't need.

Quote
"Eventually, something will be written in C(the kernel, perhaps?). Heck, there are things that should really be written in C(or at least have a public C ABI), such as system libraries. However, this does not apply to applications."
Please note that in this sentence, I was specifically referring to C, not C++. C++ ABI is stupid.

Quote
integrated circuitry designed to implement a garbage collector
I would need to see how it was being implemented, how efficient it was, what it lacked, if it was opt-in or opt-out, etc. etc. before jumping to conclusions.
Then again, different GCs often have different purposes. Some GCs are designed to be fast, others to be small, others to be simple, others are specifically designed for code locality. GCs are a fertile investigation field, and I'm not sure an integrated circuit would be the best way to implement GCs simply because GCs change and then we'd be stuck with an outdated one.

Your claim is that only C++ is used for big applications for reasons such as efficiency, power, or something like that. My claim is that C++ is used for big applications because when those big applications were started there was nothing better or because they were started as C.

Quote
Try opening a file.
Ok. I can just add a few extra commands to Brainfuck. Say, ' to open file to write, " to open file to read, « to read from file and » to write to file.
Would this somehow convince you to use Brainfuck?
Title: Re: c++0x
Post by: retep998 on June 05, 2010, 09:08:29 AM
Quote
Try opening a file.
Ok. I can just add a few extra commands to Brainfuck. Say, ' to open file to write, " to open file to read, « to read from file and » to write to file.
Would this somehow convince you to use Brainfuck?
Oh no!
You just made Brainfuck bloated!
Title: Re: c++0x
Post by: Josh @ Dreamland on June 05, 2010, 09:21:04 AM
"Also, that same bloat can get in the way of adding new features to C++."
Care to give an example? Lately it shouldn't appear the committees are having any trouble introducing new features to the language.

"My claim is that C++ is used for big applications because when those big applications were started there was nothing better or because they were started as C."
That almost definitely applies to Excel, because otherwise, Microsoft would have taken the opportunity to advertise that srs biznez can really be accomplished in C#. And that IS part of their intention. Singularity's one screen shot was so transparently propaganda-laden it made me sick.

Loading ************C#*********** kernel of Mar 25 2008
Please direct your attention to the C# in the last message
Did you notice the kernel is C#? Look, it even loads amicoolyet
Singularity>

Of course, C# is my least favorite example of such languages, and there are far better ways of accomplishing type safety that don't end up removing mad pointer tricks as a method of accomplishing something.

As for this little Brainfuck argument, Luis is going to argue it in the wrong direction. Brainfuck could be a really nice language with the right tools. For example, you could give it a DLL containing wrappers to the standard C library. " would be LoadLibrary, ' would be GetProcAddress, » would push an argument, « would call the function with the pushed arguments and store the return value.
Because the code would be so horribly redundant (having to load a new proc address every time you want to call a function), an optimizer could boil the code down to nothing. It might even be faster than C++. :O
...Until you need to pass arguments that aren't strings.
Title: Re: c++0x
Post by: luiscubal on June 05, 2010, 02:03:34 PM
Quote
"Also, that same bloat can get in the way of adding new features to C++."
Care to give an example? Lately it shouldn't appear the committees are having any trouble introducing new features to the language.
Well, judging by the horrible ugly syntax of lambdas in C++0x, it would appear they don't have many options without introducing syntactical ambiguity.

Quote
Singularity's one screen shot was so transparently propaganda-laden it made me sick.
Well, Singularity's core innovation was being in pseudo-C#(I think it's not exactly C#, but I can't remember), so obviously there wasn't much impressive about it aside from that fact and, therefore, being written in C# was probably the only notable detail about Singularity.

Quote
Of course, C# is my least favorite example of such languages, and there are far better ways of accomplishing type safety that don't end up removing mad pointer tricks as a method of accomplishing something.
That could be the root of our disagreements. C# is my favorite language(although I notably hate C# APIs).
BTW, C# has pointers. Both IntPtr(a nice safe way to deal with them) and ordinary *& C syntax. The first way is often used with P/Invokes. The second way requires the "unsafe" keyword to be used since, well, it's unsafe. I never needed to use the second syntax. The first syntax I only used for P/Invokes.

Quote
...Until you need to pass arguments that aren't strings.
Well, Brainfuck has integers. It can represent any type C can. It can represent pointers(in fact, Brainfuck is designed on the concept of pointers), it can represent integers, floating point(see IEEE 754 for how to represent float in integers), it can represent characters and, with that, it can represent strings, structs and unions. So, basically, Brainfuck(with those few command extensions) could do anything.
Title: Re: c++0x
Post by: Rusky on June 05, 2010, 02:49:58 PM
Now, when you're done raging over the bluntness of that statement, consider its implications. ISO C++ forbids void* arithmetic, it forbids implicit casts between pointers of non-inherited types, and it forbids implicit cast from pointer to integer. The question isn't of whether a separate garbage collector can be slapped on to the output of any old C++ program; that kind of thinking leads to output bloat instead of C85 language bloat that can be ignored.
The problem is not solved by ISO C++. You can still say SomeObject* foo = (SomeObject*)0x0BADF00D.

Also, you can't pretend that a garbage collector alleviates all allocation problems. Specialized ones, knowing the size of everything up front, can be used to alleviate allocation headaches and just increment a pointer. There's nothing a garbage collector can accomplish that manual can't if given equal thought. Garbage collection has come a long way, and it's typically not an O(N) clusterfuck anymore. That doesn't mean that they are programmed with magic that fixes all our resource problems.
Garbage collectors alleviate allocation headaches, which is more than enough for a lot of uses. The rest is just to show you that GC is fine for other uses as well. It improves memory locality (and thus cache usage), makes code more readable (which further helps productivity) and makes new techniques feasible (sane closures, etc.).

I don't see any of those as being exceptionally large... Looking at Xmonad, it's built off of X, which only serves to help my point. The rest are little things like RapidSVN that I kind of take for granted because really, they're just nice wrappers to what I'd otherwise be doing in a terminal.

Also, I can be missing a huge, huge project made in Haskell without "making things up." I'm reporting my findings. I indicated what would "probably [be] notice[d]," based off of my findings. Quit accusing me of making things up simply because you disagree with my point.
You still haven't done your research.
Darcs is a full, distrubted version-control system- not a wrapper.
Yi is a full text editor which improves on Vim and Emacs.
GHC is a full, bootstrapping, optimizing, production-quality Haskell compiler.
Cabal is a full package manager, with a better interface than apt-get.
Xmonad is built on X the same way Gnome and KDE are, and it shows that Haskell is fine at interop.
seL4's prototype was implemented in Haskell to prove it's behavior.
You can write large systems just fine in languages even as high-level as Haskell.

Care to give an example? Lately it shouldn't appear the committees are having any trouble introducing new features to the language.
Half of C99 got ignored. They ignored GC support (not built-in GC, nobody wants that in C++). They mostly added pointless things that could have been solved much better by removing or fixing something else.