Check in the pristine copy of ICU 4.6...

icu46/source/i18n/tmunit.cpp

Index: icu46/source/i18n/tmunit.cpp
===================================================================
--- icu46/source/i18n/tmunit.cpp	(revision 0)
+++ icu46/source/i18n/tmunit.cpp	(revision 0)
@@ -0,0 +1,117 @@
+/*
+ *******************************************************************************
+ * Copyright (C) 2008-2010, Google, International Business Machines Corporation and
+ * others. All Rights Reserved.
+ *******************************************************************************
+ */
+
+#include <typeinfo>  // for 'typeid' to work
+
+#include "unicode/tmunit.h"
+
+#if !UCONFIG_NO_FORMATTING
+
+U_NAMESPACE_BEGIN
+
+UOBJECT_DEFINE_RTTI_IMPLEMENTATION(TimeUnit)
+
+
+/*
+ * There are only 7 time units.
+ * So, TimeUnit could be made as singleton 
+ * (similar to uniset_props.cpp, or unorm.cpp,
+ * in which a static TimeUnit* array is created, and 
+ * the creatInstance() returns a const TimeUnit*).
+ * But the constraint is TimeUnit is a data member of Measure.
+ * But Measure (which is an existing API) does not expect it's "unit" member
+ * as singleton. Meaure takes ownership of the "unit" member.
+ * In its constructor, it does not take a const "unit" pointer.
+ * Also, Measure can clone and destruct the "unit" pointer.
+ * In order to preserve the old behavior and let Measure handle singleton "unit",  
+ * 1. a flag need to be added in Measure; 
+ * 2. a new constructor which takes const "unit" as parameter need to be added,
+ *    and this new constructor will set the flag on.
+ * 3. clone and destructor need to check upon this flag to distinguish on how
+ *    to handle the "unit". 
+ * 
+ * Since TimeUnit is such a light weight object, comparing with the heavy weight
+ * format operation, we decided to avoid the above complication.
+ * 
+ * So, both TimeUnit and CurrencyUnit (the 2 subclasses of MeasureUnit) are
+ * immutable and non-singleton.
+ *
+ * Currently, TimeUnitAmount and CurrencyAmount are immutable.
+ * If an application needs to create a long list of TimeUnitAmount on the same
+ * time unit but different number, for example,
+ * 1 hour, 2 hour, 3 hour, ................. 10,000 hour,
+ * there might be performance hit because 10,000 TimeUnit object, 
+ * although all are the same time unit, will be created in heap and deleted.
+ *
+ * To address this performance issue, if there is any in the future,
+ * we should and need to change TimeUnitAmount and CurrencyAmount to be 
+ * immutable by allowing a setter on the number.
+ * Or we need to add 2 parallel mutable classes in order to 
+ * preserve the existing API.
+ * Or we can use freezable.
+ */
+TimeUnit* U_EXPORT2 
+TimeUnit::createInstance(TimeUnit::UTimeUnitFields timeUnitField, 
+                         UErrorCode& status) {
+    if (U_FAILURE(status)) {
+        return NULL;
+    }
+    if (timeUnitField < 0 || timeUnitField >= UTIMEUNIT_FIELD_COUNT) {
+        status = U_ILLEGAL_ARGUMENT_ERROR;
+        return NULL;
+    }
+    return new TimeUnit(timeUnitField);
+}
+
+
+TimeUnit::TimeUnit(TimeUnit::UTimeUnitFields timeUnitField) {
+    fTimeUnitField = timeUnitField;
+}
+
+
+TimeUnit::TimeUnit(const TimeUnit& other) 
+:   MeasureUnit(other) {
+    *this = other;
+}
+
+
+UObject* 
+TimeUnit::clone() const {
+    return new TimeUnit(*this);
+}
+
+
+TimeUnit&
+TimeUnit::operator=(const TimeUnit& other) {
+    if (this == &other) {
+        return *this;
+    }
+    fTimeUnitField = other.fTimeUnitField;
+    return *this;
+}
+
+
+UBool 
+TimeUnit::operator==(const UObject& other) const {
+    return (typeid(*this) == typeid(other)
+            && fTimeUnitField == ((TimeUnit*)&other)->fTimeUnitField);
+}
+
+
+TimeUnit::UTimeUnitFields
+TimeUnit::getTimeUnitField() const {
+    return fTimeUnitField;
+}
+
+
+TimeUnit::~TimeUnit() {
+}
+
+
+U_NAMESPACE_END
+
+#endif
Property changes on: icu46/source/i18n/tmunit.cpp
___________________________________________________________________
Added: svn:eol-style
   + LF