Comments on: Comparing python to C … http://www.philhassey.com/blog/2008/08/06/comparing-python-to-c/ game dev blog Fri, 06 Jan 2012 23:00:54 +0000 hourly 1 http://wordpress.org/?v=3.1.2 By: Freddie, not C! http://www.philhassey.com/blog/2008/08/06/comparing-python-to-c/comment-page-1/#comment-7918 Freddie, not C! Thu, 11 Sep 2008 13:29:17 +0000 http://www.philhassey.com/blog/?p=147#comment-7918 Yeah, I got excited and was expecting a title box... :P Yeah, I got excited and was expecting a title box… :P

]]> By: C! http://www.philhassey.com/blog/2008/08/06/comparing-python-to-c/comment-page-1/#comment-7917 C! Thu, 11 Sep 2008 13:28:04 +0000 http://www.philhassey.com/blog/?p=147#comment-7917 Does this mean you're re-writing the linux version => no more need for python2.4?! The increased speed would be very welcome. I hate the fact my machine stutters with 2 cpu players and me... it's not that old! :( Does this mean you’re re-writing the linux version => no more need for python2.4?! The increased speed would be very welcome. I hate the fact my machine stutters with 2 cpu players and me… it’s not that old! :(

]]> By: Joachim Bengtsson http://www.philhassey.com/blog/2008/08/06/comparing-python-to-c/comment-page-1/#comment-6743 Joachim Bengtsson Fri, 22 Aug 2008 13:39:52 +0000 http://www.philhassey.com/blog/?p=147#comment-6743 PoV: Evolve a single skill as far as you can get, or shift your entire way of thinking about the skill by learning a new (good) language/library? I guess you could argue for the former, but I prefer the latter :) PoV: Evolve a single skill as far as you can get, or shift your entire way of thinking about the skill by learning a new (good) language/library? I guess you could argue for the former, but I prefer the latter :)

]]> By: Kenny http://www.philhassey.com/blog/2008/08/06/comparing-python-to-c/comment-page-1/#comment-6713 Kenny Thu, 21 Aug 2008 16:14:28 +0000 http://www.philhassey.com/blog/?p=147#comment-6713 Why not write a python script to generate your header files from the .c files? It's really quite simple - put the structs and any includes etc in a comment block at the top of the .c file to be read in for the .h file, then parse your file for functions if it has changed and put declarations into the .h file. I do something similar with Objective C and it works well - no longer have to worry about putting declarations in by hand. Why not write a python script to generate your header files from the .c files? It’s really quite simple – put the structs and any includes etc in a comment block at the top of the .c file to be read in for the .h file, then parse your file for functions if it has changed and put declarations into the .h file.

I do something similar with Objective C and it works well – no longer have to worry about putting declarations in by hand.

]]> By: philhassey http://www.philhassey.com/blog/2008/08/06/comparing-python-to-c/comment-page-1/#comment-6458 philhassey Wed, 13 Aug 2008 02:14:01 +0000 http://www.philhassey.com/blog/?p=147#comment-6458 I would have used curl (I considered it) but it's bigness scared me. Though I probably would have broke even / saved time if I had bothered to work it out. Maybe next time :) I did use enet and some md5 lib though. Those saved huge amounts of time. I would have used curl (I considered it) but it’s bigness scared me. Though I probably would have broke even / saved time if I had bothered to work it out. Maybe next time :)

I did use enet and some md5 lib though. Those saved huge amounts of time.

]]> By: Rene Dudfield http://www.philhassey.com/blog/2008/08/06/comparing-python-to-c/comment-page-1/#comment-6457 Rene Dudfield Wed, 13 Aug 2008 00:57:38 +0000 http://www.philhassey.com/blog/?p=147#comment-6457 This also shows that domain knowledge always trumps any advantages you get from languages. It also shows that using a good library can speed up development more than using a higher level language too. If your program can already scale like Phils can, you really don't need erlang. It's easier to just keep adding servers. Since each server only allows say 8 people at once to join it... there's only that shared state. This also shows that domain knowledge always trumps any advantages you get from languages.

It also shows that using a good library can speed up development more than using a higher level language too.

If your program can already scale like Phils can, you really don’t need erlang. It’s easier to just keep adding servers. Since each server only allows say 8 people at once to join it… there’s only that shared state.

]]> By: PoV http://www.philhassey.com/blog/2008/08/06/comparing-python-to-c/comment-page-1/#comment-6446 PoV Mon, 11 Aug 2008 17:42:35 +0000 http://www.philhassey.com/blog/?p=147#comment-6446 Heh, yeah. Read a book, spend weeks on end studding and learning new languages and API's, or hack it in and move on to the next project. Hmmm... Heh, yeah. Read a book, spend weeks on end studding and learning new languages and API’s, or hack it in and move on to the next project.

