macmade/cfpp

C++ wrapper for CoreFoundation base classes.

💀🦄🤖 Blood, Sweat & Code (& Rock 'n Roll)

cfpp's Issues

Windows build is broken

Version 0.1.0 is broken on Windows using VisualStudio.

CFStreamProperty symbols on Windows

The use of CFStreamProperty symbols prevents CoreFoundation.dll to be delay-loaded.

E.g.:

__imp__kCFStreamPropertyFileCurrentOffset

Localisation functions

Declared in CFBundle:

String GetLocalizedString( String key, const char * comment );
String GetLocalizedStringFromTable( String key, String tableName, const char * comment );
String GetLocalizedStringFromTableInBundle( String key, String tableName, Bundle bundle, const char * comment );
String GetLocalizedStringWithDefaultValue( String key, String tableName, String value, const char * comment );

CF::Error - Ambiguous constructors

Constructors of CF::Error are ambiguous due to implicit casts to CF::String from std::string, CFTypeRef, CFStringRef, and const char *.

Simpler operators

Operators should call themselves whenever possible, in order to remove duplicate code.

Eg: CF::URL::operator = ( CFURLRef ) should simply call CF::URL::operator = ( CFTypeRef ).

how to read/write plist file

how to read/write plist file

README typo and grammar

"CoreFoundation is an powerfull C API, allowing object-oriented style coding in C, reference counting memory management, and providing a lot of useful classes."

Should be:

"CoreFoundation is a powerful C API which allows object-oriented style coding and reference counting memory management in C and provides a lot of useful classes."

CF::ReadStream::Iterator

Creates an iterator class for CF::ReadStream(forward iterator) using CF::Data.

String::operator [] may not work

As the function uses CFStringGetCStringPtr, it may fails, depending on the encoding.

Thus, the operator is not reliable.

Unit tests

Finish unit tests for all CF++ classes, so planned features may be implemented safely.

Code coverage should ideally be around 95%.

CF::Number - Support for CFIndex

Try to add support for CFIndex in CF::Number. Actual conversion is ambiguous.

Dictionary constructor doesn't take ints.

According to the readme CF::Dictionary d3( 100 ); is valid for constructing a dictionary with an initial capacity. If I do this I get error Types CF::Dictionary and int are not compatible. As well, I don't see a constructor for int in the Dictionary header.

STL iterators

Add STL iterators for CF::Array, CF::Dictionary, and maybe CF::String and CF::Data.

CF::String::Iterator - C++11 optimisations

Optimize CF::String::Iterator using std::shared_ptr in order to avoid copying the C string buffer in the copy constructor.

Take ownership constructors for wrapper types

I can envision a factory function for CFPP types conceptually similar to CFBridgingRelease from ARC-enabled Objective-C. The purpose of which is to assign a CF object to a wrapper and release it. The most obvious benefit would be the ability to write code like CF::Array components = CFStringCreateArrayBySeparatingStrings(NULL, string, separator).

I'm planning on using CFPP in a project and I'm probably going to implement this functionality for that purpose. If you aren't opposed to the idea on principle I'd be happy to Pull Request it.

CF::String lacks a 'const unsigned char *' ctor

No big deal, but sqlite3_column_text returns const unsigned char *, would be a useful addition ;)

C++11: initializer list

Add support for std::initializer_list in CF::Array, CF::Data, and CF::Dictionary.

CF::Number - Float comparison

Ensure comparison of floating point values are correct on CF::Number.

Tag a version?

When using this library it would be quite useful to be able to reference a specific version and know what snapshot of the code it represents.

I see milestones are already used for the roadmap items. It appears that all outstanding issues are marked for v0.3.0+. Could we tag current master as v0.2.0 for a reference point?

CF::Number - Assignment operators with an invalid CF::Number object

Invalid CF::Number objects should be treated as zero.

Improvement: FromPropertyList overloads which accept CF::Data

Again, nice to parse blobs!

CF::Dictionary::ContainsKey crash if key is std::string

Consider the following example:

CF::Dictionary dic;
dic << CF::Pair( "Key", "Value" );
CF::String value = dic[ "Key" ]; //no problem.
bool contains = dic.ContainsKey( "Key" ); //crash
contains = dic.ContainsKey( CF::String( "Key" ) ); //OK.

CF::Pair's ctor accepts std::string. CF::Dictionary's subscript operator accepts std::string too. Wouldn't it make sense for ContainsKey to behave the same?

More explicit constructors

The following should not be valid:

CF::Dictionary d;
d = true;

Call is:

d.operator=( CF::Dictionary( ( CFIndex )true ) );

Use explicit constructors to fix the issue...