折磨死我了……
这应该是个很不错的版本控制，以及所谓社会化编码的网站工具。不过上手还真的是需要段时间的。可能以后经常维护，会熟能生巧吧。
两个不错的参考文献：
Git for beginner
Github Help links
April 25, 2011
April 24, 2011
great resources for C.prog.lang
Basic commands and references:
C Programming Language
C/C++ references
The Definitive C++ Book Guide and List
Google C++ Style Guide
Lessons on development of 64-bit C/C++ applications
MIT C/C++ Introductory course
Solution manual of "The C Programming Language" (Kernighan & Ritchie)
两个C++的library
Six free E-books on C and C++
Algorithms:
Complicated data structure and algorithms
“火柴棍式”程序员面试题
如何调试makefile变量
打印质数的各种算法
Suggestions && methodologies:
Small C projects
21 days vs. ten years
如何学好C语言
如何学好C++
C++程序员自信心曲线
语言的歧义
C语言下的错误处理的问题
In-depth discussions:
Primeval C: two very early compilers
The context sensitivity of C’s grammar
C is a Wasteland
Why C++ is vastly superior to C
Which programming languages are fastest?
Top 6 List of Programming Top 10 Lists
A Guide to Undefined Behavior in C and C++: Part1, Part2, Part3.
Go Programming Language, Or: Why all C-like Programming Languages Except One Suck
Experience porting 4k lines of C code
Why do C++ folks make things so complicated?
Can a local variable's memory be accessed outside its scope?
Some of my thoughts:
Keep writing in C to solve the algorithm problems.
Transform to Clojure/C++/Python whenever the application scenario needs.
Read more about Perl/Python/Java.
Try to solve some puzzles or challenges everyday
C Programming Language
C/C++ references
The Definitive C++ Book Guide and List
Google C++ Style Guide
Lessons on development of 64-bit C/C++ applications
MIT C/C++ Introductory course
Solution manual of "The C Programming Language" (Kernighan & Ritchie)
两个C++的library
Six free E-books on C and C++
Algorithms:
Complicated data structure and algorithms
“火柴棍式”程序员面试题
如何调试makefile变量
打印质数的各种算法
Suggestions && methodologies:
Small C projects
21 days vs. ten years
如何学好C语言
如何学好C++
C++程序员自信心曲线
语言的歧义
C语言下的错误处理的问题
In-depth discussions:
Primeval C: two very early compilers
The context sensitivity of C’s grammar
C is a Wasteland
Why C++ is vastly superior to C
Which programming languages are fastest?
Top 6 List of Programming Top 10 Lists
A Guide to Undefined Behavior in C and C++: Part1, Part2, Part3.
Go Programming Language, Or: Why all C-like Programming Languages Except One Suck
Experience porting 4k lines of C code
Why do C++ folks make things so complicated?
Can a local variable's memory be accessed outside its scope?
Some of my thoughts:
Keep writing in C to solve the algorithm problems.
Transform to Clojure/C++/Python whenever the application scenario needs.
Read more about Perl/Python/Java.
Try to solve some puzzles or challenges everyday
Algorithm complexity
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian Kernighan
Remark: If the code is complex enough to be at the limits of your skills, then debugging that code will exceed your skills. In other words, don't make code so complex that you can't maintain it. "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?", quoted from Kernighan (and Plauger, in "The Elements of Programming Style").
I've found that using weaker tools can help with complexity. It's hard to write a complicated C program because it can't do very much. C programs tend to use lots of arrays because that's all you get, but it turns out that arrays are great -- compact memory representation, O(1) access, good data locality. I'd never advocate intentionally using a weak tool, though. Instead, my lesson has been: write Python code like it was C.--"Complexity is the enemy" written by Evan Martin.
Remark: If the code is complex enough to be at the limits of your skills, then debugging that code will exceed your skills. In other words, don't make code so complex that you can't maintain it. "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?", quoted from Kernighan (and Plauger, in "The Elements of Programming Style").
I've found that using weaker tools can help with complexity. It's hard to write a complicated C program because it can't do very much. C programs tend to use lots of arrays because that's all you get, but it turns out that arrays are great -- compact memory representation, O(1) access, good data locality. I'd never advocate intentionally using a weak tool, though. Instead, my lesson has been: write Python code like it was C.--"Complexity is the enemy" written by Evan Martin.
April 16, 2011
Programming craftsmanship
The article below is a digest from "Programming is not a craft" (courtesy to the author Dan North.)
-----------------
Software Craftsmanship risks putting the software at the center rather than the benefit the software is supposed to deliver, mostly because we are romantics with big egos. Programming is about automating work like crunching data, processing and presenting information, or controlling and automating machines.
They understand software development is a skill, in fact a whole portfolio of skills: understanding and modeling a problem domain, understanding programming languages, libraries, paradigms and idioms, choosing which to apply in a given situation, learning and understanding algorithms, mastering the "path to production" (build, deployment, release), monitoring and availability, process automation, Lean theories of supply, production and product development, utility and cloud computing, concurrency and parallelism, and so on.
The oft-quoted figures of tenfold increase in productivity of expert versus novice programmers are wrong by orders of magnitude in my experience. A really great programmer (and I've been lucky enough to work with a handful over the years) can out-perform a doing-it-for-the-money programmer by orders of literally hundreds, delivering in hours or days what would take an average developer weeks or months.
It seems to me the most successful programmers I've encountered don't craft software; they write software in order to move information around, in order to get something done. Information is the real deal – the software just defines the space that it moves around in. For those programmers, success is about getting information from point A where it's currently languishing to point B where it's going to actually be useful, as quickly and effectively as they can. Success in a UI is about rendering or capturing exactly the information that will be useful – no less and certainly no more – in a succinct, obvious way. The software is incidental, a detail, hidden away in the wings, and it is ultimately entirely disposable.
-----------------
Software Craftsmanship risks putting the software at the center rather than the benefit the software is supposed to deliver, mostly because we are romantics with big egos. Programming is about automating work like crunching data, processing and presenting information, or controlling and automating machines.
They understand software development is a skill, in fact a whole portfolio of skills: understanding and modeling a problem domain, understanding programming languages, libraries, paradigms and idioms, choosing which to apply in a given situation, learning and understanding algorithms, mastering the "path to production" (build, deployment, release), monitoring and availability, process automation, Lean theories of supply, production and product development, utility and cloud computing, concurrency and parallelism, and so on.
The oft-quoted figures of tenfold increase in productivity of expert versus novice programmers are wrong by orders of magnitude in my experience. A really great programmer (and I've been lucky enough to work with a handful over the years) can out-perform a doing-it-for-the-money programmer by orders of literally hundreds, delivering in hours or days what would take an average developer weeks or months.
It seems to me the most successful programmers I've encountered don't craft software; they write software in order to move information around, in order to get something done. Information is the real deal – the software just defines the space that it moves around in. For those programmers, success is about getting information from point A where it's currently languishing to point B where it's going to actually be useful, as quickly and effectively as they can. Success in a UI is about rendering or capturing exactly the information that will be useful – no less and certainly no more – in a succinct, obvious way. The software is incidental, a detail, hidden away in the wings, and it is ultimately entirely disposable.
starting point
B.E. 100*2+50=250 (two exam plus one course)
M.E. 300+300+50=650 (three years)
MSc 100+600+50+200=950 (lab and homework)
=1850hr
M.E. 300+300+50=650 (three years)
MSc 100+600+50+200=950 (lab and homework)
=1850hr
April 15, 2011
recent reflection
There is an essay talking about the LISP Curse , which is so much familiar with the development of Computer Vision/Machine Learning with signal processing. I have taken two consecutive courses of computer vision, and one paragraph of description in the essay above could summarize all of my feelings:
"Programs written by individual contributors tend to follow the scratch-an-itch model. These programs will solve the problem that the contributor, himself, is having without necessarily handling related parts of the problem which would make the program more useful to others. Furthermore, the program is sure to work on that lone contributor's own setup, but may not be portable to other implementations with even similar scenarios, or to the same implementation on other platforms. Documentation may be lacking. Being essentially a project done in one's copious free time, or based on the only destination of making a proposal to apply grants, the program is liable to suffer should real-life responsibilities intrude on it. As Olin Shivers noted, this means that these one-man-band projects tend to solve eighty-percent of the problem"...(at maximum).
Those two courses were just copying and trying hard to duplicate other works from some other professors. All of the works were self-contained. The instructor wished that some of the duplications would lead him any insight, and then let some of his own students to add some other specifications on it, to make the so-called "breakthrough", and to publish one or more papers. Yes, the papers are the ultimate destination, which could both make the students graduate and reveal the extraordinary achievements of the professor.
I should have somewhat lucky feeling not choosing this lab, although I might also learn a lot by choosing it and complete my doctoral degree... And in the latter scenario, the lucky feeling seems exactly like a useless self-consolation. But, anyway, collective intellectual is definitely the right way to improve one field of study. And more importantly, I should leave myself sufficient time to learn more and think about everything.
"Programs written by individual contributors tend to follow the scratch-an-itch model. These programs will solve the problem that the contributor, himself, is having without necessarily handling related parts of the problem which would make the program more useful to others. Furthermore, the program is sure to work on that lone contributor's own setup, but may not be portable to other implementations with even similar scenarios, or to the same implementation on other platforms. Documentation may be lacking. Being essentially a project done in one's copious free time, or based on the only destination of making a proposal to apply grants, the program is liable to suffer should real-life responsibilities intrude on it. As Olin Shivers noted, this means that these one-man-band projects tend to solve eighty-percent of the problem"...(at maximum).
Those two courses were just copying and trying hard to duplicate other works from some other professors. All of the works were self-contained. The instructor wished that some of the duplications would lead him any insight, and then let some of his own students to add some other specifications on it, to make the so-called "breakthrough", and to publish one or more papers. Yes, the papers are the ultimate destination, which could both make the students graduate and reveal the extraordinary achievements of the professor.
I should have somewhat lucky feeling not choosing this lab, although I might also learn a lot by choosing it and complete my doctoral degree... And in the latter scenario, the lucky feeling seems exactly like a useless self-consolation. But, anyway, collective intellectual is definitely the right way to improve one field of study. And more importantly, I should leave myself sufficient time to learn more and think about everything.
March 29, 2011
virtual function and template in C++
Object-oriented programming is based on three fundamental concepts: data abstraction, inheritance, and dynamic binding. In C++ we use classes for data abstraction and class derivation to inherit one class from another: A derived class inherits the members of its base class(es). Dynamic binding lets the compiler determine at run time whether to use a function defined in the base or derived class.
Inheritance and dynamic binding streamline our programs in two ways: They make it easier to define new classes that are similar, but not identical, to other classes, and they make it easier for us to write programs that can ignore the details of how those similar types differ.
By default, function calls in C++ do not use dynamic binding. To trigger dynamic binding, two conditions must be met: First, only member functions that are specified as virtual can be dynamically bound. By default, member functions are not virtual; nonvirtual functions are not dynamically bound. Second, the call must be made through a reference or a pointer to a base-class type.
In object-oriented programming, a virtual function or virtual method is a function or method whose behaviour can be overridden within an inheriting class by a function with the same signature. This concept is a very important part of the polymorphism portion of object-oriented programming (OOP). (Wikipage)
Virtual functions overcome the problems with the type-field solution by allowing the programmer to declare functions in a base class that can be redefined in each derived class. The distinction between virtual and non-virtual resolves this ambiguity. If the function in question is designated "virtual" in the base class then the derived class's function would be called (if it exists). If it is not virtual, the base class's function would be called. C++ non-virtual function calls are resolved at compile time with static binding, while virtual function calls are resolved at run time with dynamic binding
A destructor in base class need to be declared virtual.
Calling a method with an object pointer always invokes:
» the most derived class function, if a method is virtual
» the function implementation corresponding to the object pointer type (used to call the method), if a method is non-virtual
A virtual destructor works in the same way A destructor gets called when an object goes out of scope or when we call delete on an object pointer When any derived class object goes out of scope, the destructor of that derived class gets called first It then calls its parent class destructor so memory allocated to the object is properly released. But, if we call delete on a base pointer which points to a derived class object, the base class destructor gets called first (for non-virtual function). We should use virtual destructors if we call delete on a base class pointer which points to a derived class
=========
Templates are the foundation of generic programming, which involves writing code in a way that is independent of any particular type. The library containers and iterators are examples of generic programming. There is a single definition of each container, such as vector, but we can define many different kinds of vectors that differ by the element type that the vector contains. Similarly, we can, and have, used templates without understanding how they are defined.
A template is a blueprint or formula for creating a class or a function. A function template is a type-independent function that is used as a formula for generating a type-specific version of the function. For example, the standard library defines a single class template that defines what it means to be a vector. That template is used to generate any number of type-specific vector classesfor example, vector<int> or vector<string>.
reference <C++ primer>
Inheritance and dynamic binding streamline our programs in two ways: They make it easier to define new classes that are similar, but not identical, to other classes, and they make it easier for us to write programs that can ignore the details of how those similar types differ.
By default, function calls in C++ do not use dynamic binding. To trigger dynamic binding, two conditions must be met: First, only member functions that are specified as virtual can be dynamically bound. By default, member functions are not virtual; nonvirtual functions are not dynamically bound. Second, the call must be made through a reference or a pointer to a base-class type.
In object-oriented programming, a virtual function or virtual method is a function or method whose behaviour can be overridden within an inheriting class by a function with the same signature. This concept is a very important part of the polymorphism portion of object-oriented programming (OOP). (Wikipage)
Virtual functions overcome the problems with the type-field solution by allowing the programmer to declare functions in a base class that can be redefined in each derived class. The distinction between virtual and non-virtual resolves this ambiguity. If the function in question is designated "virtual" in the base class then the derived class's function would be called (if it exists). If it is not virtual, the base class's function would be called. C++ non-virtual function calls are resolved at compile time with static binding, while virtual function calls are resolved at run time with dynamic binding
A destructor in base class need to be declared virtual.
Calling a method with an object pointer always invokes:
» the most derived class function, if a method is virtual
» the function implementation corresponding to the object pointer type (used to call the method), if a method is non-virtual
A virtual destructor works in the same way A destructor gets called when an object goes out of scope or when we call delete on an object pointer When any derived class object goes out of scope, the destructor of that derived class gets called first It then calls its parent class destructor so memory allocated to the object is properly released. But, if we call delete on a base pointer which points to a derived class object, the base class destructor gets called first (for non-virtual function). We should use virtual destructors if we call delete on a base class pointer which points to a derived class
=========
Templates are the foundation of generic programming, which involves writing code in a way that is independent of any particular type. The library containers and iterators are examples of generic programming. There is a single definition of each container, such as vector, but we can define many different kinds of vectors that differ by the element type that the vector contains. Similarly, we can, and have, used templates without understanding how they are defined.
A template is a blueprint or formula for creating a class or a function. A function template is a type-independent function that is used as a formula for generating a type-specific version of the function. For example, the standard library defines a single class template that defines what it means to be a vector. That template is used to generate any number of type-specific vector classesfor example, vector<int> or vector<string>.
reference <C++ primer>
Subscribe to:
Posts (Atom)
Days of our lives
