On Wed, Feb 21, 2018 at 07:03:21AM +0800, Andy Green <[email protected]> wrote: > > Maybe you can borrow some ideas or even some code from them. > > Maybe you can fix your library headers. Or maybe not.
Just out of curiosity, which of Harald's libraries are you refering to? On Wed, Feb 21, 2018 at 07:26:03AM +0800, Andy Green <[email protected]> wrote: > > > > Anyhow, I don't think this is the right place for introductory programming > > You brought this subject up. I pointed at a solution to your problem, which you claimed isn't a solution because your prtogramming skills weren't good enough to be familiar with it, after which I either had the choice of leaving you or teach you about this technique i more detail. Opaque types and data hiding is a very standard technique used in almost all libraries, so it's not really a libev thing, thus the reference to the "introductory programming", because that is what it is, a basic technique in C programming. So, if by "you brought this up" you mean "you tried to help me with my problem" then you are spot on. > > Quite possibly, lws_ev_io_watcher could even be identical to > > struct ev_io, and with some work, it doesn't even have to be a pointer, and > > lws_ev_watcher might not need to be a separate data type either. > > That is the first constructive suggestion, thanks. The thread is full of constructive suggestions, it's just that you were unable or unwiling to understand and/or apply them. > It adds another layer of indirection. But actually that is probably a > good idea. It also incidentally shows most of the strongly worded and derisive claims you made to be untrue. What are your thoughts about that? > > > However you cannot compose an opaque / forward-referenced struct into > > > another struct with type safety, because the size of the undefined thing > > > is > > > unknown. > > > > Yes, you can, multiple ways. > > Note the word "compose" has a specific meaning here... ... a meaning which you won't explain here, so this is a useless comment, because nobody knows what's going in on your mind. What I said is certainly true. > > Again, not trivial, but what you are trying to do is hardly typical. > > All of these event loop things are contributed. I don't think any of these > extreme tricks to workaround your header clash problem will help with > maintainability or source code clarity. None of these "extreme" tricks as you call them are needed, either, mind you. > > To say it bluntly, you come about as very tight-lipped about your needs > > and a bit arrogant, when considering that your programming skills are > > comparatively limited, given you are quite troubled by even simple > > abstraction problems in C... > > Wow! You are living down to my expectations :-) If by that you mean "I attack you and then you call me out, and I totally expected that" then there is nothing surprising about it indeed. > > Both Harald and I have tried to help you, and it would suit you well if you > > would explain your problem a bit more and would use rational arguments > > instead of shouting at people... > > No... you preferred to attack the user and find a way that nothing needed to You are very deluded - you used ad hominems instead of rational arguments almost form the very beginning. I merely pointed out that your progamming skills are lacking and your tone is arrogant, certainly in relation to your actual skills - again, it would become you well to show a bit more humility and learn from people who, clearly, know better how to design APIs and implement data hiding than you do. What you are doing is projecting your own attacks on others, but that doesn't make it true. Even if you can't show any humility or the will to learn, you should certainly use rational arguments instead of hand waving, shouting, and making stuff up just to disagree. > change on your side, even when a comparable, more popular library has no > problem with its header hygiene doing the same thing. Nothing in this thread is about what any reasonable person would call "header hygiene". The fact that libev provides a libevent-compatible API and therefore also provides its, well, public API symbols is construed by you to be some header hygiene problem. You clearly either don't understand what header hygiene means or you are misusing it on purpose. This is just another example of a non-rational made-up argument without any merit or even content. > As I said I will just leave it unselectable for choose-at-runtime in cmake - > and suggest people avoid using libev. You of course didn't say this before, but that's an entirely rational solution if you are incapable of solving this problem yourself. I.e. giving up when your skills are not up tp the job is probably the best solution, also for your users. It's also fine to suggest people to avoid using libev - libev was always provided "as is", and certainly is a tool for experts and not beginners, and anybody making thier event loop selection based on misunderstanding of basic programming techniques is probably better of with other event libraries, although I am not sure what those would be. In any case, you are clearly only intersted in trolling and not interested in solving your problem, so I regret having tried to help you. Good luck for your futgure endeavours and good bye. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [email protected] -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/mailman/listinfo/libev
