Good afternoon.
The wording of the name of this example is a bit confusing

Also, I find it not very efficient to create and delete threads for each new request if the requests need to be sent frequently.

What do you think about it?
Thanks

This field is static. Access to change it is shared by all objects of the class. Creating multiple objects in different threads results in a data race.

Please use a mutex and encapsulate operations with this field.

Example:

using TransferStorage = std::map<TransferImpl*, std::weak_ptr<TransferImpl>>;
static TransferStorage m_TransferMap;
static std::mutex m_TransferMap_mutex;

template<class T>
static std::pair<TransferStorage::iterator, bool> insert_transfer(T&& value) {
  std::lock_guard<std::mutex> lk(m_TransferMap_mutex);
  return m_TransferMap.insert(std::move(value));
}

static size_t erase_transfer(TransferImpl* index) {
  std::lock_guard<std::mutex> lk(m_TransferMap_mutex);
  return m_TransferMap.erase(index);
}

static std::weak_ptr<TransferImpl> get_transfer(TransferImpl* index) {
  std::lock_guard<std::mutex> lk(m_TransferMap_mutex);
  return m_TransferMap[index];
}

On Mac OS X I have:

In file included from LibusbTest.cpp:18:
In file included from ../headers/libusbpp.h:3:
In file included from ../headers/device.h:2:
In file included from ../headers/Configuration.h:5:
In file included from ../headers/interface.h:6:
In file included from ../headers/Endpoint.h:7:
../headers/Transfer.h:4:10: fatal error: 'chrono' file not found
# include <chrono>

 ^

1 error generated.
make: **\* [LibusbTest] Error 1```

I also do not have the `<future>` header.

I guess that is because my C++ compiler (clang) is not yet C++11 compliant.

`$ c++ --version
Apple clang version 3.1 (tags/Apple/clang-318.0.61) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.4.0
Thread model: posix`

I also tried with GCC but I have the same problem:
`$ g++ --version
i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)`

I have a device that has two bulk endpoints with addresses 0x05 and 0x85. Libusbcpp ignores the latter completely for the following reason.

In InterfaceImpl::CreateEndpoints(), a new std::shared_ptr<Endpoint> named pEndpoint is created and then inserted into a std::map like so:

The map key being generated by Endpoint::Number, which is implemented like so:

Since the key omits the upper nibble of the address, it's impossible to store a pair of endpoints with opposite directions but the same endpoint number. The second insert has no effect (because the key already exits), and the newly created Endpoint is deleted.

A subsequent call to Interface::getEPNumberByIndex() throws std::logic_error(LibUSB::InterfaceImpl::getEPNumberByIndex(): Endpoint not found.)

On Mac OS X:

make LibusbTest
c++ -Wall -g -O2 -Wextra -pipe -funsigned-char -fstrict-aliasing -Wchar-subscripts -Wundef -Wshadow -Wcast-align -Wwrite-strings -Wunused -Wuninitialized -Wpointer-arith -Wredundant-decls -Winline -Wformat -Wformat-security -Wswitch-enum -Winit-self -Wmissing-include-dirs LibusbTest.cpp -o LibusbTest
In file included from LibusbTest.cpp:17:
In file included from ./stdafx.h:8:
./targetver.h:8:10: fatal error: 'SDKDDKVer.h' file not found

include <SDKDDKVer.h>

     ^

1 error generated.
make: *** [LibusbTest] Error 1

Please remove any Windows specific code if you want to use your lib on Unix (Linux, Mac OS X, BSD, etc).

There are a few issues which prevent a full build on linux with gcc

• libusb.h include path assumes that the file lies in /libusb/, which might not be true for all systems (on fedora 19 the subdirectory is libusb-1.0). it would be better to just include libusb.h and set the directory as include path via pkg-config.
• std::exception has no constructor which takes a c-string as argument (this seems to be microsoft-specific)
• include file names are not compatible with case-sensitive systems (eg. Interface.h is included as interface.h)

LibUSB::InterfaceImpl::getEndpoint() throws a logic_error exception if the index and endpoint number are not equal. This presents a problem communicating with my USB device, based on the Cypress cy7c68001 chip which only implements endpoints 2,4,6 and 8 in addition to 0. Shouldn't this configuration be handled in Libusbpp?

I can't finde any copyright string or license agreement. I'm planning to use the code in my own project and need a valid open source license.

     hi, i comipler the lastest code( 10.0.19042.541, vs2019 16.7.4,  ZPL Priter: USB\VID_1FC9&PID_2016\

or USB\VID_154F&PID_1300), except modifyed the vid && pid of ZPL Printer. then it crashed. tpis is: Unhandled exception thrown: write access violation. entry->next was nullptr.
Detail:
Call Stack:

LibusbTest.exe!list_del(list_head * entry) Line 203 C
LibusbTest.exe!handle_event_trigger(libusb_context * ctx) Line 2116 C
LibusbTest.exe!handle_events(libusb_context * ctx, timeval * tv) Line 2234 C
LibusbTest.exe!libusb_handle_events_timeout_completed(libusb_context * ctx, timeval * tv, int * completed) Line 2341 C
LibusbTest.exe!libusb_handle_events_completed(libusb_context * ctx, int * completed) Line 2440 C
LibusbTest.exe!LibUSB::TransferImpl::Start() Line 155 C++
LibusbTest.exe!LibUSB::Transfer::Start() Line 122 C++
LibusbTest.exe!main(int argc, char * * argv) Line 114 C++
[External Code]
kernel32.dll![Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] Unknown

debug the code, it stop at(libusbi.h): entry->next->prev = entry->prev; context is :
static inline void list_del(struct list_head *entry)
{
entry->next->prev = entry->prev;
entry->prev->next = entry->next;
entry->next = entry->prev = NULL;
}

   finally,  i mean, i known this problem is not caused by your library, but libusb.  
   running at win32 platform,  if someone run the exe which added the libusb wrapper DLL file(like your project libusbTest.exe) ,

the exe crashed.