Friday, June 18, 2010

Adding PHP snippets through the Drupal user interface

Enable PHP input filter: Go to Administer -> Site building -> Modules, and check PHP Filter under core - optional. Now when create new content, a PHP option will appear under input formats - select this to paste a PHP code snippet. This opens a powerful door to creating dynamic content on a Drupal site.

See Drupal: A beginner's guide to using snippets.

Often a PHP snippet is written inside a drupal module block. What if you want to access Drupal database from an external PHP file? Below is an example. See here for reference.

<?php
// Root path of drupal site, can be obtained using getcwd().
$path = "/web/1/www.hawaii.edu/drupalc/";
chdir($path);

// include needed files
include_once('includes/bootstrap.inc');
include_once('includes/database.inc');
//include_once('includes/database.mysql.inc'); // Disable this for drupal 6.

// Launch drupal start: configuration and database bootstrap
conf_init();
drupal_bootstrap(DRUPAL_BOOTSTRAP_CONFIGURATION);
drupal_bootstrap(DRUPAL_BOOTSTRAP_DATABASE);

// Page start. Output page as an Excel file download.
header("Content-type: application/vnd.ms-excel");
header("Content-Disposition: attachment; filename=\"excel_download.xls\"");
header("Pragma: no-cache");
header("Expires: 0");

// table header
echo "<table border='1'>";
db_query("SELECT * FROM users"); // access to database.
// more processing ...
echo "</table>";

?>

Friday, June 4, 2010

C#.Net recover password by email

In C#.Net 2005, the asp:PasswordRecovery control by default use User Name to recover password. But sometimes the user may forget user name, and User Email is used instead. For this we can do it this way (from here):

In aspx page:
<asp:PasswordRecovery Id="PasswordRecovery1" runat="server" OnVerifyingUser="PasswordRecovery1_VerifyingUser">
</asp:PasswordRecovery>

In Code behind:
protected void PasswordRecovery1_VerifyingUser(object sender, LoginCancelEventArgs e) {
   PasswordRecovery1.UserName = Membership.GetUserNameByEmail(PasswordRecovery1.Us erName);
}

Thursday, June 3, 2010

Javascript resources

- Unbelievably easy javascript for sortable table header columns: Available here.
- Calendar date picker: datepickercontrol. Available here.
- Slider: Easy slider.

Wednesday, June 2, 2010

The Longest Palindrome problem

See here for a linear solution.

Another blog for linear solution.

Another linear solution is to use suffix tree.

More Effective C++