Hmmm…

]]> By: Joachim Bengtsson http://www.philhassey.com/blog/2008/08/06/comparing-python-to-c/comment-page-1/#comment-6381 Joachim Bengtsson Fri, 08 Aug 2008 15:31:17 +0000 http://www.philhassey.com/blog/?p=147#comment-6381 I'll gladly explain :) It boils down to different abstraction layers. At the bottom of user space you have Core Foundation, which serves as a common ground for the higher-level APIs above it. It's plain C, and it provides, among others, CFString. You can use this from your current C code to clean string handling up if you feel you need it :) Above that, on a desktop Mac, you have several APIs, e g Cocoa, Carbon and Java, that all have wrappers around CFString. In Cocoa, and on the iPhone, Cocoa Touch, you have NSString, which is an ObjC wrapper around CFString. CFString and NSString are toll-free bridged, which means that you can send a pointer to the one to a function requesting a pointer to the other (i e, doing (CFString*)myNSStringInstance is okay) (e g if you want to propagate an NSString down to your C code without copying and/or degrading it to a char buffer). I'm guessing that the third string you found was NSMutableString. The distinction is that an NSString (and almost all other container class bases in Cocoa) is immutable (like const), for performance, and so that you can share one instance in many places without having to worry about it changing under you (sharing instances is an area where ObjC shines, for being a C language). Thus, if you want a string which you can change in-place, you'd use NSMutableString. Then there's also NSAttributedString, which is for styled text. If you want a book on ObjC/Cocoa, I'd recommend Aaron Hillegass' "Cocoa Programming for Mac OS X". It's probably the best programming book or maybe even computing book I've read. For networking and high performance servers I'm learning Erlang, a distributed concurrent language, and it's really cool, stable and fast :) I’ll gladly explain :) It boils down to different abstraction layers. At the bottom of user space you have Core Foundation, which serves as a common ground for the higher-level APIs above it. It’s plain C, and it provides, among others, CFString. You can use this from your current C code to clean string handling up if you feel you need it :)

Above that, on a desktop Mac, you have several APIs, e g Cocoa, Carbon and Java, that all have wrappers around CFString. In Cocoa, and on the iPhone, Cocoa Touch, you have NSString, which is an ObjC wrapper around CFString.

CFString and NSString are toll-free bridged, which means that you can send a pointer to the one to a function requesting a pointer to the other (i e, doing (CFString*)myNSStringInstance is okay) (e g if you want to propagate an NSString down to your C code without copying and/or degrading it to a char buffer).

I’m guessing that the third string you found was NSMutableString. The distinction is that an NSString (and almost all other container class bases in Cocoa) is immutable (like const), for performance, and so that you can share one instance in many places without having to worry about it changing under you (sharing instances is an area where ObjC shines, for being a C language). Thus, if you want a string which you can change in-place, you’d use NSMutableString.

Then there’s also NSAttributedString, which is for styled text.

If you want a book on ObjC/Cocoa, I’d recommend Aaron Hillegass’ “Cocoa Programming for Mac OS X”. It’s probably the best programming book or maybe even computing book I’ve read.

For networking and high performance servers I’m learning Erlang, a distributed concurrent language, and it’s really cool, stable and fast :)

]]> By: philhassey http://www.philhassey.com/blog/2008/08/06/comparing-python-to-c/comment-page-1/#comment-6379 philhassey Fri, 08 Aug 2008 14:53:50 +0000 http://www.philhassey.com/blog/?p=147#comment-6379 No problem. While we're on the subject - one thing that I noticed which made me very nervous about ObjC is that it seemed to me that there were at least 3 different String objects that I came across. For a "noob" to ObjC, that's scary as all get out. Which string do I use? Why are there 3? Should I be concerned? Is there some real difference? etc ... The speed thing is actually really nice, I'm going to be able to host dozens of servers on a single CPU :) Which will be great if the MP game takes off. No problem. While we’re on the subject – one thing that I noticed which made me very nervous about ObjC is that it seemed to me that there were at least 3 different String objects that I came across.

For a “noob” to ObjC, that’s scary as all get out. Which string do I use? Why are there 3? Should I be concerned? Is there some real difference? etc …

The speed thing is actually really nice, I’m going to be able to host dozens of servers on a single CPU :) Which will be great if the MP game takes off.

]]> By: Joachim Bengtsson http://www.philhassey.com/blog/2008/08/06/comparing-python-to-c/comment-page-1/#comment-6378 Joachim Bengtsson Fri, 08 Aug 2008 14:49:10 +0000 http://www.philhassey.com/blog/?p=147#comment-6378 I hope you don't mind me rebutting :) - C style coding is terse, but on the other hand, you have to write a lot of blanket code, both because of the language itself (e g "int i = 0; for(; i < someLength; i++)" vs "for(obj in collection)" and because the standard library is so small. Also, I like Cocoa's verbosity, because it lends to self-documenting code (a method's complete functionality is in its name, rarely with non-obvious side effects). - If you wish to do code in ObjC/Cocoa in the future, I'd love to help out, just contact me :) I love the language, can't stop evangelizing it :P - You already got Python for desktop OS's ;) Yeah, I know, speed... I hope you don’t mind me rebutting :)

- C style coding is terse, but on the other hand, you have to write a lot of blanket code, both because of the language itself (e g “int i = 0; for(; i < someLength; i++)” vs “for(obj in collection)” and because the standard library is so small. Also, I like Cocoa’s verbosity, because it lends to self-documenting code (a method’s complete functionality is in its name, rarely with non-obvious side effects).
- If you wish to do code in ObjC/Cocoa in the future, I’d love to help out, just contact me :) I love the language, can’t stop evangelizing it :P
– You already got Python for desktop OS’s ;) Yeah, I know, speed…

]]>