0001820: [refactoring] Replace std:: classes with internal zdoom classes

Notes
(0008896) Watermelon (developer) 2014-06-08 00:47 edited on: 2014-06-08 00:48	As for a big discussion on this, hopefully the following questions can be answered: 1) Is it worth forever locking the std libraries out? There are a ton of useful features that I've grown accustom to over the years of using the std library. One I really liked that they added was std::regex. If we ever upgrade to C++ 11 compatibility, we'd never get to use this because we have deviated from using any std libraries. 2) The overhead, is it worth it? Since you did all the changes, can you see how much size gain we get? Is it only 10-20 kb? or is it much more? 3) Someone needs to document the equivalents of what is in ZDoom, such as (some of these we already know, like FString): String HashMap Sets Queue/Deque Priority Queue Stack Tree Iterators (for the above) I'm also worried they won't have some of the useful std lib features. While I can always code them in and add them to ZDoom... I'd have to wait for a backport to get it since it'd be way out of order. ---------------------------------------------------------- I'm not against switching to all ZDoom containers. If they are easy to work with and allow me to do what I normally can do, I personally wouldn't care at all. It looks like you did a lot of work there, so I don't want to sound like I'm against it. Just playing the Devil's advocate ;) I would definitely love the documentation (just a short one somewhere) so that I don't have to waste time trying to find out what each one does...etc.

(0008903) Torr Samaho (administrator) 2014-06-08 07:51	Quote from Edward-san I hope this brings a lot of improvements in code size and in compile-time and runtime speed. Do you have any evidence that this is actually the case? So far I don't see any real benefit in getting rid of the std classes. In some cases I even intentionally did not use the ZDoom classes. For instance, I did not use FString anywhere in networkshared.h and networkshared.cpp so that this code can be used outside of ZDoom code, e.g. in the master server.

(0009369) Edward-san (developer) 2014-06-15 11:10	Okay, I reverted the changes on networkshared., but I have some concerns about some things: 1) the usage of std::ostream in the function QueryIPQueue::addAddress . Why don't you use "FILE " and the "fprintf" function? (the string you print has no format, so there's no overhead from runtime checking, to begin with!); 2) std::stringstream inside some functions, when you can use safely just std::string operator+ and operator+= (all the arguments passed to '<<' are compatible with the std::string operators). 3) I can remove some useless includes (considering also point 1 and 2): //from networkshared.cpp #include <sstream> #include <errno.h> #include <iostream> //from networkshared.h #include <string.h> #include <stdlib.h> #include <list> #include <ctype.h> #include <math.h> Obviously, 1) implies that masterserver should be changed by using "stderr" instead of "&std::cerr". I'll make a patch with these changes.

(0009471) Torr Samaho (administrator) 2014-06-15 17:43	Quote from Edward-san 1) the usage of std::ostream in the function QueryIPQueue::addAddress . Why don't you use "FILE " and the "fprintf" function? (the string you print has no format, so there's no overhead from runtime checking, to begin with!); Why should I? We are not restricted to C code, so I can nicely use the STL. As I said above, I don't see any real benefit in getting rid of the STL. Quote from Edward-san* 2) std::stringstream inside some functions, when you can use safely just std::string operator+ and operator+= (all the arguments passed to '<<' are compatible with the std::string operators). Why? The code is a perfectly valid use of std::stringstream. I would even dare to say that it's more efficient than using the std::string operator+ since each call of the latter creates an extra string copy.

(0009478) Edward-san (developer) 2014-06-15 19:16 edited on: 2014-06-15 19:19	Quote from Torr_Samaho I would even dare to say that it's more efficient than using the std::string operator+ since each call of the latter creates an extra string copy. If there's enough reserved memory for all the strings to append to the std::string object, why should it?

(0009479) Torr Samaho (administrator) 2014-06-15 19:24	By design operator+ has to return a temporary copy of the combined string. That copy then is later stored into whatever you use operator= on. You don't have the problem with operator+=, but there you need multiple lines to add multiple strings. Anyway, even if using a string is as good as a stringstream here (the compiler optimizations can possibly eliminate the temporary copy), I still see absolutely no reason not to use the stringstream.

(0021311) Edward-san (developer) 2020-05-05 21:45	Actually, after a long time I realized that this idea is not good. If the internal code must be separated from the game code, this would hinder the process. Closing this.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2014-06-08 00:14	Edward-san	New Issue
2014-06-08 00:14	Edward-san	Status	new => assigned
2014-06-08 00:14	Edward-san	Assigned To	=> Edward-san
2014-06-08 00:14	Edward-san	File Added: huge_std_convert.diff
2014-06-08 00:14	Edward-san	Status	assigned => feedback
2014-06-08 00:21	Dusk	Status	feedback => needs review
2014-06-08 00:47	Watermelon	Note Added: 0008896
2014-06-08 00:48	Watermelon	Note Edited: 0008896	View Revisions
2014-06-08 00:48	Watermelon	Note Edited: 0008896	View Revisions
2014-06-08 07:51	Torr Samaho	Note Added: 0008903
2014-06-08 07:52	Torr Samaho	Status	needs review => feedback
2014-06-15 11:10	Edward-san	Note Added: 0009369
2014-06-15 11:10	Edward-san	Status	feedback => assigned
2014-06-15 17:43	Torr Samaho	Note Added: 0009471
2014-06-15 19:16	Edward-san	Note Added: 0009478
2014-06-15 19:19	Edward-san	Note Edited: 0009478	View Revisions
2014-06-15 19:24	Torr Samaho	Note Added: 0009479
2020-05-05 21:45	Edward-san	Note Added: 0021311
2020-05-05 21:45	Edward-san	Status	assigned => closed
2020-05-05 21:45	Edward-san	Assigned To	Edward-san =>
2020-05-05 21:45	Edward-san	Resolution	open => invalid

Relationships