Oelbox, you were right about the exceptions. Passing them through dynamic memory is not a good idea.
So you were about the delete issue and importing std namespace. All these have been changed for good and I have to thank you for pointing those defects.
About your comment about this library being full of copy-pasted code I only have to say that your statement is impertinent and rude. It is stated very clear which part of the code is not mine and who is the author (util/pack and a function in nlSockets.cc if I recall well).
About the design: it is ok for me. This library is designed to be easy to use and I am aware that it can have non common approaches, but it's ok: if I would have wanted to make it as the others I wouldn't have picked one of them instead. Anyway there's clearly room for improvement and I will study to change the interface for 0.5 version (always keeping simplicity and ease of use as main objectives).
You misunderstand what copy-paste coding is. I was not implying that you are copying and pasting from other people, but the code it self is repeated over and over in different functions that should have been consolidated. Please look at http://en.wikipedia.org/wiki/Copy_and_paste_programming as a reference for copy-paste coding.
I also have a suggestion about the v 1.0 branch of the library (which after a very quick and superficial glance looks a lot better than the .4 branch): I would rather write a copy constructor and an assignment operator for the Socket class and return by value rather than returning an new'ed object. And I will explain why:
First of all, the socket class is simple. It does not contain a huge amount of data that is copied - so the copy itself is trivial, further more the compiler may use RVO (Return Value Optimization) on the returned value which is more or less free with regards to performance.
Further more the above will then lead to users of the library not having to use a smart pointer, object manager or manually delete the returned socket object from the library's accept function.
Also it's that would satifsy the rule of three ( http://en.wikipedia.org/wiki/Rule_of_three_(C%2B%2B_programming) )
You state that the library should be simple to use, which the above changes would achieve.
Now I would also implement move constructor and move operator for compilers that support it to further enhance the flexibility of usage.
This has no longer relevance (more than 1 year old) and I have no time for more no-sense.
The code was an alpha I was making for my personal use and I made it public in case It could be useful to anyone. the last thing I imagined is that a "nobody" (no published projects) would come here to give me lessons. Two constructors duplicated some initialization code, ok, what's the big deal?: Do you know what a prototype is?? Should I leave here a wikipedia link to prototype definition so you can check it?? (No, I won't because I am not so rude).
That said, the code has changed completely (and it is no longer alpha) so this is completely irrelevant, the same way as it is your review.
To be rude you have to have some work done to back you up.
I quite sure that any C++ networking developer knows what a pointer is and how to manage and free it. The ease of use depends more in a coherent and compact design than in removing any sight of a pointer, and furthermore in this case replacing the accept pointer with a value return would add an undesired complexity to the use of the sockets.
Well if that is your opinion - you are certainly entitled to have it. Also in my irrelevant review, i stated that it was in alpha, and also my irrelevant review lead to improvements. But as of your statements above it is clear that you don't want suggestions to further improve - and that is fine - it is your project after all. For your last statement I'll just let the above speak for itself.
A suggestion is made in an email or in a forum thread. Anyone can help by sending suggestion/questions/patches. All that is welcomed.
What you did was to state in a review that the library was a worthless toy shit. That's a very strange concept of what a suggestion is.
I'm sure you can see the difference: if not, that would speak very much for itself...
So I wrote a non favorable review of a library that leaks memory, has maintenance problems and was not suitable for production code. I also commented that it was in alpha. Now this was a reaction to the favorable reviews so that people looking at this library would be warned that it wasn't all gold. Now in anything of what I wrote - did I lie? No I did not. Did I have any personal attacks? No. Did what I wrote in the review make you rethink what you were doing? Yes. Now what you're doing is passive aggressively attacking me as a person, my knowledge and intelligence - and that's fine, this is the internet and you are welcome to continue doing that.
I have never stated that the review was a suggestion, I was merely pointing out the problems with the library - I do understand that this seems to somehow offend you personally, and again that is fine - although that was not my intent, but at the time of the review the library was not production safe - and as you yourself state - it was alpha, but there was several reviews which gave the impression that the library was super-fantastic.
Now I made several sound suggestions in this thread, which you shot down without actually having any sound argument - that is why I stated that you seem to not be interested in improving the library through outside suggestions - and that is your choice, and is absolutely fine.
That being said, I hope you continue to improve the library, for yourself and for those that use it. I won't give more suggestions as my suggestions are clearly not welcome, but I do hope others will give input as their use cases expose needs that might not be covered by the library as of the current version.
I'm glad you noticed: You are clearly not welcomed. You should not be so surprised. I'm not giving any support to you in case you still have any doubt.
I'm giving this for free and I have no intention to endure dealing with people which is unrespectful with me and my work. Congratulations on your warning anyone about how bad designed and bad coded my library was (instead of discussing it with me first, now it is a little too late to come here and play ball).
The suggestion of making a value return accept is terrible. You can have all the RVO optimizations of the world but it would break the entire thing. I'm not wasting any more time discussing the collateral effects that It would have because I won't take the role of the master lessons giver you took; now I'm too lazy to google wikipedia for the links and I don't have any special interest in you using the library (Indeed you should take another one that would have the accept function value-returned). Anyway anyone who look the code should notice them and the change of the design philosophy that this change would take in this case.
For the move constructor and move operators: do you want them?? Then code it yourself!! That's the greatness of the opensource. I'm not doing your homework. But like I said, you should take your own advice and avoid this library. Take another and start spreading your "this is a shit" suggestions (to compensate their too good reviews) in their forums so I won't have to deal with you anymore.
"So I wrote a non favorable review of a library that leaks memory, has maintenance problems and was not suitable for production code."
Please do not mix present and pass to confuse people. I don't know if this was accidentally or you are trying to induce people to error.
The thing about memory leaks is false (for the present as well as for the past code). The maintenance problems in the past that would be your opinion and I remind you that back there it was an alpha (and you don't have to save/prevent people from using an alpha for production because everyone in the Earth knows what an alpha mean), but if you states that for the actual code I just would have to laugh.
It doesn't have memory leaks now nor it had them in the 0.4 versions as you stated (the use of macros for the section of code you refereed in your review was because of the unavailability of making dynamically sized arrays in stack of the VC++2008 compiler, that made necessary to make that in dynamic memory in that compiler as opposite to the g++, and anyway it wasn't a memory leak). It is a pity this isn't part of your "vast" knowledge about compilers.
I would like not to have to explain you again how things work in order to defend my work of your "after 5 minutes of code overview" insights and manipulation.
Now I was going to stop discussing, but after you continue to give false statements in your last post, I feel I have no option but to make a reply. Now "Variable Length Arrays" which you used for non-Microsoft compilers is not a part of the C++ standard. It is a part of the C99 standard, but GCC allows for an extension to the C++ language, enabling it in C++ - which is fine. There is no guarantee though that any other C++ compiler on earth will support it. But that is fine.
Now the problem is in the code for Microsoft compilers:
char* buffer = new char[bufferSize];
/ Implementation /
when it should have been:
delete  buffer;
This is undefined behavior according to the C++ standard (5.3.5/2 C++03 ISO/IEC
14882). Now what that means is that anything can happen, and in best case it would instantly crash the application giving a back-trace of what was wrong or it could call up Dominoes and order 15 pepperoni pizzas and blast of to space in search of new planets. Now in most cases this silently leads to memory being leaked. So it's a pity that you do not seem to know this in your vast knowledge of C++.
Further more the new version is not coded in an exception safe manner. Take a look at the Socket::accept function. When you new the Socket in line 403, if getLocalPort throws an exception - you have a memory leak leaking the new'ed Socket, so I would not be too confident that your code never leaks, nor that it never will.
Since you also mentioned it in one of your previous posts, what I meant about copy-paste-code: Take a look at your NLSocket::read and NLSocket::readraw in 0.4.1 - they have almost identical code, now if a bug was identified in read, you would have to fix it two places. Now the library is fairly small, so correcting it in both places would be easy to remember, but that does not mean its good practice, and as the complexity increases, it becomes harder and harder to maintain. Now "read" and "readraw" is not the only functions that exhibit this coding style.
And to ease your temper - the new version, which is the relevant version, does not exhibit this coding-style, which is good!
Now the past and present mixing in the sentence you quote was unfortunate and an error by me, and if that would confuse anyone - I do apologize for that.
Now to make it clear, I did not know that I needed to send you an email asking for permission to write a non favorable review - As you state, this is an open source project, and I assumed that since it was hosted on sourceforge, which have a review system, people could write a review of their thoughts about the library. Now there is no doubt that the v0.4 branch had numerous problems, and I find it unfortunate that you should take the review so personally.
And you don't need to worry, I never had the intention of using your library, nor would I in any way or form require your support.
First, this is a discussion you focus in discussing old code that was removed more than a year ago. Like a said before this is no longer relevant. I'm not wasting time in discussing what a undefined behaviour is either or what the specific supported compilers does in that case.
You said: "So I wrote a non favorable review of a library that leaks memory, has maintenance problems and was not suitable for production code."
This leaded to error giving the impression that the current version of the library leaked memory and had maintenance problems. My main concern was to make clear that is not true.
"Now to make it clear, I did not know that I needed to send you an email asking for permission to write a non favorable review - As you state, this is an open source project, and I assumed that since it was hosted on sourceforge, which have a review system, people could write a review of their thoughts about the library. Now there is no doubt that the v0.4 branch had numerous problems, and I find it unfortunate that you should take the review so personally."
A considerer person would request/suggest/point improvements/deficiencies to the project (if he/she cares) and would be perfectly normal to write a bad review after that if he/she is not listened and the deficiencies are still there.
You are free to directly bitch about the library all you want in a review instead of being constructive, but that is acting like a cretin (here in Internet or anywhere). I don't like cretins nor want them for the community.
Writting such a review is a one time, one direction trip. Back then I took in consideration what you said, but your credit has gone for anything more. You are free to write that review and I am free to ask you not to come back ever. Anyway I did take in consideration your last suggestions: the first one was a bad idea, and the others, in my opinion, are not necessary.
If you say you had already no intention of using the library nor want any support I would assume you are still here only to troll and piss me off. Please take your cs101 lessons and wikipedia links to a beginner C++ forum, which is where they belong.
Log in to post a comment.