Le 23/04/13 20:48, Shamsher Siddiqui a écrit :
hi mentors plz review my project and give me suggestion to improve to my proposal
Name :Shamsher Ahmed
Hi Shamsher, thanks for posting your proposal. I have a general remark. Your proposal is more a list of functionalities than a clear design. H.H. proposal provides a single chrono::date class. I experimented in TBoost Chrono/Date a different approach than the one from H.H. Instead of having a single date class I implemented several classes that model the Date concept. Each class has a different representation and is the more adapted to some kind of functions. I made also the difference between two kind of dates, absolute and relative dates. H.H. has only one date class that has a 'flag' to signal if it is relative or absolute. Each one of these classes is convertible to the other classes making a transformation of the representation. It is not clear how your library proposal positions respect to Howard Hinnant proposal or mine. What are the functions a class date or a model of a concept Date must provide. What do you think of date iterators? What about I/O I don't know if you will have enough time to implement several calendars. I think the best would be to provide a good interface for the Gregorian calendar, by discussing a lot on this ML. It would be great if you mark the features as MUST, SHOULD, and COULD in order to make clear the priorities. Would you start from the H.H implementation, mine or would start from a white page. It would be very important to include in the proposal performances measures for some of the functions depending on the representation. More comments below. Best, Vicente
Project Proposal Goals & Implemenatations
1) Construction of Date: • Date can be represented in two ways field representation or as an serial representation . In field based representation(YMD) date value is constructed from individual year,month,and day value in three integral value. In serial reprensentation(SERIAL) data values are stroed in intergral number of days from an implementation defiend epoch date, there is third hybrid version to represent the date which implemantd the both representation and it is named HH_YMD_SERIAL_X where x represents the size of types in byte. What representation would you choose for your library? • Providing support for entering the date in form YDM(year,day,month) which is lacking currently in chrono:date library Humm, Are you referring to the H. Hinnant Proposal or my implementation on TBoost.Chrono/Date? Why do you think that this constructor is missing?
• No invalid dates can be entered considering range cheaking ,non existent date if entered bad_date exception is thrown . Does it means that the constructor would always check for a valid date? For performances reasons it has been requested too many times to be able to build a date without validating. This doesn't mean that the simple way would not use validation. • Constructing constant object for day,week_day.
Eg. last/may/2000 represents 31 may 2000 • Construction of meta data for date 1) Leap year flag 2) Nth day of month 3) Nth weekday month Could you elaborate on this?
2) Arithematic Operation On date
Date airthematic can be done on three units i.e day,month,year.In chrono date ::calendar(Gregorian calendar) length of month and year is not fixed : • day arithematic 1) Adding number of days to date until range doesn’t exceed What do you mean by "until range doesn't exceed"?
3) InterConversion field representation & serial representation
Some operation are quite fast on field but airthematic operation are much faster on serial campared field representation .So it is necessary to provide the inter-coversion so that it can be easily converted from one representation to another. 1) Constructing bi-directional conversion of serial and field by making use of static cache to optimize conversion Do you mean that you pretend to memoize the conversions?
4) Building function for week days & date formatting
1) weekday of a date used. 2) nextweek day of date used. 3) previous weekday of date used. 4) finding number of weeks in month 5) formatting of date according of all types
5)Interoperability with other calendar
Current chrono::calendar is Gregorian calendar which exist everywhere in date & time library of every programming language.(c,c++,java) and ISO 8601 and POSIX. This section provides conversion of chrono calendar to client calendar. 1) Conversion of chrono ::calendar to Julian Calendar 2) Conversion of chrono :: calendar to Hebrew calendar 3) Conversion of chrono :: calendar to hindu calendar 4) Conversion of chrono :: calendar to Chinese calendar 5) Conversion of chrono :: calendar to Buddhist calendar 6) Conversion of chrono :: calendar to Islamic calendar Hindu ,Chinese ,Buddhist ,Hebrew(Jewish ) calendars are lunisolar calendar with a very little difference. Julian, Gregorian are very much similar except the method of finding the leap year. Islamic calendar is lunar calendar(totally dependent on moon ) which is quite unpredicatable. Hence accurate conversion is rare.