Dear Ivan, all,
I started to do work on the PCU and didn't compile C++ for a long time. I was surprised how long it takes to compile the code. From my point of view we are taking the hit of g++ without really using any of the features that C++ vould provide (e.g. no stack variables with automatic cleanup..).
Holger Hans Peter Freyther wrote:
From my point of view we are taking the hit of g++ without really using any of the features that C++ vould provide (e.g. no stack variables with automatic cleanup..).
hi holger,
i have some old patches somewhere that turn everything from c++ to c, except the dissecting part, which stays c++, iirc. i never finished them, because there was someone doing a similar work, so i didn't want to do double work. in my opinion it makes sense to change it, since we don't (and won't) use any c++ features at our code.
I think we should find a more nice solution to extern "C".
that would be my solution. if you like, i could dig these patches out.
regards,
andreas
Hi Holger and Andreas,
I agree with Andreas, actually most of the code is c, not c++, so I think that the right solution is to get rid of с++ completely. Andreas, if you have patches for that and time, I believe that it make sense to create new branch with these patches. After that I can try to turn dissecting part from c++ to c. What do you think about it?
2013/7/29 Andreas Eversberg andreas@eversberg.eu
Holger Hans Peter Freyther wrote:
From my point of view we are taking the hit of g++ without really using any of the features that C++ vould provide (e.g. no stack variables with automatic cleanup..).
hi holger,
i have some old patches somewhere that turn everything from c++ to c, except the dissecting part, which stays c++, iirc. i never finished them, because there was someone doing a similar work, so i didn't want to do double work. in my opinion it makes sense to change it, since we don't (and won't) use any c++ features at our code.
I think we should find a more nice solution to extern "C".
that would be my solution. if you like, i could dig these patches out.
regards,
andreas
Ivan Kluchnikov wrote:
Andreas, if you have patches for that and time, I believe that it make sense to create new branch with these patches. After that I can try to turn dissecting part from c++ to c.
hi ivan,
i juts pushed the old patches i made. (see jolly/outdated_c branch.) the last two patches show you what i did. the first patch moves all bitvector stuff to a sepeate file (is missing in this patch, but present in the next one). the second patch renames c++ code to c and changes c++ functions to c functions. it does not make sense to take any of the patches, since there is too many divergence between master and this branch, so just take it as an idea what i did.
regards,
andreas
Hi Holger,
Do you have a clear idea what could be done easier/better/safer with C++ in this case? I general I'm a big fan of C++ because it's easier to write safe/better code, but in this exact case we're already deep into C style and I'm not sure we could change that with a reasonable amount of effort. If you have concrete proposals, please send them for discussion. Otherwise I agree that we should change the code to be pure C, even though I don't like C.
On Mon, Jul 29, 2013 at 3:33 PM, Holger Hans Peter Freyther hfreyther@sysmocom.de wrote:
Dear Ivan, all,
I started to do work on the PCU and didn't compile C++ for a long time. I was surprised how long it takes to compile the code. From my point of view we are taking the hit of g++ without really using any of the features that C++ vould provide (e.g. no stack variables with automatic cleanup..).
From here I wonder if we should use gcc for more speedy compiles or if we should use more C++ features (I am not talking STL, operator overloading)?
Any opinions?
holgerPS: I think we should find a more nice solution to extern "C".. I spent various minutes trying to figure out which parts of the pcu have C linkage and which C++.. For things from libosmocore it is obvious.. but then we have the vty_info...
--
- Holger Freyther hfreyther@sysmocom.de http://www.sysmocom.de/
=======================================================================
- sysmocom - systems for mobile communications GmbH
- Schivelbeiner Str. 5
- 10439 Berlin, Germany
- Sitz / Registered office: Berlin, HRB 134158 B
- Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
On Tue, Jul 30, 2013 at 11:50:23AM +0400, Alexander Chemeris wrote:
Hi Holger,
Do you have a clear idea what could be done easier/better/safer with C++ in this case? I general I'm a big fan of C++ because it's easier to write safe/better code, but in this exact case we're already deep into C style and I'm not sure we could change that with a reasonable amount of effort. If you have concrete proposals, please send them for discussion. Otherwise I agree that we should change the code to be pure C, even though I don't like C.
I would convert the C modules to C. In terms of C++ I still wonder how it could help. E.g. bitvec could be a C++ class. Then we would have the 23bytes on the stack (maybe one template instantiation for the case of 23 bytes)... but given the state of things C might just be the easiest route.
osmocom-net-gprs@lists.osmocom.org
-
Alexander Chemeris -
Andreas Eversberg -
Holger Hans Peter Freyther -
Ivan Kluchnikov