WebSocket++ 0.4.0 release

127 views
Skip to first unread message

Peter Thorson

unread,
Nov 4, 2014, 9:15:25 AM11/4/14
to websocketpp-...@googlegroups.com

Summary


This release includes a number of bug fixes and code/api housekeeping. There is a small handful of minor API breaking changes from 0.3.0. Even so, upgrading from 0.3.0 to 0.4.0 should be straight forward for all users and is highly encouraged.


Breaking Changes

Exception Type Change

The primary breaking change is the change in the type of exceptions that WebSocket++ throws. Prior to version 0.4.0 exceptions were thrown with a custom type `websocketpp::lib::error_code`. This presented a number of issues, primarily relating to not deriving from the standard `std::exception` base and not matching the semantics of `std::exception`.


Starting in version 0.4.0 all exceptions thrown by WebSocket++ will be of type `websocketpp::exception` which derives from `std::exception`. This normalizes all exception types under the standard exception hierarchy and allows WebSocket++ exceptions to be caught in the same statement as others. The error code that was previously thrown is wrapped in the exception object and can be accessed via the websocketpp::exception::code() method.


Custom Logging Policy Change

The API for building custom logging policies has been updated to be slightly more generic. In particular it no longer mandates the use of `std::ostream`. As a result any custom logging policies will need to change/add a few constructors to match the new API. All logging policies bundled with WebSocket++ (the stub/none policy and the default ostream logger) have been updated. If you only use the default logging policies there are no changes you need to make.


Utility method signatures

Three utility methods have had their signatures updated. These methods are not part of WebSocket++’s public API but some users may use the bundled versions in leu of including their own libraries for convenience. If you are using any of these utility methods you may need to update your call sites:


The following methods were prefixed to work around macros in some operating systems with similar names:

`websocketpp::lib::net::htonll` -> `websocketpp::lib::net::_htonll`

`websocketpp::lib::net::ntonll` -> `websocketpp::lib::net::_ntonll`


The following methods have had length parameters changed to size_t from various less specific integer types

`websocketpp::base64_encode(unsigned char const *, unsigned int)` -> `websocketpp::base64_encode(unsigned char const *, size_t)`


`websocketpp::sha1::calc(void const *, int, unsigned char *)` -> `websocketpp::sha1::calc(void const *, size_t, unsigned char *)`


Other Changes

- Adds minimal_client and minimal_server configs. These configs have the absolute minimal set of dependencies possible. They are not complete but can be used as a base class for creating custom configs that avoid the dependencies introduced by the core configs.


- The core library no longer depends on std::iostream. The iostream transport and ostream logging policy still do, however, so to use the library without std::iostream use the minimal config and supply your own iostream free transport and logging policies.


- The library should now automatically detect C++11 settings for many more compilers. Recent versions of clang and gcc (4.7+) should no longer need any configuration defines to use WebSocket++ in C++11 mode. Simply compiling with -std=c++11 should be sufficient. 


- A thread safety issue related to the use of std::localtime has been fixed

- A number of minor fixes for cmake builds and builds using Visual Studio

- A minor code cleanup that normalized whitespace, removed unused functions and parameters, etc. This should assist users who are building with -Werror


Roadmap


- Continue cleaning up documentation and build/compatibility issues, especially with CMake and Visual Studio.

- Continue watching the development of permessage-deflate extension and merge that branch once we get a final spec.

- Finish tutorials

- Continue work on custom message buffer policies

Reply all
Reply to author
Forward
0 new messages