Go to the FreeLists Home Page Home Signup Help Login
 



[openbeosnetteam] || [Date Prev] [07-2003 Date Index] [Date Next] || [Thread Prev] [07-2003 Thread Index] [Thread Next]

[openbeosnetteam] Re: PPP: dial-on-demand

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: openbeosnetteam@xxxxxxxxxxxxx
  • Date: Fri, 04 Jul 2003 15:58:56 +0200 CEST
"Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx> wrote:
> > Please not - for the small libkernel_ppp.a this might suitable
> > (although I wouldn't do it), but not for a whole networking stack.
> > I certainly don't want to read 10 MB of net stack modules before 
> > going
> > online (slight exaggeration).
> > C is really not so bad that I would want to live with the bloat
> > currently introduced by a C++ solution.
> The 10 MB bloat is only there because we use a static library.
> For R2 we could introduce a C++ stack without having the bloat.
> Currently, it is just a workaround. It will work, but not as 
> efficient as it
> could do.
> After R1 it will work very good. Or do you think differently?

Yes, I do - I don't want to have that bloat in R1, even if it's only 
temporary, at least not for the whole stack.

> It is clear that nobody should ever want to create an instance of the
> manager object, but this is the same as making all methods public and 
> saying
> that some methods must not be used because they are internal methods, 
> though
> they are defined public.

If the ppp stuff is clearly separated from the rest, and the 
libkernel_ppp.a is reasonably small, I wouldn't mind if you go C++ only 
there - just take care of what you do.

> Probably we have the wrong programming language, but that is another 
> topic.
> :)

I have to disagree: C is not the wrong language, C++ is just better :)

[...]
> FSM_info structure even if you should not do that.

#define private public
;-)

Adios...
   Axel.






[ Home | Signup | Help | Login | Archives | Lists ]

All trademarks and copyrights within the FreeLists archives are owned by their respective owners.
Everything else ©2007 Avenir Technologies, LLC.