This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Allow C++ or C99 in sim/*?



C99 isn't necessarily completely implemented, as has been pointed out.

While i occasionally like to use // comments, and find them more
visually appealing than /* */ comments, i don't think there's a strong
win in using them.

declarations "anywhere," IMO, just clutter things.  Personally, i'd
limit declarations to start of blocks and to perhaps one or two other
places, e.g. declaring local vars for use in 'for' loops.  ("for int i
= ...")

However, these things have been in c++ for a while, right?

I hope so. Was using them in '90 :-)


- C++ which would also allow access to objects and (ulgh?) templates
(replacement for the sim-endian macro stuff?)


If the sim tree goes there to any large extent, then it would force
some simulator maintainers to learn C++.  I don't see that happening
any time soon, at least for one particular maintainer...  8-)


I guess it wouldn't hurt (much) to:


* make infrastructure compatible (to the extent easily possible),

* tolerate use of some (relatively minor) new language features in
  existing simulator code, and

* *possibly* encourage implementors of new sims to do so in different
  languages.


I must also say that performance *is* a concern. Our goal in doing sim work was to be able to real code (i.e., "telnet into the operating system running on the simulator, communicating via the simulated ethernet device which talks out on the real network..."). If improving the system meant slowing it down much, then that would be a real lose.

(honestly, i don't know enough about modern C++ to know if using it
extensively is likely to mean decrease in performance... but it's not
clear that there's great incentive for me to find out.  8-)

Two parts, and two features, come to mind:


- the sim-endian code which, I think, would work better using templates

- the h/w devices which are objects with virtual methods

I suspect a careful choice of language features will avoid the performance problems - no multiple inheritance for instance.

after that, well who knows.

Andrew



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]