More Effective C++

    Basics
  1. Pointers and References.
    - A reference must be initialized. There is no null reference.
    - result of the following is undefined:
    char *pc = 0; // set pointer to null
    char& rc = *pc; // make reference refer to
    - Reference is more efficient, b/c there is no need to test its validity.
    - Pointers should generally be tested against NULL first.
    - A pointer can be reassigned, but a reference does not change.
    - certain operators need to use reference, e.g., [].

  2. Prefer C++-style casts. (over C-style cast: (type) expression)
    - static_cast (similar to C-style cast in fxn): static_cast(expression)
    - const_cast: cast away the constness or volatileness of an expression. enforced by compiler
    - dynamic_cast: perform safe casts down or across an inheritance hierarchy. Failed casts are indicated by a null pointer (when casting pointers) or an exception (when casting references).
    - reinterpret_cast: result is implementation-defined. rarely portable.

  3. Never treat arrays polymorphically.
    - not able to distinguish between base type and derived type for correct polymorphism.

  4. Avoid gratuitous default constructors.

  5. Operators
  6. Be wary of user-defined conversion functions.
    - Single-argument constructors
    - Implicit type conversion operators (better avoid)

  7. Distinguish between prefix and postfix forms of increment and decrement operators.
    - E.g. Class UPInt. prefix ++ returns reference, postfix ++ returns const object.
    - i ++++ is inhibited.
    - i ++ is less efficient because it creates a temporary copy of its return value.

  8. Never overload &&, ||, or ,.
    - otherwise it'll lose short-circuit semantics, and sequence of evaluation becomes uncertain.

  9. Understand the different meanings of new and delete.
    - new operator: 1) allocates memory, 2) calls constructor
    - operator new: does memory allocation only. knows nothing about constructor
    - placement new
    - Deletion and Memory Deallocation
    - Array

  10. Exceptions
  11. Use destructors to prevent resource leaks.
    - pointer operation may lead to memory leak if exception is thrown
    - a possible solution is to use local object instead of pointer, with help of smart_ptr, or STL auto_ptr.

  12. Prevent resource leaks in constructors.
    - destructor deletes only FULLY constructed objects. So if an exception is thrown in constructor, destructor won't be called.

  13. Prevent exceptions from leaving destructors.
    - if control leaves a destructor due to an exception while another exception is active, C++ terminates the program.
    - stack unwinding.

  14. Understand how throwing an exception differs from passing a parameter or calling a virtual function. (more reading needed)

  15. Catch exceptions by reference.
    - four standard exceptions: 1) bad_alloc (thrown when operator new (see Item 8) can't satisfy a memory request), 2) bad_cast (thrown when a dynamic_cast to a reference fails; see Item 2), 3) bad_typeid (thrown when dynamic_cast is applied to a null pointer), and 4) bad_exception (available for unexpected exceptions).

  16. Use exception specifications judiciously. (more reading needed)

  17. Understand the costs of exception handling.

  18. Efficiency
  19. Remember the 80-20 rule.

  20. Consider using lazy evaluation. (more reading needed)

  21. Amortize the cost of expected computations.
    - over eager evaluation, caching
    - prefetching

  22. Understand the origin of temporary objects.

  23. Facilitate the return value optimization.

  24. Overload to avoid implicit type conversions.

  25. Consider using op= instead of stand-alone op.

  26. Consider alternative libraries.

  27. Understand the costs of virtual functions, multiple inheritance, virtual base classes, and RTTI.
    - virtual table (vtable)
    - RTTI: runtime type identification

  28. Techniques
  29. Virtualizing constructors and non-member functions.

  30. Limiting the number of objects of a class.

  31. Requiring or prohibiting heap-based objects.

  32. Smart pointers.

  33. Reference counting.
    - a simple form of garbage collection.

  34. Proxy classes.

  35. Making functions virtual with respect to more than one object.

  36. Miscellany
  37. Program in the future tense.

  38. Make non-leaf classes abstract.

  39. Understand how to combine C++ and C in the same program.
    - name mangling
    - initialization of statics
    - dynamic memory allocation
    - data structure compatibility

  40. Familiarize yourself with the language standard.

  41. Recommended Reading
    An auto_ptr Implementation

Tuesday, June 1, 2010

Effective C++

Scott Meyers' Effective C++ (1997)

    Shifting from C to C++

  1. Prefer const and inline to #define
    - Value by #define does not go to symbol table, but processed by preprocessor.
    - For const pointer, needs to be like const char * const a = "zzz";
    - Class-specific constants: in class declaration: "static const int a;", need to define outside class.

  2. Prefer <iostream> to <stdio.h>
    - stdio.h is not type-safe and not extensible.
    - e.g. friend ostream& operator<<(ostream& s, const Rational& r);
    - iostream is in std (preferred), iostream.h is in global range.

  3. Prefer new/delete to malloc/free
    - Reason: malloc/delete do not know constructor/destructor

  4. Prefer C++ style comments (// ...) over C'(/* ... */)
    - Note some preprocessors only recognize /* ... */

  5. Memory management

  6. Use the same form in corresponding uses of new and delete.
    - Example:
    string *stringPtr1 = new string;
    string *stringPtr2 = new string[100];
    ...
    delete stringPtr1; // delete an object
    delete [] stringPtr2; // delete an array of

  7. Use delete on pointer members in destructors
    - Delete a NULL pointer does no harm (free a NULL pointer causes error though)
    - One way to avoid using delete is to use smart pointers (e.g. auto_ptr in STL)

  8. Be prepared for out-of-memory conditions (more reading needed..)
    - When new fails, it throws an exception std::bad_alloc (in old compilers, it may return NULL)
    - assert is a macro. It does not work when NDEBUG is defined.

  9. Adhere to convention when writing operator new and operator delete. (more reading needed..)

  10. Avoid hiding the "normal" form of new.
    - Declare a function called "operator new" inside the class would block access to the "normal" form of new.
    - Two solutions: 1) overload operator new, 2) provide default value for additional parameters.
    - Example:
    class X {
    public:
    void f();
    static void * operator new(size_t size, new_handler p);
    static void * operator new(size_t size)
    { return ::operator new(size); }
    };
    X *px1 = new (specialErrorHandler) X; // calls X::operator new(size_t, new_handler)
    X* px2 = new X; // calls X::operator new(size_t)

  11. Write operator delete if you write operator new. (new/delete should be paired) (more reading needed..)

  12. Constructors, Destructors and Assignment Operators

    Almost every class has one or more constructors, a destructor, and an assignment operator.
  13. Declare a copy constructor and an assignment operator for classes with dynamically allocated memory.

  14. Prefer initialization to assignment in constructors. (more reading needed..)

  15. List members in an initialization list in the order in which they are declared.
    - Otherwise there is overhead for compiler to track information.

  16. Make sure base classes have virtual destructors.
    - Base class virtual destructor should be used when base class has virtual fxns.
    - No virtual fxns in a base class often means it's not suitable to be a base class.
    - When need an abstract class, it may be convenient to declare destructor as pure virtual destructor, but then a definition of it should also be defined.

  17. Have operator= return a reference to *this. (more reading needed..)
    - So as to be able to chain assignments together (assignment is right associative)

  18. Assign to all data members in operator=. (more reading needed..)

  19. Check for assignment to self in operator=. (more reading needed..)

  20. Classes and Functions: Design and Declaration
  21. Strive for class interfaces that are complete and minimal.

  22. Differentiate among member functions, non-member functions, and friend functions.
    - Member fxns can be virtual, non-member fxns can't.
    - Operator>> and operator<< are never members.
    - Only non-member functions get type conversions on their left-most argument.
    - Everything else should be a member function.

  23. Avoid data members in the public interface.
    - Use access/inline functions instead of data members.

  24. Use const whenever possible. (more reading needed)
    - const value and const pointer
    - mutable
    - const_cast()

  25. Prefer pass-by-reference to pass-by-value.
    - The meaning of passing an object by value is defined by the copy constructor of that object's class. This can be expensive.
    - Bad use: Student returnStudent(Student s) { return s; }
    - Good use: const Student& returnStudent(const Student& s) { return s; }
    - Slicing problem. (Pass by base class type will cut off derived class members.)
    - Aliasing.
    - Reference is implemented by pointer.

  26. Don't try to return a reference when you must return an object.
    - E.g., operator* should return an object instead of reference.

  27. Choose carefully between function overloading and parameter defaulting.
    - 2 questions: 1) is there a value you can use for a default? 2) how many algorithms do you want to use?

  28. Avoid overloading on a pointer and a numerical type.

  29. Guard against potential ambiguity. (more reading needed)

  30. Explicitly disallow use of implicitly generated member functions you don't want.
    - E.g. operator=

  31. Partition the global namespace. (more reading needed)

  32. Classes and Functions: Implementation
  33. Avoid returning "handles" to internal data.

  34. Avoid member functions that return non-const pointers or references to members less accessible than themselves.

  35. Never return a reference to a local object or to a dereferenced pointer initialized by new within the function.
    - e.g. this is bad because the difficulty of applying delete:
    inline const Rational& operator*(const Rational& lhs, const Rational& rhs)
    { Rational *result = new Rational(lhs.n * rhs.n, lhs.d * rhs.d); return *result; }

  36. Postpone variable definitions as long as possible.
    - instead of "string encrypted; encrypted = password;", use "string encrypted = password;", this avoids calling default constructor on string.

  37. Item 33: Use inlining judiciously.
    - inline function used extensively may increase code size a lot.
    - inline, like "register", is only a hint to compiler.
    - uninlined inline function, in old rule, is treated as static and included into every translation unit.
    - library needs careful consideration on inline function, inline functions make it impossible to provide binary upgrades to the inline functions in a library - all clients have to recompile.
    - inline function should avoid using static variable.
    - most debuggers have problem with inline function.

  38. Minimize compilation dependencies between files.
    - should do: replacement of dependencies on class definitions with dependencies on class declarations
    - Avoid using objects when object references and pointers will do.
    - Use class declarations instead of class definitions whenever you can.
    - Don't #include header files in your header files unless your headers won't compile without them.
    - Handle/body class, envelope/letter class.

  39. Inheritance and Object-Oriented Design
  40. Make sure public inheritance models "isa."
    - isa == public inheritance
    - Two other common inter-class relationships are "has-a" and "is-implemented-in-terms-of."

  41. Differentiate between inheritance of interface and inheritance of implementation. (more reading needed)

  42. Never redefine an inherited nonvirtual function.
    - nonvirtual - statically bound
    - virtual - dynamically bound

  43. Never redefine an inherited default parameter value.
    - default parameters are statically bound!

  44. Avoid casts down the inheritance hierarchy.
    - down cast: from a base class pointer to a derived class pointer
    - down cast leads to a maintenance nightmare
    - safe downcasting: by using dynamic_cast

  45. Model "has-a" or "is-implemented-in-terms-of" through layering.
    - difference between isa and is-implemented-in-terms-of

  46. Differentiate between inheritance and templates. (more reading needed)

  47. Use private inheritance judiciously. (more reading needed)
    - compilers will generally not convert a derived class object into a base class object if the inheritance relationship between the classes is private.
    - members inherited from a private base class become private members of the derived class, even if they were protected or public in the base class.
    - private inheritance means is-implemented-in-terms-of.
    - use layering whenever you can, use private inheritance whenever you must.
    - template-induced code bloat. It is not a good thing.

  48. Use multiple inheritance (MI) judiciously. (more reading needed)
    - MI leads to many problems, one is ambiguity (diamond inheritance).

  49. Say what you mean; understand what you're saying.

  50. Miscellaneous
  51. Know what functions C++ silently writes and calls.
    - default constructor, destructor, assignment/copy constructor, address-of operator, const address-of operator.

  52. Prefer compile-time and link-time errors to runtime errors.

  53. Ensure that non-local static objects are initialized before they're used. (more reading needed)

  54. Pay attention to compiler warnings.

  55. Familiarize yourself with the standard library.

  56. Improve your understanding of C++.

Blog Archive

Followers