Comments (10)
Good point, how about change 'ACO_H' to something like 'ACO_V1_H'?
V1 here means the major version number.
from libaco.
How do you think about to make include guards unique by appending a kind of UUID?
from libaco.
I think 'ACO_V1_H' is long enough.
The compilation errors will be yielded when it is happened (could be very rarely) that there is some other c header file has the exactly same include guard 'ACO_V1_H' (because many other 'aco_*' macros and prototypes which are defined in 'aco.h' is always required by the 'aco.c' and other libaco application source files).
I'll commit this adjustment soon :-)
from libaco.
I am curious then how often corresponding name space issues will occasionally matter.
from libaco.
How do you think about to make include guards unique by appending a kind of UUID?
I think that kind of solution probably be a little overweight. Imaging that there is a UUID hex in the include guard :D
But maybe one day this would be added into to the new C standard. Be honestly, personally I think this solution is a very good solution.
from libaco.
There is some search results about the "uuid include guard". It has been used on some occasion.
from libaco.
One problem here is, the possible inner api & macros collision (say there is another aco.h
which also have some maybe different aco_* macros and prototypes) may still exist even when the include guard is unique. In some cases, I think the compilation errors would be yielded more easily when the two collision aco.h
have the same include guard.
from libaco.
People normally would think that the C header file name (say "aco.h") is usually corresponding to the macro name of the include guard ("ACO_H" in this case).
If there is a totally different macro name of the include guard with the file name, it may would delay or even suppress some compilation errors that should be yielded as soon as possible.
So I think it is not necessary to use a different macro name of the include guard in aco.h, let's keep "ACO_H".
(Unless we choose to change the all aco_* started macros and prototypes into aco_{$UUID}_* in our source files, then the collision naming problems is solved fundamentally... But this kind of solution is only suited for very special and rare situations in real life.)
from libaco.
People normally would think that the C header file name (…) is usually corresponding to the macro name of the include guard ….
The expectations are varying, aren't they?
…, let's keep "ACO_H".
- The probability for name clashes might be low enough also for such an identifier (for a while).
- Other name variants can be safer.
from libaco.
The expectations are varying, aren't they?
…, let's keep "ACO_H".
- The probability for name clashes might be low enough also for such an identifier (for a while).
- Other name variants can be safer.
Yes, I agree with you. So, let's just remain what it is.
from libaco.
Related Issues (20)
- Document c standard library dependencies
- Status and Future Plans of libaco
- can libaco support yield/resume between threads? HOT 3
- Provide way to return error to caller instead of calling `abort()` on failed assertions HOT 1
- is it worth to create coroutine inside coroutine?
- which one better to pass argument to co function
- 关于libco bug的疑问
- Thread local storage support HOT 1
- Feature request: Ability to return a value from aco_yield() HOT 1
- Feature Request: aco_get_co() return NULL when the caller is main co HOT 4
- is 120byte the lowest we can have? possible to lower this? HOT 1
- Do libaco coroutines run on different CPUs at the same time. i.e. does the program performance benefit from having multiple CPUs HOT 2
- Question: which is faster, creating new coroutines or reusing old coroutines HOT 3
- resume multiple coroutines in parallel HOT 1
- Integrate into our io engine? HOT 1
- add arm32/aarch64 support for android and ios HOT 1
- `aco_amd64_inline_short_aligned_memcpy_test_ok` size alignment
- whether this description is incorrect
- Few questions about proper usage
- is aco_exit necessary?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libaco.