Hi Kin,
It looks like you discovered something. I've tried it on the iPhone Simulator
and it doesn't work right, like you said. However, it _does_ work on the device.
Thanks,
On 11 Νοε 2011, at 3:17 μ.μ., Kin Mak wrote:
> Hi Nick,
>
> The code works fine in iOS 4.3 or earlier, but not anymore on iOS 5.0. I
> didn't try it on Mac OSX tough
> But if you try the code on different versions of iOS, the result may not be
> the same.
>
> Don Quixote,
> Thanks for your tips of using assert. I am now wondering if there is anything
> to do with memory instead.
> In fact after reading your email, I have written a simple UnitTestCase using
> a similar approach, namely using STAssertNotNil :
>
> - (void)testFormatter {
>
> NSDateFormatter *formatter = [[NSDateFormatter alloc] init];
> [formatter setDateFormat:@"yyyy-MM-dd HH:mm:ss.SSS zzz"];
> NSString *currentString = @"2011-11-11 11:00:00.000 CET";
> NSDate *date = [formatter dateFromString:currentString];
> [formatter release];
>
> STAssertNotNil(date, @"Formatter failed to convert", nil);
>
> }
>
> This simple unit test works fine on iOS 4 with simulator iOS 4.3, but fails
> on iOS 5 with simulator iOS 5.0.
> I'll now turn on Guard Malloc, and see if I can find out something more.
>
>
> Thanks for the advice/help from you two.
>
> Thanks again,
> Kin
>
>
> On Nov 11, 2011, at 7:42 PM, Don Quixote de la Mancha wrote:
>
>>> On 11 Νοε 2011, at 10:13 π.μ., Kin Mak wrote:
>>>> The following code used to work fine prior to iOS 5. The dateFromString
>>>> method seems to stop working on iOS 5 and always returns null.
>>
>> 2011/11/11 Νικόλας Τουμπέλης <nicktoumpe...@gmail.com>:
>>> I've tried the snippet in both Mac OS X and iOS and found that it still
>>> works. What are you doing prior to calling dateFromString: ?
>>
>> Kin,
>>
>> Does dateFromString also return NULL in the Simulator?
>>
>> If it works for Nick but not for you, possibly there is a bug
>> elsewhere in your own code that is screwing up the date formatter.
>> The fact that it returns NULL suggests that a memory allocation
>> failed. You're not likely running out of memory, but a corrupt heap
>> could cause allocations to fail.
>>
>> Try turning on all the malloc diagnostics in your debug build's scheme
>> editor. Enable Guard Malloc when running in the Simulator. (Guard
>> Malloc is not yet supported on devices.)
>>
>> Try calling dateFromString as the very first line of code in main().
>> If it works there but not in your original code, you probably have a
>> bug that occurs in the time duration from the entry of main until you
>> reach your original code. If you think that could be the case, use a
>> binary search to narrow the problem down, by estimating where the
>> halfway point in time is, testing there, and so on.
>>
>> In general, it is useful to everyone to make liberal use of the
>> assert() macro. I cannot emphasize this enough. I call assert() "The
>> Test That Keeps On Testing". Even if none of your assertions are
>> presently failing, if you leave them in your code and keep them
>> enabled in debug builds, it is quite likely that introducing a bug at
>> some point in the future will trip one of your existing assertions.
>>
>> The easiest way to use assert() is to validate all of the parameters
>> to each of your methods and functions. Such asserts also serve to
>> document the API or your methods and functions far better than do
>> comments. While comments have no particular requirement that they be
>> updated to keep them in sync with code changes, changing your APIs
>> without also revising your assertions will cause them to trip.
>>
>> Use assert() only to test for conditions that cannot possibly happen
>> except as a result of programmer errror. Do not use them to test for
>> runtime failures or user error. Use some other means of error
>> recovery for that.
>>
>> Your program should behave in precisely the same way whether or not
>> assertions are enabled. Having them enabled will make your executable
>> file a little bigger and your App will run a little slower, but the
>> difference in speed will just about always be insignificant to the
>> user.
>>
>> The following code is quite *WRONG*, because it uses assert() to check
>> for a failure that can happen as a result of limited system resources:
>>
>> - (unsigned char*) foo
>> {
>> unsigned char *result;
>>
>> result = malloc( kBufferSize );
>>
>> assert( NULL != result ); // This is a bug!
>>
>> [initBuf result];
>>
>> return result;
>> }
>>
>> However, the following is a correct use of assert. We handle the
>> memory allocation failure gracefully, then assert that the buffer
>> pointer is non-NULL upon entry to a method that requires pointers to
>> be valid:
>>
>> - (unsigned char*) foo
>> {
>> unsigned char *result;
>>
>> result = malloc( kBufferSize );
>> if ( NULL == result )
>> return result;
>>
>> [initBuf result]; // We are now certain result is not NULL
>>
>> return result;
>> }
>>
>> - (void) initBuf: (unsigned char*) bufPtr
>> {
>> assert( NULL != bufPtr ); // Correct use of assert
>> ...
>> return;
>> }
>>
>> Hope That Helps,
>>
>> Don Quixote
>> --
>> Don Quixote de la Mancha
>> Dulcinea Technologies Corporation
>> Software of Elegance and Beauty
>> http://www.dulcineatech.com
>> quix...@dulcineatech.com
>> _______________________________________________
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/cocoa-dev/kinmak%40me.com
>>
>> This email sent to kin...@me.com
>
--
Nick :wq
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
