From nicolas.weeger at laposte.net Fri May 27 08:46:03 2022 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 27 May 2022 15:46:03 +0200 Subject: [crossfire] Building in C++? Message-ID: <1794305.Yhhp66BgsX@gros> Hello. I just pushed branch "cpp-build" which changes all .c files to .cpp files. The only other changes are what was required for correctly building (adding some casts, renaming a few variables, things like that). Functionally, everything is the same. I'd like to merge those changes to master, but well, I'd like to get opinions before. I don't plan on migrating to a full C++ code base with classes, inheritance & other things, the current code is fine. I do plan to use C++ to replace some home-grown things (lists handling mostly - for new code, I don't want to always have to realloc() and check size, a std::vector is enough for that), and to solve issues with object* items being free'd while still referenced (with our nice check on "count == saved_count" here and there urgh). Regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From shjohnson.pi at gmail.com Fri May 27 13:19:55 2022 From: shjohnson.pi at gmail.com (Steven Johnson) Date: Fri, 27 May 2022 14:19:55 -0400 Subject: [crossfire] Building in C++? In-Reply-To: <1794305.Yhhp66BgsX@gros> References: <1794305.Yhhp66BgsX@gros> Message-ID: I think this is a good idea. I was able to build and run crossfire server with minimal changes on the cpp-buld branch. Here's my small patch: - fix building in a 'build' directory - Add 'build' to .gitignore - Fix .gitignore to ignore the .cpp version of common/arch_types_valid.c diff --git a/.gitignore b/.gitignore index cdb60bf9..bec59837 100644 --- a/.gitignore +++ b/.gitignore @@ -517,7 +517,8 @@ /utils/ylwrap Makefile Makefile.in -common/arch_types_valid.c +build +common/arch_types_valid.cpp cov-int/ cscope.* doc/playbook/handbook.idx diff --git a/common/Makefile.am b/common/Makefile.am index 9b08a564..682c0f5c 100644 --- a/common/Makefile.am +++ b/common/Makefile.am @@ -74,7 +74,7 @@ libcross_a_SOURCES = \ utils.cpp loader.cpp: - $(LEX) -i -o loader.cpp loader.l + $(LEX) -i -o loader.cpp $(top_srcdir)/common/loader.l EXTRA_DIST = README is_valid_types_gen.py AM_CPPFLAGS = -I$(top_srcdir)/include -DDATADIR=\"$(pkgdatadir)\" -DCONFDIR=\"$(pkgconfdir)\" \ diff --git a/random_maps/Makefile.am b/random_maps/Makefile.am index 65e1b3d9..7562133b 100644 --- a/random_maps/Makefile.am +++ b/random_maps/Makefile.am @@ -29,7 +29,7 @@ EXTRA_DIST = \ main.cpp reader.cpp: - $(LEX) -P rm -o reader.cpp reader.l + $(LEX) -P rm -o reader.cpp $(top_srcdir)/random_maps/reader.l AM_CPPFLAGS = -I$(top_srcdir)/include -I${top_srcdir}/include/random_maps On Fri, May 27, 2022 at 9:46 AM Nicolas Weeger wrote: > Hello. > > > I just pushed branch "cpp-build" which changes all .c files to .cpp files. > The > only other changes are what was required for correctly building (adding > some > casts, renaming a few variables, things like that). > > Functionally, everything is the same. > > > I'd like to merge those changes to master, but well, I'd like to get > opinions > before. > > > I don't plan on migrating to a full C++ code base with classes, > inheritance & > other things, the current code is fine. > > I do plan to use C++ to replace some home-grown things (lists handling > mostly > - for new code, I don't want to always have to realloc() and check size, a > std::vector is enough for that), and to solve issues with object* items > being > free'd while still referenced (with our nice check on "count == > saved_count" > here and there urgh). > > > > Regards > > > Nicolas_______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > IRC: http://crossfire.real-time.com/irc/index.html > Discord: http://crossfire.real-time.com/discord/index.html > Project Site: https://sourceforge.net/projects/crossfire/ > Wiki: http://wiki.cross-fire.org/ > Website: http://crossfire.real-time.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruben at mrbrklyn.com Fri May 27 21:25:49 2022 From: ruben at mrbrklyn.com (Ruben Safir) Date: Fri, 27 May 2022 22:25:49 -0400 Subject: [crossfire] Building in C++? In-Reply-To: References: <1794305.Yhhp66BgsX@gros> Message-ID: On 5/27/22 14:19, Steven Johnson wrote: > I think this is a good idea. Nah - there is little or no advantage. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 From ruben at mrbrklyn.com Fri May 27 21:42:47 2022 From: ruben at mrbrklyn.com (Ruben Safir) Date: Fri, 27 May 2022 22:42:47 -0400 Subject: [crossfire] Building in C++? In-Reply-To: References: <1794305.Yhhp66BgsX@gros> Message-ID: <6ca66357-fec8-8697-3fdd-d38b9f9eba3f@mrbrklyn.com> On 5/27/22 14:19, Steven Johnson wrote: > I think this is a good idea. I was able to build and run crossfire server > with minimal changes on the cpp-buld branch. No only a bad idea, but a REALLY bad idea and this "C++" wouldn't even compile if it was REAL C++ with, using a strict compiler, with namespaces and C++ storage facilities. You just compiled a C program with a C++ compliler without even altering the headers for C imports...uuggg. Undergraduate student FAIL. It is broken from the ground up and completely unecessary. The reason why the server has remained viable for several decades is because it is written in standard C, not C++ or Java, or Javascript, which all change with every passing undergraduate class from your favorite local technology university. Leave it alone so we can continue to have a compling server in a few more decades. It doesn't need C++ overhead or syntax hell. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 From ruben at mrbrklyn.com Sat May 28 14:06:55 2022 From: ruben at mrbrklyn.com (Ruben Safir) Date: Sat, 28 May 2022 15:06:55 -0400 Subject: [crossfire] Building in C++? In-Reply-To: <1794305.Yhhp66BgsX@gros> References: <1794305.Yhhp66BgsX@gros> Message-ID: <20220528190655.GB21643@www2.mrbrklyn.com> On Fri, May 27, 2022 at 03:46:03PM +0200, Nicolas Weeger wrote: > Hello. > > > I just pushed branch "cpp-build" which changes all .c files to .cpp files. The > only other changes are what was required for correctly building (adding some > casts, renaming a few variables, things like that). > > Functionally, everything is the same. never never never do this. This will kill crossfire permanently. C++ is not C and the vectors stroage have huge overheads, plus there is adapations of name spaces and hundreds of language changes and dozens of variations of C++ and you get little in return, if not nothing, in return. Once you move to C++ you will never have continuity again and in a few short time the project will be uncompilable on most system. This is truly an insane idea and it is frankly lazy. What? C++ has no memory leaks? pffff... There is good reasons why all along lived projects are written in C. It is truly portable and complies over time for decades and it is faster and more efficient that anything else, especially C++ There are hundreds of dead C++ projects that just won't compile today, > > > I'd like to merge those changes to master, but well, I'd like to get opinions > before. > > > I don't plan on migrating to a full C++ code base with classes, inheritance & > other things, the current code is fine. > > I do plan to use C++ to replace some home-grown things (lists handling mostly > - for new code, I don't want to always have to realloc() and check size, a > std::vector is enough for that), and to solve issues with object* items being > free'd while still referenced (with our nice check on "count == saved_count" > here and there urgh). > > > > Regards > > > Nicolas > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > IRC: http://crossfire.real-time.com/irc/index.html > Discord: http://crossfire.real-time.com/discord/index.html > Project Site: https://sourceforge.net/projects/crossfire/ > Wiki: http://wiki.cross-fire.org/ > Website: http://crossfire.real-time.com -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 From pc-crossfire06 at crowcastle.net Sun May 29 15:39:11 2022 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Sun, 29 May 2022 16:39:11 -0400 Subject: [crossfire] Building in C++? In-Reply-To: <1794305.Yhhp66BgsX@gros> References: <1794305.Yhhp66BgsX@gros> Message-ID: <5a85a4fd-b742-2bed-641e-8450ff6f966f@crowcastle.net> Crossfire is built around objects, so I can see why making such a change would seem to make sense, but I'm not clear that it would really improve anything in particular.  The first question is what language features in C++ would be useful? I was looking at making the maximum window size a runtime config option instead of a compile-time option (default 25x25 now). There are places where using a language with object constructors would make that much simpler since we have a bunch of hard-coded arrays now.  I don't think this justifies such a change. I'm a bit concerned about security running a public Crossfire server.  Switching to C++ would do nothing to help, but I was thinking Rust would be interesting.  That would be a major porting effort; essentially a rewrite.  Probably not worth it, especially for such a relatively new language. For the server, the game is quite stable, so we would need some major reason to make a big change.  Most of the changes now should be tweaks to fix issues, often hidden bugs that are exposed when a new map tries something original. Ultimately, what the game needs is not server work.  It needs more players and more maps.  For more players, a browser-based client would be awesome.  For more maps, I'm working on some on my server, which I'll push out eventually. If you want to do coding, is there some possibility to build a client in Rust compiled to Webassembly to run in a browser?  That would be all kinds of awesome! On 5/27/22 09:46, Nicolas Weeger wrote: > Hello. > > > I just pushed branch "cpp-build" which changes all .c files to .cpp files. The > only other changes are what was required for correctly building (adding some > casts, renaming a few variables, things like that). > > Functionally, everything is the same. > > > I'd like to merge those changes to master, but well, I'd like to get opinions > before. > > > I don't plan on migrating to a full C++ code base with classes, inheritance & > other things, the current code is fine. > > I do plan to use C++ to replace some home-grown things (lists handling mostly > - for new code, I don't want to always have to realloc() and check size, a > std::vector is enough for that), and to solve issues with object* items being > free'd while still referenced (with our nice check on "count == saved_count" > here and there urgh). > > > > Regards > > > Nicolas > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > IRC: http://crossfire.real-time.com/irc/index.html > Discord: http://crossfire.real-time.com/discord/index.html > Project Site: https://sourceforge.net/projects/crossfire/ > Wiki: http://wiki.cross-fire.org/ > Website: http://crossfire.real-time.com > From ruben at mrbrklyn.com Sun May 29 15:49:20 2022 From: ruben at mrbrklyn.com (Ruben Safir) Date: Sun, 29 May 2022 16:49:20 -0400 Subject: [crossfire] Building in C++? In-Reply-To: <5a85a4fd-b742-2bed-641e-8450ff6f966f@crowcastle.net> References: <1794305.Yhhp66BgsX@gros> <5a85a4fd-b742-2bed-641e-8450ff6f966f@crowcastle.net> Message-ID: <673fdcfd-c3db-5193-a697-acccc4673712@mrbrklyn.com> On 5/29/22 16:39, Preston Crow wrote: > > I was looking at making the maximum window size a runtime config option > instead of a compile-time option (default 25x25 now). There are places > where using a language with object constructors would make that much > simpler since we have a bunch of hard-coded arrays now. hard coded arrays are much faster and what do you thing the C++ objects are made of? Compile time options are good things, and if you really want to change something to run time options, that doesn't require the use of C++ with its huge overhead and ever changing syntax. In fact, C++ delvelopers don't even all work in the same syntaxically universe as MS users develope routinely with methods and syntax that don't exist in Unix. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and extermination camps, but incompatible with living as a free human being. -RI Safir 2013