The Joys Of Programming

Anyone know of a good e-book on Django? A book on doing REST wih Django? I'm in Hawaii currently. I have a long trip home (the trip was purchased on points) and I have a job interview next week for a job doing Python. I know Python, but I haven't used it since my last job. A year. Since then I've been working on a web service in my spare time (a startup project) using PHP. I figured on the way home I'd rewrite it in Django/Python, but need to download a good e-book to reference on the plane. Any ideas?

Hey that page looks familiar, I think I came across it earlier this year when I was doing research for my own ray-tracer (c++, multithreaded, but lacking a solid acceleration structure).

Here's a screen of a render I made with mine. 800x600 screen resolution, 2048 indirect rays per first hit.

http://farm3.static.flickr.com/2756/...

DSGamer wrote:

Anyone know of a good e-book on Django? A book on doing REST wih Django? I'm in Hawaii currently. I have a long trip home (the trip was purchased on points) and I have a job interview next week for a job doing Python. I know Python, but I haven't used it since my last job. A year. Since then I've been working on a web service in my spare time (a startup project) using PHP. I figured on the way home I'd rewrite it in Django/Python, but need to download a good e-book to reference on the plane. Any ideas?

The Django Book, online version of Apress's book.

wget -m that bad boy for a locally stored copy.

I second the Django Book, only because it's the only one I used.

Maybe this is a stupid place to ask this, but I've run into an interesting C++ question. I'm a C#/PHP guy, with distant C++ experience, so please be gentle.

I'm working with Ogre3D to do some rendering. Sometimes they'll declare a pointer like:

"Ogre::Root* mRoot;"

and sometimes it's like:

"Ogre::ConfigFile::SettingsMultiMap *settings = seci.getNext();"

What's the difference? I hope those aren't ridiculously bad examples. I've poured through my old C++ book, and I've Googled, but I'm not actually sure what I'm even looking for?

Side note: They do the same with the reference "&" operator.

EDIt:
To clarify, I'm wondering why sometimes the "*" and "&" are adjacent to the type, and sometimes they're adjacent to the variable.

If you are referring to the alignment of *, then no it doesn't matter for anything but esthetics.

