switch to room list switch to menu My folders
Go to page: First ... 17 18 19 20 [21] 22 23 24 25 ... Last
[#] Wed Jan 21 2009 22:16:43 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I've tried to mostly avoid showing him how to mess around with templates, as that's also kind of mind-bendy.

"It's like using the pre-processor, except it's built into the language, and much weirder."

No, boost::bind is ... well... it's seriously cool, but bizarre, especially when combined with boost::function.

I could try to give an example, I guess...

class A



  int fn( int i ) { return i + 5; };


class B



 int some_other_fn( int i ) { return i + 10; };


class C


 int some_weird_fn( boost::function< int () > fn )

 { return 12 + fn(); };


int some_weirdness( int arg )


  int result = 0;

  A a; B b; C c;

  if ( arg < 3 )


    result = c.some_weird_fn( boost::bind( &A::fn, &a, arg ) );




    result = c.some_weird_fn( boost::bind( &B::some_other_fn, &b, arg ) );


  return result;



So, if you call weirdness with a -5, result will be 12.  If you call weirdness with 12, result will be 34.

This is only the tip of the iceberg.  It helped me do some amazing stuff that, normally, I'd have to do with a pre-processor instead, since the second parameter could just as easily be some variable you acquired some other way, or the third parameter can be a placeholder  (_1, _2, _3, etc.. not sure how many placeholders you can use) so something using the function can supply the argument instead.  Totally flippin' cool, with type safety, yet tremendous flexibility. The latest Microsoft compilers have it as part of tr1 now; the thing is so useful, it made its way into the standard library package for modern C++ compilers.

[#] Thu Jan 22 2009 12:14:27 EST from Peter Pulse @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I know you were just joking about the stream thing.. but it was just a good example of something really confusing. As far as explaining aggregate types, I wouldn't even use the word "aggregate". Because that is a word that most people don't use very often.. it adds another level of confusion that is in my mind not required. When I learned C, I didn't think of structure as aggregate types.. I already had a word I was required to memorize.. "structure". That is the problem I keep finding with C++, that the whole mentality with it is snarled up in all these concepts and abstractions and explanations of why this horribly complex stuff is all worth it, really! You have to stow half a textbook worth of concepts in your head before you get anywhere near comfortable with it. I am more tool oriented, I don't need to see my code in a programming textbook.

[#] Thu Jan 22 2009 12:25:41 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Well, I get that, actually.

I know a lot of C++ developers who really don't use the full potential of the tool. They just sorta stick to writing their tools, and ignore or rail against the language's designs because, to their way of thinking, the language works well enough doing it their way.

And you know, for what a lot of people do, I suppose that's good enough.
You can still write your applications, and you can still get stuff done.

But... BUT... if you *do* learn the why behind the features... if you *do* take the time to lug that whole compendium of concepts, abstractions, and explainations around in your head... if you *do* learn how to push the language to its n-th degree, you'll be able to write some extremely powerful, flexible, elegant code.

In this way, C++ is like the English language. Most people use English well enough to get by, but a really good wordsmith can express themselves in English such that nobody mistakes what the wordsmith is saying, and can even be moved by the use of his words.

That said, sometimes you just want to get shit done.

I'm not trying to bury my young coworker with the full power of C++. As much as possible, I'm trying to limit his exposure to just the stuff he needs to do what he needs to do. It's limiting, but it's doable. But I do want him to take the time to learn the 'textbook' stuff when he feels up to it.
You can't lose in learning that stuff.

And, no, I didn't use the word 'aggregate'. I didn't come close to expressing it in that way. I tried to find another way to express the concept, using things like pictures and diagrams, since they do a better job of describing what he needs to do. He still had a rough time of it, but he seems to be getting it now. It's just harder to draw those diagrams and stuff in a BBS.

[#] Thu Jan 22 2009 12:35:44 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Wow, all this learn C++ stuff? If it's anybody's first OO project, just use Java. RTOL.

Just sayin ;)

[#] Thu Jan 22 2009 14:09:23 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Why manage your own memory, when you can leave it to the garbage collector?

[#] Thu Jan 22 2009 14:09:56 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

(I mean, since C++ is so dead anyway, why bother teaching anything about memory management?)

[#] Thu Jan 22 2009 14:26:50 EST from Peter Pulse @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

RTOL, haha. But yea, I kind of agree. Without getting into the whole C++ bashing thing again... But it comes down to the same thing every time. You have got this language with a kajillion bells and whistles.. very complex.
And when the question is asked "why do you need this, why do you need that" the answer is always "because otherwise you can't do", or "it's the principle of xyz, a very powerful programming method"... etc etc. But you look at languages like Java and Objective-C, and they don't have so much complexity, they are a lot easier to understand, a lot easier to learn. Yet people have developed amazingly complex applications with these languages. All of OS/X is Objective-C and C. No C++ to speak of. And really, I would be the first to agree that there are shortcomings to these languages. Objective-C memory management is sorely lacking. Yet fantastic applications are being written with it, many of them, in both Objective-C and Java.. and most of the code we've all used in our lives has been written in plain old C, and people loved writing in C and did not feel exceptionally constrained by it.. but a little bit constrained. Hence C++, what was supposed to be an extension to C.. but which is now a gargantuan thing that completely destroys the beauty of that which it was supposed to "improve". My take on it is that the problem with C++, and why it is so hard to learn.. is not a programming problem but an attitude problem. It's a problem with the attitude taken in the design of the language, and a problem with the attitude taken in development in the language. I just don't see the value of cluttering up programs with such complexity and more to the point conceptual density for mostly small gains in code reliability and functionality.

[#] Thu Jan 22 2009 14:29:38 EST from Peter Pulse @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Jan 22 2009 2:08pm from fleeb @uncnsrd

Less is sometimes more.

[#] Thu Jan 22 2009 15:10:58 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Well, again, you have the option to use some of C++'s more arcane features, or not. You are not forced to use tr1::bind, but it's there if you like it.
You are not forced to use templates, but they're there if you want to use them.

It isn't that much different from English in that way. You can probably say almost anything you can imagine with English. If you want to use the really fancy words, you can. Or you can limit yourself to simpler words.
Depending on what you're trying to do, one set of features in the language may work better for you than others, but you can still get the job done.

[#] Thu Jan 22 2009 15:52:51 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

C++'s arcane parts are not just a little arcane, they are *really* *fecking* *arcane.* And not only that but they keep breaking the language every time a new ISO standard edition comes out. It's a moving target, unfortunately, because they just didn't manage to do things right the first time, and it doesn't seem like they're going to be satified with what they have any time soon, either, so they're going to keep breaking source compatibility.

It's like they *know* the thing is too arcane, and they keep frigging around with hacks and kludges to try to mitigate the arcane bits, but they're making it worse, and it's not going to stabilize.

[#] Thu Jan 22 2009 16:30:19 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Gads, I keep writing these monster articles, then looking back at what I wrote, and thinking, "Nobody gives a damn."

Yeah, parts of C++ are really arcane. Parts of English are, as well.

But I'll agree that in English, the person interpreting what you are saying probably isn't going to go down the arcane road, while the compiler is almost always going to go down there because it doesn't know any better.

I don't know how much of that stuff is easy to run into, maybe because I have habits that prevent me from making those kinds of mistakes. Familiarity and all that.

Still, we use C++ here, so I have to teach it to my co-worker. I was hired because of my experience in C++ (amongst other things), so we use this language.
If we decided to jump to Smalltalk, Algol, Lisp, or whatever, I'd simply adjust for it. And that's just how it is.

I suspect C++ is losing its edge in the market place. I suspect my background in C++ may become less relevant down the road. I think, in a funny sort of way, that's a good thing.
If it's true, it means we don't need something like C++ to write well-performing applications anymore. And that's fine... let's use something people have an easier time grasping.

But, for me, C++ is pretty easy to use. I don't mind sticking to it for what I do, at least for now.

[#] Thu Jan 22 2009 16:35:18 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I suspect C++ is losing its edge in the market place. I suspect my

Native code is losing its edge in the marketplace. These days it's all about "managed code" (Java and C# ... or even scripting languages). Naturally it isn't as efficient as native code, but it makes sense from a business perspective: bigger hardware costs less than the extra developer time required to do it right. This relegates native code to low-level applications, and to those few projects that are driven by quality rather than time-to-market.

[#] Thu Jan 22 2009 16:37:59 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

IG, s/quality/high performance/, and I'll agree with you. There are different kinds of "quality", and "doesn't crash because some goon munged a pointer" is one of them.

That said, I wouldn't want any OS components that have to run the entire time your computer is up, to be written in managed code.

[#] Thu Jan 22 2009 16:45:32 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

You said something many messages ago: if you
*do* learn how to push the language to its n-th degree, you'll be able to write some extremely
powerful, flexible, elegant code.

And that's where I start having an issue.
I've been doing this shit for 20 years now and I have never seen all that flexibility come to any real amount of value.
I'm sure everybody has an exmaple of where they reused something, but in the large picture: that's bullshit. paradigms change, platforms change, and whole systems get rewritten long before andbody actually gets to reuse anything in any substantial way.

How much of the original uncensored codebase even exists let alone got reused.

The advantage C++ gives you is that it's fast. It's still not too far away from assembly. That's what it buys you over java and smallass.

But while I don't quite get all of the boost examples, I see what you're getting at, and from the compiler's point of view, it just can't be that fast. All that flexibility (that you're never going to use) really just got turned into wasted CPU cycles. I know, stu, shut up, I'll just buy a faster processor.

Let me put it this way:
You need a stack, variables, if-then, memory, and the ability to go to and come back from a funtion.
After that (and I know, we really need a lot less, but lets be turing-reasonable for a moment) it's all bullshit.
You can't tell me there's something you can do in C that you can't do in C++, because you can either do it in assembly or you can't, and if you can't do it in assembly, you won't get your C++ compiler to generate it either.
We make all the high level constructs and then have to invent more crap to get us out of the corner we painted ourselves in with all the limiting constructs.
I'm in that camp of people you mention of 'getting by with enough to make it work."
Because that's all you ever really need. To pay the mortgage or to work on your own projects.

[#] Thu Jan 22 2009 16:46:04 EST from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Making a bigger nastier tool to fix the bigger naster problem that you invented with the last iteration of the tool is... oh I know: Progress.

[#] Thu Jan 22 2009 18:44:42 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

There's nothing wrong with OO, and there *are* things you can do in OO that you can't do in C. You can organize your code far more effectively and efficiently. This is not about writing code that compiles to the most efficient assembler, it's about making the programmer's life easier. OO succeeds at that yet C++ actually partially fails (if misused; unfortunately in this day and age you have to deal with a lot of toolkits written by people who, you guessed it, misused the language.)

I'd much rather have a simple-but-slower OO language, that doesn't try to do all the speed-optimization crap that C++ is doing, such as templates and non-virtual method calls. Because all that speed-optimization only ends up painting you semantically into an ugly corner. It's like, dude, just make all your functions virtual and suck it up. Just add some runtime indirection instead of making this ugly compile-time mess. Then you don't need templates because you can just make everything respond to named methods. In other words, Peter Pulse has been right for all these years.

[#] Thu Jan 22 2009 18:46:56 EST from Peter Pulse @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Aww shucks ;)

[#] Thu Jan 22 2009 18:52:11 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

yea well, I came to this conclusion right around the time I actually started reading the source code for what was called the BTL or Borland Template Library, included w/ Turbo C++ 3.1... nasty levels of crap that piled you up with 10 levels deep of nested inline template overloaded operators. (And of course they had to include their source code because the whole thing was header files and otherwise they couldn't make the library available to you.)

And it was a freaking nightmare that needed to be razed to the ground and rebuilt. java.util.Collection finally gets it right. Anything written in straight C would have been far preferable, as well.

[#] Thu Jan 22 2009 22:11:52 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Heh... Tools++.

[#] Thu Jan 22 2009 23:51:38 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

There's nothing wrong with OO, and there *are* things you can do in OO

that you can't do in C. You can organize your code far more effectively

and efficiently. This is not about writing code that compiles to the

I don't know ... some of the nicest OO I've seen has been done in C. Write a C "class" with a good API that has "methods" (functions) to create, destroy, access, manipulate, serialize, and deserialize a data type without ever having to peek inside that data type ... and I think you're really most of the way there. So what if it isn't enforced by the compiler?

Ok, so you miss some extra goodies like inheritance and overloading, but you've still got objects, you still get the clean, organized code that results from using objects, and you didn't have to learn a byzantine language like C++ to make it happen.

Go to page: First ... 17 18 19 20 [21] 22 23 24 25 ... Last