You can do this. Windows Azure Blob Storage is accessible via a language-independent REST API.
Note that there are some more directly supported language SDKs that simplify the REST API interaction (retries, HMAC signing, etc), but it is entirely doable from C++.
Whether you need a Web Role (or Worker Role) for this depends on one thing: Is the sensor-collection application running on a system that can be trusted with the "keys" needed to access Windows Azure Blob Storage. If that app host can be trusted (e.g., fully under your control, not running on a customer's or partner's desktop for example) then it might be fine to fully trust it with unfettered access to your storage account. Then the sensor-collection app can beam the data directly into blob storage - no Web Role needed.
If you cannot trust the host on which the sensor-collection is running, you need another tact. There is a way for a client to request temporary, limited-scope access to blob storage. This is known as Shared Access Signatures (SAS) in Azure/Blob terminology. A client in possession of an unexpired SAS can do whatever is allowed by that SAS - such as writing to blob storage. To create a SAS, one needs the storage keys mentioned in the prior paragraph. This would be a reason to deploy a Web Role - it can generate the SAS for you as needed (via a web service of your creation, for example). The scheme for identifying trusted clients depends on how you do things (the sensor-collection app instances need to identify themselves in some trusted way, I assume -- but the SAS issued to one instance can let it write into an area in blob storage dedicated to that app instance, account, customer, site, etc. - whatever the right abstraction is for your business).
Note, though, that while a Web Role is a way to solve the SAS-creation, you could also do it from any code that has access to a storage key.