Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming Technology

Web Interfaces for C++ Introspection? 66

Posted by Cliff from the tune-ups-while-still-executing dept.
Milo_Mindbender asks: "For a C++ application I'm working on I want to be able to pop up an interface to a class that will display all the 'tunable' parameters of the class and let me inspect/modify them, while the program is running. The catch is that I'm running on a minimal embedded OS with Open GL but no GUI library. Rather than porting a widget set or writing my own, I was thinking about having the application talk to a web browser, and then use the browser to display the GUI, take user input, and finally push the data back to the app. The classes have metadata that describes the public data locations/types so they can be accessed, but not being a web-wizard I'm not sure of the best way of generating the information I need to create the UI. My first thought is to generate HTML and push that to the browser, but it seems like there must be a better way than this, maybe someone has written a library specifically for doing this sort of thing? Any help/suggestions would be appreciated!"
This discussion has been archived. No new comments can be posted.

Web Interfaces for C++ Introspection? More

Web Interfaces for C++ Introspection?

Comments Filter:

  • Why GUI (Score:4, Insightful)

    by the eric conspiracy ( 20178 ) on Saturday December 03, 2005 @10:53PM (#14176359)
    Any particular reason that it has to be a GUI? Something like an ncurses interface might be a lit easier.

    • Re:Why GUI (Score:2, Insightful)

      by billcopc ( 196330 )
      I second this opinion. Remote debugging or "tuning" could be rather easily done from a serial terminal. There's no need for an HTTP protocol and the sloppy hassle of HTML forms; just a quick text console, not unlike those found in games such as Quake.

      get myvar, set myvar xxyy, toggle myvar, listvars etc etc

      Yeah, web interfaces are nice for end-users, but since you just want to debug your own one-off app and it's quite likely you will be the only person doing it, might as well be lazy - I mean efficient -
      • Too right - follow KISS and you won't go far wrong.

        And if you want a GUI, then it's a simple bit of Python to add a front end to that serial comms and text. A web interface is usually a pretty dumb move, unless you're sure that the person using the interface won't have the relevant software.

        Grab.

    • Rather than porting a widget set or writing my own, I was thinking about having the application talk to a web browser, and then use the browser to display the GUI, take user input, and finally push the data back to the app.

      WARNING: BUZZWORD COMPLIANCE ALERT!!!

      Uhh, isn't this exactly what AJAX was invented for? If his "minimal embedded OS with Open GL but no GUI library" had an eency-weency [itsy-bitsy?] little webserver, like thttpd, with some sort of an AJAX extension, then he could interactively push

  • This question is odd.... (Score:3, Insightful)

    by Manip ( 656104 ) on Saturday December 03, 2005 @10:55PM (#14176364)
    I find this question somewhat odd... The guy clearly knows C++ and is able to develop on an embedded OS which isn't an easy thing to do but yet can't write himself a simple web-server, which a lot of us learnt during our first few years of programming in something nooby like VBA or Java...

    So either he isn't being completely accurate in so much that he might not be as knowledgeable as he claims or just by freak chance managed never to write a web-server in a couple of hours like everyone else...

    • Well, I'm a junior in college and a computer science major, studying things across the spectrum from kernels to compilers to recursive descent parsers to Turing machines and much of the stuff in between. I've had several jobs dealing with web or Intranet applications and embedded development. And I've never written a web server. I've never even considered it. I've written some pretty low-level CGI bits for C/C++ applications (parsing query strings and POSTs) and I've written some TCP/IP network communicatio
      • I'm studying for a CS masters and a UNIX-based web server is the final project of our "Systems programming in C" course. It's an optional course though. Oh and BTW, fork() and the unix process model sucks as a parallellism primitive. I love Win32 threads and io completion ports :/
        • Unix has threads, too. Recent Linux kernels have particularly fast threading.

        • Re:This question is odd.... (Score:4, Informative)

          by Short Circuit ( 52384 ) * <mikemol@gmail.com> on Sunday December 04, 2005 @01:48AM (#14176849) Homepage Journal
          Oh and BTW, fork() and the unix process model sucks as a parallellism primitive.

          You're right...you should use pthreads or nptl [wikipedia.org] instead.

          Some advice from someone who makes the same mistake every now and then...When you learn something in class, don't talk about it on Slashdot for at least a month. That'll give you a chance to think before you type.

          In the mean time, dissing UNIX around here is likely to get you modded "Troll."
          • Sure, but that's not traditional UNIX and is not guaranteed to exist under all unix systems. On Windows you can count on a reasonably decent threading model being there. Although it may be argued that limiting yourself to Windows is just as limiting as limiting oneself to a few particular unixes.
            • Would you argue that Windows XP SP2 qualifies as Traditional Windows? It exemplefies thatAPIs available under one version may not be available, or even behave the same, under others.

              Other examples:
              • NT kernel vs DOS kernel. The Windows 95 era should have been the Windows NT4 era.
              • Early versions of DirectX compared with later ones. You can't run many old games under later versions of Microsoft's "Gaming API".
              • Win16 not supported in WoW for 64-bit Windows. In the Real World, there are still a lot of 16-bit Wi

        • Personally, I think threads are a stupid thing to use unless there's no other way to achieve your goal. I would suggest looking at the 'epoll' call on Linux and the kernel queue (kqueue?) on BSD. select and poll aren't that great.

        • Re:This question is odd.... (Score:5, Informative)

          by GileadGreene ( 539584 ) on Sunday December 04, 2005 @04:18AM (#14177280) Homepage
          BTW, threads of any sort suck as a parallelism primitive. A better choice would be CSP-style process networks, as implemented in occam [kent.ac.uk] and C++CSP [twistedsquare.com]. Erlang [erlang.org] implements a similar (but not identical) concurrency model.

          Why would you want to use a CSP-style concurrency model instead of threads? To quote from the occam compiler homepage:

          CSP has a compositional and denotational semantics, which means that it allows modular and incremental development (refinement) even for concurrent components. In turn, this means that we get no surprises when we run processes in parallel (since their points of interaction have to be explicitly handled by all parties to these interactions). This is simply not the case for standard threads-and-locks concurrency, which have no formal denotational semantics and by which we get surprised all the time.

          In layman's terms, you get concurrency that can be built up from easily understood pieces (instead of a monolithically concurrent system with locks scattered throughout the code), and an underlying theory of concurrency that lets you understand and analyze your design and ensure that it is, for example, free of deadlocks (I've personally created complex networks of 1000+ interacting processes in a dynamically evolving topology, with nary a hitch). And did I mentioned that the context-switching performance of most of these systems is amazingly good?

        • Oh and BTW, fork() and the unix process model sucks as a parallellism primitive. I love Win32 threads and io completion ports :/

          I see: you indeed are a future Windows programmer, and you are ready to produce the same bloated and flaky software that your predecessors produce.

          (FWIW, you don't have to use fork for parallelism on UNIX; UNIX systems have always had better threads than Windows, it's just that UNIX programmers have the good sense not to use threads if they can help it.)
      • Out of the 20 or so programmers I've known rather well over my life so far, about half have resorting to building their own web server (even in languages like Perl). They've done it for kicks (because, seriously, HTTP 1.0 is *easy*) or for practical reasons (like for the sort of problem you're having). Servers like Apache and IIS are for heavy loads and high reliability - but HTTP itself is a really simple protocol. Writing your own server should not only be reasonably trivial for someone such as yoursel
        • agreed also if you say wan't a web based admin interface to a daemon app then things like cgi aren't really the kind of interface you want, you are going to have to write the cgis as seperate apps then connect them to your main daemon somehow.

          whereas if you code the web server yourself you can just build it into your daemon and access the daemons transiant data through direct procedure/method calls or even direct reading of global variables or fields.

          and provided you don't care about things like chunked enc

    • Re:This question is odd.... (Score:1, Interesting)

      by Anonymous Coward

      The guy clearly knows C++ and is able to develop on an embedded OS which isn't an easy thing to do but yet can't write himself a simple web-server

      Sorry, you've just given yourself away as an amateur. Every professional with two brain cells to rub together quickly realises that writing everything yourself is a non-starter, and that decent libraries can make you more productive than dozens of programmers who choose to write everything themselves.

    • Well, I didn't assume he was asking how to write an http server. I assumed he was looking for introspection facilities like Java's, which C++ doesn't have. I wish it did. typeinfo could be that if any compiler manufacturer implemented a rich enough set of extensions to it.

      It would be nice to get, at runtime, a list of pointers to functions a class supported as well as their names and type signatures. It would also be nice to be able to get a list of members and their types and their offsets from the beginning of the class.

    • The guy clearly knows C++ and is able to develop on an embedded OS which isn't an easy thing to do but yet can't write himself a simple web-server, which a lot of us learnt during our first few years of programming in something nooby like VBA or Java

      I've been using C for over 25 years, and C++ for nearly 20, and I don't remember writing a web server when I was a newbie.
      (Of course, the web did not yet exist when I was a newbie, so that's probably why.)
      The point is, I've also written device drivers and othe

  • Well, you don't necessarily need a web browser... (Score:3, Insightful)

    by FooAtWFU ( 699187 ) on Saturday December 03, 2005 @10:58PM (#14176378) Homepage
    Instead of embedding a mini HTTP server into your application so it can talk to an application, you could just write a GUI in your favorite language (Java? C++? Java?) and talk to it with good old-fashioned TCP/IP (or even UDP) network sockets. Probably a lot simpler to define your own stuff than to deal with a big old standard like HTTP and parsing all the browsers which may be mangling your requests.

    If it must be accessible via the web/intranet/browser/etc, set up some of your favorite CGI/PHP/JSP/Python/Ruby and have it talk to the application via TCP/IP and to the browser with HTTP.

    • To solve his problem he wouldn't need to "parse all browser's requests." He could code it simply for the one he uses. Obviously if this is truly a minimal system, a pre-packaged web server is likely to be more than his resources can bear. But using a web interface eliminates the need to write a client side app.

      So yeah, write a text interface to a socket, and telnet to it from off the box. It may not be clickably pretty, but he can probably solve his problems quickly. It's what I used to do twelve yea

  • Well, C++ doesn't have any metadata on its own, so you must be using something third-party to create it. Since any library that provides the functionality you need will read that data, we need to know what it is!

    Of course, I don't know of any such libraries, but anyway. I am very interested in how you'd be doing reflection-type stuff in C++. I'd like to investigate doing that to do mock objects, like nmock does.

  • Remote XUL (Score:3, Informative)

    by dorkygeek ( 898295 ) on Saturday December 03, 2005 @11:09PM (#14176417) Journal

    You may be interested in XUL [mozilla.org] then. Especially, in remote XUL [mozilla.org].

    Also, see Remote XUL Application Development with_Mozilla I [mozilla.org] and Remote XUL Application Development with Mozilla II [mozilla.org].

    You may even be able to create the UI XML files automatically from your interfaces, using a script, or introspection.

    You can then send the data back to your host, using RPCs or a REST-like interface.

  • Light minimal XML interface (Score:3, Interesting)

    by Zarf ( 5735 ) on Saturday December 03, 2005 @11:29PM (#14176492) Journal
    You might consider a very minimal XML interface on top of a very very very simple HTTP server. Your UI could live on a completely different device on a completely different server... or on the same server in a different application stack. You could run your service on port 8080 or something if you didn't want to run it on 80 to prevent

    You could display your state as a single XML document that is gotten at a single URL. Each setting could be manipulated by posting to a URL specified in the XML document. These sets of documents and post URLs could become a simple CGI set of interfaces you could describe for anything from webservers, application servers, or other web-aware C++ programs to hook into.
    • This is what I was thinking, too.

      I suspect the biggest bang for the buck would be embedding a python interpreter with a subset of its standard library. Figure maybe 2-3 MB VM size and about the same on disk. Everything the poster needs is in there; the web server, the xml, and the ability to update his C++ code in-process.

      • Figure maybe 2-3 MB VM size...

        Better hope that "minimal embedded OS" he's using isn't running on a "minimal embedded system" as well. Otherwise 2-3 MB of VM may well be out of the question.

        • Can he open a socket? Can he put characters to it? Can he read characters from it? Maybe 2 or 3 MB is too little to do that in. What do you need to read and write text? Maybe 128 MB or so?

          • Can't tell if you're joking or not, but (modern) computers since the beginning of time read and wrote text. The mainframe at MIT worked with text (and much more) back when the first megabyte stick of memory cost over a million dollars, without adjusting that sum for inflation. Of course, you need enough memory to hold the text you're working with, but to work with it, you need, at most, kilobytes.

            • So it sounds like most devices could read and write text now-a-days right? If that's so then maybe they could write text that was generically formatted into some kind of mark-up language... an ML. We want something really generic so let's call it "XML" and all this XML would do is represent a data structure. You would print it to a socket. So even if you had a very teeny tiny embedded device that at least could do networking, could at least use a couple of Kbytes of RAM that device's data structures could b

              • XML is pretty and human readable, but there's a lot of space wasted to make it so - especially for just representing a small structure. A binary markup language would probably be better. For example, two bytes of ASCII would get you the < and one character of an XML tag (even less in Unicode) whereas with a special binary format, you could represent the tag as 1 "start of tag" byte followed by 1 "type of tag" byte. Not pretty and not human readable, but you're proposing having another machine parse it

                • Not pretty, but if space and processing power is truly at such a premium...

                  At this point I'll point out that the original poster was talking about deploying an entire HTTP server with HTML in the device. If it was even possible to do that, then we know the device was in a class that would allow such waste as an XML export. His idea of pushing HTML from his device to the browser is perhaps one of the single worst ideas I've ever heard. If this is a one off project that nobody cares about, then fine, but i

  • GLUI (Score:3, Interesting)

    by tfinniga ( 555989 ) on Sunday December 04, 2005 @12:33AM (#14176670)
    Have you looked at GLUI [unc.edu]?
  • It would help if you said what the OS was, or at least specified what APIs were available natively. I would suggest that you should not discount the option of using X11 instead of a browser, at least not without evaluating the pros and cons.

    Assuming only a socket API, the easiest thing to do is use a simple text-based protocol, talking to a minimalistic TCP server, probably written in PHP, Perl, or Java, and acting as a FastCGI script. You'll find it much quicker and less error prone, chatty, and code-heav
    • It would help if you said what the OS was

      He did, it's a minimal embedded OS. There are a thousand and one of these out on the market, plus tens of thousands of others written from scratch in-house.

  • What about ICE or CORBA? (Score:3, Insightful)

    by motus ( 617094 ) on Sunday December 04, 2005 @02:01AM (#14176884)
    I think the challenge here is not how to represent the data visually (i.e. web/GUI), but how to control a C++ object from the remote application. For that puropse, I would suggest CORBA. You can define all controllable classes in CORBA IDL, compile it into C++ code and integrate with your existing application with minimum efforts. CORBA client should not necessarily written in C++ - it can be Java or Python, for example. I have very good experience with omniORB (http://omniorb.sourceforge.net/ [sourceforge.net]). It supports both C++ and Python, and I use a bunch of Python scripts as a test harness for my C++ CORBA services. Besides omniORB, there are lots other decent implementations of CORBA in many programming languages (http://www.omg.org/technology/corba/corbadownload s.htm [omg.org]).

    PS. Good alternative to CORBA is ICE (http://www.zeroc.com/ice.html [zeroc.com]), which is basically the same thing as CORBA, and founded by one of the CORBA gurus. ICE has much better C++ mapping, and lots of other nice features.

    Hope this helps!

  • if you are doing openGL stuff how about throwing in an interactive debug mode. I am pretty sure openGL can sned lines of text in and out just have the app load a translucent console window when launched with --debug
  • I had a similiar problem with how to write a nice GUI in Perl and have an application that can run over a network? I used a webserver and CGI.pm. I don't know whether there are CGI.pm-like libraries for C++, though...
  • Instead of:

    Webapp Your App

    Consider:

    Webapp Database Your App

    Now you have 2 simpler problems: get your app to get its data from a database, and get your webapp to display and modify values in the database.

  • Use Qt (Score:3, Interesting)

    by e8johan ( 605347 ) on Sunday December 04, 2005 @08:38AM (#14177819) Homepage Journal
    Use Qt and declare your tunable parameters as properties. Writing a minimal server using Qt is trivial.

  • It's a tiny web server with CGI support. You didn't say anything about your target platform, so it's possible that it's still to large, but it's only about 70KB compiled. It would have to be ported to your OS, of course, but at only 8000 lines of code, that shouldn't be too difficult.

    As for what to serve up, in the interest of keeping the code small I would suggest defining a custom XML markup rather than HTML. That way your on-board code doesn't have to generate all of the formatting markup to make it

  • I'm not sure if I'm on the same page, but could you create bindings using ruby or python and modify your class attributes using an interactive shell like irb?
  • Use something like libhttpd [hughes.com.au] or thttp [acme.com] to embed a webserver. Using ideas based on REST [wikipedia.org], design a RPC system (can use XML-RPC or if you're bent on making it a web based frontend, then maybe JSON [json.org]-RPC) to communicate with the GUI.

  • How about minimal server-side XML + Client side XSLT?

    Requirements:

    1. minimal http server (There is bound to be BSD licensed code for this somewhere on the net)
    2. Code to generate simple (possibly flat?) XML file. You don't need a library for this, you could just pretend it's a text file if the XML is simple enough.
    3. XSLT and CSS stylesheets

    Now all you have to do is serve the XML and stylesheet, attach the stylesheet to the XML file and watch any XSLT-aware browser do the heavy work of transforming that simp

  • Sorry, I guess I missed a few details about what I was looking for. The main thing I was interested in was some library that would autogenerate the http/xml code necessary to display a variable inspection/modification GUI in a web browser. It would be nice if it was already integrated in a library that also did the minimal web-browser stuff needed to send the page to the browser, fill in the data and then manage getting the data back.

    Specifically, each object in the app has metadata describing the class m
  • This is a great question. Sounds like you have a few different problems:
    - Changing the runtime state (introspection)
    - The GUI

    First, I'd like to ask how much memory you have available on the embedded system, and how many classes you are planning on using this introspection approach on. Do you have threads or processes on the embedded platform? Does your parameter tuning program have to run on multiple platforms?

    If you have enough memory, you may want to embed something like lua, tcl, ruby, guile or pyt

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close