Author Topic: macros used in GNE  (Read 4874 times)

entity

  • User
  • *
  • Posts: 2
macros used in GNE
« on: July 22, 2007, 01:20:45 AM »
First off, this is very clean API. I'm very impressed. Thanks!

Now the issue... We are using GNE to implement the network version of our sim engine. We are using our own object serialization code to keep the network a modular component. We already have methods for serialization to other devices. The macros in GNE (readShort, writeString, etc.) are very generic and cause many compiler issues by trying to override our own class methods. It is very "dirty" for us to have to undefine macros in the classes that define these methods, as they do not depend on GNE in any way... They just happen to be included in the same cpp files. It also worries me that I'm undefining the macros in cpp files before including our own objects.  So I guess this is a two fold post...

1) Will undefining macros possibly break GNE? If all of the macros are used in cpp files, no worries... I'm more worried about inlined methods.

2) Is it possible to prefix (with GNE_) or undefine macros in future releases? I personally think rewriting the methods as template specializations is the cleaner approach, but I am not aware of how extensively things are used :)

Thanks again for your time and this library!

Nick
« Last Edit: July 22, 2007, 01:23:05 AM by entity »

Gillius

  • Administrator
  • User
  • *****
  • Posts: 147
    • http://www.gillius.org/
Re: macros used in GNE
« Reply #1 on: July 24, 2007, 09:17:14 PM »
These are actually macros inherited from HawkNL. I think they are only used in the Buffer.cpp file. What I thought was strange is that I thought I removed the dependency of nl.h on user code, but I might have needed to leave it only for the initGNE method, which takes an NLenum for the network type. To be honest, GNE only really works with IP networks anyway (and probably unfortunately only IPv4). It's been a very long time since I've seen the code though.

You probably could just remove the NL dependency entirely by changing the code so that the networkType is defined by GNE itself (which is how I was thinking to achieve it), or just hack it by removing it or making it an int. Then you can remove the nl.h, and after this, there should be few if any macros, because I'm not a fan of macros at all. I did most of the GNE work years ago and certainly today I would only use a macro as a last resort but even then I probably would have used an inline function instead of a macro unless I had a good reason.
Gillius
Gillius's Programming http://www.gillius.org/

Gillius

  • Administrator
  • User
  • *****
  • Posts: 147
    • http://www.gillius.org/
Re: macros used in GNE
« Reply #2 on: July 24, 2007, 09:28:36 PM »
OK, so I was wrong, there are a few more instances in the public headers where I use NL's header. Users can create GNE Address objects from an NLAddress, and a couple of the methods of the classes meant to be used more internally have a few references to NL types like NLsocket and NLint. The LowLevelError contains an NLint error code from HawkNL, although the user cannot get the error code. So the only two places users should be seeing NL stuff is in the initGNE method as I said, and the NLaddress for the Address object. I'm not sure how to get around some of the typedef issues, but the end result here is that it seems like it should be safe for you to #undef whatever you need/want because I should be keeping usage of nl.h in the headers to a minimum.
Gillius
Gillius's Programming http://www.gillius.org/

entity

  • User
  • *
  • Posts: 2
Re: macros used in GNE
« Reply #3 on: July 27, 2007, 06:45:17 PM »
Hey,

Thanks for replying. I didn't realize the macros were introduced by HawkNL. I am undefining them in cpp files where errors occur, and so far everything seems to work fine. As far as exposing NL, I don't understand why any users of GNE need to know about HawkNL, but that is your decision to expose it... and I can live with that. The only drawback is something you already mentioned: If you want to switch to another open source socket library, the user level API will change. That might happen if HawkNL does not support IPv6.

Thanks again for this well designed library.

Nick

Gillius

  • Administrator
  • User
  • *****
  • Posts: 147
    • http://www.gillius.org/
Re: macros used in GNE
« Reply #4 on: July 29, 2007, 11:12:09 PM »
Well as I said I only expose HawkNL in two areas: one is the NL network enum passed into GNE's initGNE method, and the other is allowing users to construct GNE Address objects from NLaddress structs. The other exposures are there only because they are private implementation details (variables) of classes that are exposed to the user. To get rid of that I would have to use something like the pimpl idiom to conceal the implementation of a class from the user headers. It had been my thought towards the end of when I was still developing GNE to remove entirely the dependency on nl.h from the user code, precisely because of the fact in case I needed/wanted to use a different library. Now, HawkNL isn't maintained anymore. But even with the amount of functionality that I use in HawkNL anyway I could just "integrate" the code into GNE by taking what I want and modifying it to be better for the user's environment, as well as removing a hard-to-find dependency. Until a recent post on this board discussing HawkNL being obtained by yum through Red Hat, I didn't even think HawkNL was included as a package for any Linux distribution.
Gillius
Gillius's Programming http://www.gillius.org/