Closed gregschrock closed 6 years ago
Hey @gregschrock . Can you please cite specific examples?
Sure! Sorry about that.
There was one conflict I was hitting frequently that made me start investigating. I hit it in a number of places in our code and ended up taking another approach before I found other potential conflicts. The problem was in switch_common.h
with the declaration of:
extern char etext, edata, end;
end
is a very common variable/function name in our codebase and was the source of a number of conflicts. Granted, since this is an extern
, I'm not sure if namespacing can necessarily solve it. However, C++ convention is to write library code within namespaces, so I do still find it a valuable addition to the codebase.
This is odd; end shouldn't have been in the extern char decl. Thank you for pointing it out - I removed it and pushed an update. If there are any other issues, please let me know. If you don't mind me asking, what kind of project are you working on?
That's great! Thanks!
I work for 128 Technology. We create a software router that rethinks networking fundamentals to allow networks to do what companies need.
We recently started rearchitecting our analytics infrastructure and need a queue to provide data consistency among the compute nodes within a router. TANK has proven to be a perfect fit for our use case and hardware requirements.
This is really cool. Please let me know if there is anything else I could do to help :)
Hello,
I've been working to integrate TANK into a project. As I've expanded the use of the client further into our codebase, I've run into a number of naming conflicts as many of TANK's declarations (I am also referring to the contained Switch code) are in the global scope. I realize the conflicts should also be resolved in our own namespacing. However, client integration would be significantly simplified if the TANK codebase were contained within namespaces.
Thanks