(As long as you don't confuse int* foo, bar; with int *foo, *bar; that is)

nossid wrote:

If you are referring to the alignment of *, then no it doesn't matter for anything but esthetics.

(As long as you don't confuse int* foo, bar; with int *foo, *bar; that is)

Great. What's the difference with your example?

int* foo, bar; is the same as:

int* foo; int bar;

while int *foo, *bar; is

int* foo; int* bar;

Just gotta be careful with the way the * is parsed, which is why some prefer to have it aligned with the variable instead of the type to make it clearer in this case. I prefer to align it with the type and just avoid writing mixed declarations on one line.

Is there a reason you prefer to align it with the type?

Lex Cayman wrote:

Is there a reason you prefer to align it with the type?

It fits with the way I read and think about the code. I view it primarily as an "int pointer", not as an int at the other end of a pointer, so it makes sense to consider it part of the type from that point of view.

Ditto.

A lot of more old skool C hacker types (who still use Kernigan and Ritchie style) like to put it with the instance name. With C++, I like to have the various types all clearly set out (for when I have to cast them or whatever), so I prefer to keep it with the type.

Also, constructions like int *foo, *bar; aren't initialising the variables, so I'd prefer to have them on separate lines and initialised in any way.

I also prefer const int* rather than int const *, just so I can distinguish const int * const, int* const, and const int* easily.

Awesome, thanks guys!

Honestly I just say screw it and don't do multiple variable declarations on one line. You'd be surprised how much more readable the code is this way, and honestly it rarely saves enough space to matter (as if LOC matters anymore, don't fill up your 10MB hard drive!)

I prefer to align it with the symbol being declared:

int *foo;

The conceit behind C's declaration syntax is that the declaration mirrors the syntax for using the declared symbol. Given "foo" above, saying "*foo" will yield an int (the type of the declaration). This explains why the syntax for declaring a function pointer is so weird:

int *(*f)(double, char*);

There we have a function pointer to a function which accepts a double and a char*, and returns an int*.

This also gives us the array declaration syntax:

int *arr[20];

There we have an array of 20 pointers. The only really confusing part here is remembering whether prefix or postfix unary operators have precedence. (Postfix operators do.)

Anyway. In this broader context, aligning the asterisk with the identifier makes a great deal of sense.

The awesome part is that 'const' can be placed before or after the symbol, with occasionally different results. Just the other day I had to write "char const * const &" to satisfy a template function specialization. C++ is powerful, but the syntax could be better. For example, it's often necessary to inject "typename" in template type names just to tell the compiler that something is actually a type name. Worse, typedef doesn't help. For example:

template(class T) void func() { typedef std::vector(T) buffer_type; typedef buffer_type::iterator iter_type; // error typedef typename buffer_type::iterator iter_type; // correct }

(just pretend the parens are angle brackets)

Why oh why didn't I take the blue pill?

This thread has suddenly become like reading The Matrix. :p

IMAGE(http://www.webdesign.org/img_articles/7467/matrix-slice_09.gif)

/programming retard.

MightyMooquack wrote:

I prefer to align it with the symbol being declared:

int *foo;

The conceit behind C's declaration syntax is that the declaration mirrors the syntax for using the declared symbol. Given "foo" above, saying "*foo" will yield an int (the type of the declaration). This explains why the syntax for declaring a function pointer is so weird:

int *(*f)(double, char*);

There we have a function pointer to a function which accepts a double and a char*, and returns an int*.

This also gives us the array declaration syntax:

int *arr[20];

There we have an array of 20 pointers. The only really confusing part here is remembering whether prefix or postfix unary operators have precedence. (Postfix operators do.)

Anyway. In this broader context, aligning the asterisk with the identifier makes a great deal of sense.

In C++ I'm primarily concerned with the types of instances. The type of foo is int*, so in the sense that I am declaring a instance of a "pointer to an int" called "foo" I want it spaced that way. I regard most of the newbie mistakes in using pointers (e.g. not allocating them) as stemming from the int *foo style, which really only makes sense when you're stacking them up on a line.

Whereas I would regard that function pointer as being more clearly defined as

int* (*f)(double, char*);

rather than putting the two asterisks together. This way the asterisk for the return type (int*) and the one for the function pointer are grouped with the element they're referring to.

The compiler doesn't care about all of this, but I like to use a syntax that helps me know what type everything is everywhere.

complexmath wrote:

The awesome part is that 'const' can be placed before or after the symbol, with occasionally different results. Just the other day I had to write "char const * const &" to satisfy a template function specialization. C++ is powerful, but the syntax could be better. For example, it's often necessary to inject "typename" in template type names just to tell the compiler that something is actually a type name. Worse, typedef doesn't help. For example:

template(class T) void func() { typedef std::vector(T) buffer_type; typedef buffer_type::iterator iter_type; // error typedef typename buffer_type::iterator iter_type; // correct }

(just pretend the parens are angle brackets)

That's a facet of how C++ deals with template ambiguity. If you have a templated function on T, then T::f(a) could be calling a function f or initialising an instance T::f. So it makes you put typename in. I agree that typedef should be able to resolve it since the syntax dictates that only a type could go immediately after the typename keyword, but since it's inherited from C I guess they can't change the compiler syntax for it.

My eyes start crossing whenever pointers get mentioned. I can appreciate them, what they're for and some of the clever stuff they do, but it just doesn't get my juices flowing.

I don't miss C++ pointers & dereferencing and all the mental gymnastics related to them.

DudleySmith wrote:

In C++ I'm primarily concerned with the types of instances. The type of foo is int*, so in the sense that I am declaring a instance of a "pointer to an int" called "foo" I want it spaced that way. I regard most of the newbie mistakes in using pointers (e.g. not allocating them) as stemming from the int *foo style, which really only makes sense when you're stacking them up on a line.

Later languages which are influenced by C's syntax agree with you. In D, for instance, the following declares two pointers:

int* a, b;

Go's declaration syntax is backwards compared to C, but is otherwise derived from it. The following declares two pointers:

var a, b *int

DudleySmith wrote:
complexmath wrote:

The awesome part is that 'const' can be placed before or after the symbol, with occasionally different results. Just the other day I had to write "char const * const &" to satisfy a template function specialization. C++ is powerful, but the syntax could be better. For example, it's often necessary to inject "typename" in template type names just to tell the compiler that something is actually a type name. Worse, typedef doesn't help. For example:

template(class T) void func() { typedef std::vector(T) buffer_type; typedef buffer_type::iterator iter_type; // error typedef typename buffer_type::iterator iter_type; // correct }

(just pretend the parens are angle brackets)

That's a facet of how C++ deals with template ambiguity. If you have a templated function on T, then T::f(a) could be calling a function f or initialising an instance T::f. So it makes you put typename in. I agree that typedef should be able to resolve it since the syntax dictates that only a type could go immediately after the typename keyword, but since it's inherited from C I guess they can't change the compiler syntax for it.

This is basically a consequence of how tortured the C++ grammar is. It is very telling that D's templates manage to avoid this ambiguity entirely. The following is basically equivalent to the C++ code above, except (as D doesn't have a precise equivalent to C++'s iterators) using a fictional templated type "foo" with an inner type "bar".

void func(T)() { alias foo!(T) buffer_type; alias buffer_type.bar iter_type; }

My point is basically that I am not a huge fan of C++.

Up Next: a round-table on Hungarian notation.

[font=small](oh please Dear Lord not really....)[/font]

DudleySmith wrote:
complexmath wrote:

The awesome part is that 'const' can be placed before or after the symbol, with occasionally different results. Just the other day I had to write "char const * const &" to satisfy a template function specialization. C++ is powerful, but the syntax could be better. For example, it's often necessary to inject "typename" in template type names just to tell the compiler that something is actually a type name. Worse, typedef doesn't help. For example:

template(class T) void func() { typedef std::vector(T) buffer_type; typedef buffer_type::iterator iter_type; // error typedef typename buffer_type::iterator iter_type; // correct }

(just pretend the parens are angle brackets)

That's a facet of how C++ deals with template ambiguity. If you have a templated function on T, then T::f(a) could be calling a function f or initialising an instance T::f. So it makes you put typename in. I agree that typedef should be able to resolve it since the syntax dictates that only a type could go immediately after the typename keyword, but since it's inherited from C I guess they can't change the compiler syntax for it.

That reminds me of "C++'s most vexing parse," which is another huge issue. My point was simply that the syntax for C++ has a number of warts that, I suspect, are a result of the syntax being designed by people who don't write compilers and therefore didn't think of the ambiguities at the time. As MightyMooquack points out, these problems aren't intrinsic to what's actually being done, but more an issue of the specific C++ syntax for doing so.

FWIW, I've been a tinkering-level programmer for most of my adult life, and I understand perfectly well what pointers are, and I was still getting a bit dizzy in this thread.

complexmath wrote:

That reminds me of "C++'s most vexing parse," which is another huge issue. My point was simply that the syntax for C++ has a number of warts that, I suspect, are a result of the syntax being designed by people who don't write compilers and therefore didn't think of the ambiguities at the time. As MightyMooquack points out, these problems aren't intrinsic to what's actually being done, but more an issue of the specific C++ syntax for doing so.

I don't know which compiler you're using (Microsoft, maybe?) but gcc allows you to typedef iterator types without inserting the typename keyword. That construct is all over our code. As I said, I don't typedef iterators very often myself, so I wasn't sure.

The gotchas and nasties in the C++ syntax are not due to the people who wrote it not knowing about compilers, but due to it needing to be back-compatible with C syntax, and being unable to properly escape from them without breaking the back-compatibility.

Since programming is a job and not a hobby any more for me, I've probably lost a lot of the joy I had when I programmed my Spectrum 25 years ago. Learning the shiny new language is not time-effective for me until such time as it makes commercial sense. I've got nothing against D (there are some languages that I regard as worthless academic wanking), but it is still pretty niche. I don't honestly see it taking off, since it isn't better enough than C++ to supplant it in industry. If you know how to write it properly, C++ is still the way you'd get a sizeable team to develop a large real-time embedded system.

I've been spending some spare cycles teaching myself Erlang, which has been a lot of fun and smiles. There are some posts on my blog about when I was first getting into it. I love the syntax and the philosophy behind it, although the dynamic typing is annoying at times.
I've started work on a really sh*tty telnet mud in it and that's been fun, but time consuming.
I've never learned Python, but a lot of my co workers love it, on the to do list.

DudleySmith wrote:

I don't know which compiler you're using (Microsoft, maybe?) but gcc allows you to typedef iterator types without inserting the typename keyword. That construct is all over our code. As I said, I don't typedef iterators very often myself, so I wasn't sure.

The gotchas and nasties in the C++ syntax are not due to the people who wrote it not knowing about compilers, but due to it needing to be back-compatible with C syntax, and being unable to properly escape from them without breaking the back-compatibility.

I'm using gcc. Try the code I pasted and see. Dependent template type definitions pretty much always need a 'typename' added. Just using "vector::iterator" will do it. And I disagree about C compatibility in this case. They could have chosen a different syntax for type initialization that didn't cause the parsing ambiguity, chose different template typelist markers that didn't cause that ambiguity, etc, and still been C-compatible. There are other examples of decisions that might have been different if those involved had more experience writing compilers, such as exported templates. Now, there are a bunch of compiler folks in the committee--the EDG folks, Bjarne (obviously, etc)--but design by committee is a tricky thing.

Mixolyde wrote:

I've been spending some spare cycles teaching myself Erlang, which has been a lot of fun and smiles. There are some posts on my blog about when I was first getting into it. I love the syntax and the philosophy behind it, although the dynamic typing is annoying at times.
I've started work on a really sh*tty telnet mud in it and that's been fun, but time consuming.
I've never learned Python, but a lot of my co workers love it, on the to do list.

Found any good resources for getting started with Erlang? That's on my short list of languages to learn.

If you're serious about learning Erlang, pick up the book. It's well written, and I haven't found online tutorials and such that are anywhere near as complete.