Main BLOGGER

Friday, January 26, 2007

add sound card to vmware server virtual machine

If your virtual machine does not have a virtual sound adapter in the virtual machine configuration file (.vmx)

With the virtual machine powered off, try adding the following lines to the end of the .vmx file

sound.present = "TRUE"
sound.virtualDev = "es1371"
sound.fileName = "-1"
sound.autodetect = "TRUE"

Then you can use wmware server virtual machine configuration to point the sound card to your host machine physical sound card.

--
Pop (Pu Liu)

- posted by Pop @ 9:26 AM

Tuesday, January 23, 2007

UML learning stuff

Java modeling: Summary

Document options

Document options requiring JavaScript are not displayed

		Print this page
		E-mail this page
		Discuss

Rate this page

Help us improve this content

Level: Introductory

Granville Miller (rmiller@togethersoft.com), Mentor, TogetherSoft

01 Jun 2002

Welcome to Java modeling, a monthly column for Java developers that examines best practices in the UML, a standard notation for modeling object-oriented systems. The column begins with some introductory articles to build a foundation, but will quickly move to more advanced applications. All of the articles are presented here for your convenience.

A UML workbook, Part 4
June 2002
Level: Introductory
Granville Miller re-opens the UML workbook for an in-depth discussion of one of the fundamental components of the use case diagram: the actor. The actor is not only essential in UML modeling, it can also play an important role in creating Java applications and may even suggest patterns in J2EE application design. Follow along as Granville uses sequence and class diagrams to explain the role of the actor in use case diagramming and Java application development.

Holonic software development, Part 2
October 2001
Level: Introductory
Granville Miller continues his discussion of holonic software development, with a conceptual overview of requirements gathering. Find out how the four most common requirements gathering processes -- features, user stories, use cases, and the traditional software requirements specification -- fit into the larger context of an agile software development process.

Holonic software development, Part 1
August 2001
Level: Introductory
Granville Miller temporarily abandons the topic of requirements gathering for one more compelling: holonic software development. Find out how this method complements and extends the tenets of the agile development movement, and how its emergence into mainstream development circles may alter the education of software developers, as well as the practice of software development.

A UML workbook, Part 3
June 2001
Level: Introductory
Granville leads you into the gray zone between modeling and method, with a look at requirements gathering via use case modeling. In particular, he focuses on the relationship between user interfaces, system interfaces, and use case descriptions. While tempting to do so, it is generally considered bad form to include user interface logic in a use case. Follow along as Granville uses sequence diagrams and system interfaces to show you why.

A UML workbook, Part 2
June 2001
Level: Introductory
Granville continues his discussion of the Unified Modeling Language and sequence diagramming. He examines the role of conditional logic in sequence diagramming and discusses why you might choose to include or exclude conditions and loops from a diagram. Granville also describes the two forms of sequence diagram -- generic and instance -- and explains their respective applications in the development cycle.

A UML workbook, Part 1
May 2001
Level: Introductory
In this first installment of his new column, Granville Miller introduces one of the building blocks of the Unified Modeling Language: sequence diagramming. Sequence diagrams are used throughout the design process to demonstrate the internal interactions between actors and objects as a system executes over time. Follow along with Granville as he creates one of these diagrams, using a loan processing application as his example.

--
Pop (Pu Liu)

- posted by Pop @ 11:28 AM

Monday, January 22, 2007

two articles about C++ assignment operator

http://icu.sourceforge.net/docs/papers/cpp_report/the_anatomy_of_the_assignment_operator.html

class TFoo : public TSuperFoo { 
    TBar* fBar1; //TBar is monomorphic (1)
     TBar* fBar2;
    // various method definitions go here...
}

//Do not need to be a virtual function 
TFoo& const  //considering: a=b=c and (a=b)=c
TFoo::operator=(const TFoo& that) 
{
//step 1
    if (this == &that) //compare address of this and that
       retur *this;

//step 2
    TBar* bar1 = 0;  //make memory allocation a transaction
    TBar* bar2 = 0;
    try {
         bar1 = new TBar(*that.fBar1);//make a copy, see  (1)
         bar2 = new TBar(*that.fBar2);
         TSuperFoo::operator=(that); //copy super's members 
    }
    catch (...) {
         delete bar1;
         delete bar2;
         throw;
    }

//step 3
    delete fBar1; //free fBar1 
    fBar1 = bar1; //call TBar.=()
    delete fBar2;
    fBar2 = bar2;

//step 4
    return *this;
}

(1) If TBar is polymorphic, we need a virtual function like clone() to accomplish the creation.
(2) Owning pointer: like fBar1, fBar2, whose lifecycle are the same as the host object of TFoo
--
Pop (Pu Liu)

- posted by Pop @ 11:38 AM

Using copy construction and assign operator

statement:
Using initializer in copy constructor to avoid double initialization for class type members
Do not reuse the same for copy constructor and assign operator even they are doing the same thing!

In C++, assignment and copy construction are different because the copy constructor initializes uninitialized memory, whereas assignment starts with an existing initialized object.
If your class contains instances of other classes as data members, the copy constructor must first construct these data members before it calls operator=.
The result is that these members get initialized twice, as cctest shows. Got it? It's the same thing that happens with the default constructor when you initialize members using assignment instead of initializers.

For example:

CFoo::CFoo() 
{
   m_obj = DEFAULT; // cause double initialization of m_obj, one for m_obj, another for "="
}

As opposed to:

CFoo::CFoo() : m_obj(DEFAULT)
{
}

--
Pop (Pu Liu)

- posted by Pop @ 9:37 AM

C++ virtual destructor

5.3.5.3: "If the static type of the operand is different from its dynamic type, the static type shall be a base class of the operand's dynamic type and the static type shall have a virtual destructor or the behavior is undefined."

1. If C++ had a "sealed" keyword, then the rule would be simpler: If you do a "delete p" where p is a pointer to an unsealed class, then that class needs have a virtual destructor. (The imaginary "sealed" keyword makes it explicit when a class can act as the base class for another class.)

2. If the sizeof or layout of your class is a concern for some reason, making the destructor virtual "costs nothing" if your base class already has a virtual method. You're already carrying a vptr at that point.

3. Classes having virtual functions should always have a virtual destructor. This is necessary since it is likely that you will hold an object of a class with a pointer of a less derived type. Making the destructor virtual ensures that the right code will be run if you delete
the object via the pointer
--
Pop (Pu Liu)

- posted by Pop @ 8:20 AM