29 Jul
2013
29 Jul
'13
1:33 p.m.
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..).
29 Jul
29 Jul
5:20 p.m.
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
30 Jul
30 Jul
9:42 a.m.
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(a)eversberg.eu>
Holger Hans Peter Freyther wrote:
--
Regards,
Ivan Kluchnikov.
http://fairwaves.ru
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
5 Aug
5 Aug
1:11 p.m.
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
30 Jul
30 Jul
9:50 a.m.
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(a)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?
holger
PS: 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(a)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
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
10:20 a.m.
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.
--
- Holger Freyther <hfreyther(a)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
3925
days inactive
3932
days old
osmocom-net-gprs@lists.osmocom.org
5 comments
4 participants
participants (4)
-
Alexander Chemeris -
Andreas Eversberg -
Holger Hans Peter Freyther -
Ivan Kluchnikov