orbitcpp-list

[orbitcpp-list] Implementation inheritance

[ERDI G. <ca...@ca...>]

Loaded with enthusiasm after hearing about Murray's success with ORBit/C++
and the Hello World demo, I jumped on it to play with it.

The first thing I wanted to figure out was how implementation inheritance
works. So I created a Hello2 interface that extends Hello with a new "foo"
method. Without looking at any CORBA docs, the obvious thing to do was:

class Hello_impl: public POA_hellomodule::Hello
{
public:
	virtual char* helloWorld (const char* greeting) throw (CORBA::SystemException);
};

class Hello2_impl: public POA_hellomodule::Hello2,
		   public Hello_impl
{
public:
	void foo () throw (CORBA::SystemException);
};

This didn't quite work:

server.cc: In function `int main(int, char**)':
server.cc:25: cannot declare variable `servant' to be of type `hellomodule::Hello2_impl'
server.cc:25:   because the following virtual functions are abstract:
generated/helloworld-cpp-skels.hh:62: 	virtual char* POA_hellomodule::Hello::helloWorld(const char*)

server.cc:26: request for member `_this' is ambiguous
generated/helloworld-cpp-skels.hh:51: candidates are: _orbitcpp::stub::hellomodule::Hello* POA_hellomodule::Hello::_this()
generated/helloworld-cpp-skels.hh:109:                _orbitcpp::stub::hellomodule::Hello2* POA_hellomodule::Hello2::_this()

So, I thought, yeah right, I'm duplicating POA_hellomodule::Hello in
Hello2_impl since POA_hellomodule::Hello2 is inherited from it.

After playing around with every combination of virtual inheritance, I
decided to look for 'canonical' answers on the Web. However, the pages
I've found all boiled down to my initial solution.

So I guess the above code should work, in which case it is ORBit's fault.
If it's not, I'd like to hear how you do implementation inheritance.

-- 
   .--= ULLA! =---------------------.   `We are not here to give users what
   \     http://cactus.rulez.org     \   they want'  -- RMS, at GUADEC 2001
    `---= ca...@ca... =---'
As a computer, I find your faith in technology amusing.

[orbitcpp-list] Re: cpp: Gratuitous code formatting change

[Michael M. <mi...@xi...>]

Hi Sam,

On Sat, 2002-03-02 at 01:00, Sam Couter wrote:
> I figured that the stubs and skeletons generated by orbit-idl were far
> from simple, and that indent would not be helpful.

	This used to be the case; now the C output is extremely simple, except
perhaps for the method lookup methods, and they're never going to look
simple ;-)

	So I'd be in favour of stripping out the indent phase and making the
code look nice. The more reliability, and less cruft we have to fork the
better as far as I'm concerned.

	If someone would write a mini pre-processor, and re-write libIDL to
clean them both up I'd be even happier ;-)

	Regards,

		Michael.

-- 
 mm...@gn...  <><, Pseudo Engineer, itinerant idiot

Re: [orbitcpp-list] cpp: Gratuitous code formatting change

[<bb...@ya...>]

In general Artistic Style does a better job on C++ code, but I've found
that having multiple braces on one line causes problems.

That said, I imagine it would be a fairly simple job to write a perl
script to put newlines after braces, then run astyle, or indent...


 --- Sam Couter <sc...@bi...> wrote: 
> I figured that the stubs and skeletons generated by orbit-idl were
> far
> from simple, and that indent would not be helpful.
> 
> And yesterday, out of curiosity (and a desire to be able to actually
> read the code I was looking at) I ran indent on some of the generated
> code. Nasty, total failure. I'm confident that indent does not solve
> any
> formatting problems for the generated C++ code.
 

http://movies.yahoo.com.au - Yahoo! Movies
- Vote for your nominees in our online Oscars pool.

[orbitcpp-list] Re: cpp: Gratuitous code formatting change

[Sam C. <sc...@bi...>]

Chris Waters <xt...@de...> wrote:
> From the info file:
>=20
>   "While an attempt was made to get `indent' working for C++, it will
> not do a good job on any C++ source except the very simple."
>=20
> That's not the (quite) same as not working.  I actually ran indent on
> the example Murray provided, and the result looked fine.  I've also
> used indent on other C++ code in the past and been perfectly satisfied
> with the results.  Maybe we should try out some more complex
> real-world examples, and see if it's good enough for our purposes.

I figured that the stubs and skeletons generated by orbit-idl were far
from simple, and that indent would not be helpful.

And yesterday, out of curiosity (and a desire to be able to actually
read the code I was looking at) I ran indent on some of the generated
code. Nasty, total failure. I'm confident that indent does not solve any
formatting problems for the generated C++ code.
--=20
Sam "Eddie" Couter  |  mailto:sc...@bi...
Debian Developer    |  mailto:ed...@de...
                    |  jabber:sa...@ja...
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

[orbitcpp-list] Re: TypeCode operations

[Michael M. <mi...@xi...>]

Hi Sam,

On Thu, 2002-02-28 at 11:12, Sam Couter wrote:
> I've committed the TypeCode operations to the cpp branch of ORBit2. Most
> of them are just copied straight from STABLE, one had to be modified to
> reflect the changes in the TypeCode struct in ORBit2.

	Great :-)

> I've also added a bunch of tests for those TypeCode operations in
> test/everything/client.c.

	That's really good.

> I can now use the cpp branch of ORBit2 to compile and link a basic
> "Hello World" application. It crashes somewhere in
> CORBA_ORB_resolve_initial_references(), but that just gives me something
> else to do. :)

	Great work to Murray and You !

		Michael.

-- 
 mm...@gn...  <><, Pseudo Engineer, itinerant idiot

[orbitcpp-list] TypeCode operations

[Sam C. <sc...@bi...>]

I've committed the TypeCode operations to the cpp branch of ORBit2. Most
of them are just copied straight from STABLE, one had to be modified to
reflect the changes in the TypeCode struct in ORBit2.

I've also added a bunch of tests for those TypeCode operations in
test/everything/client.c.

I can now use the cpp branch of ORBit2 to compile and link a basic
"Hello World" application. It crashes somewhere in
CORBA_ORB_resolve_initial_references(), but that just gives me something
else to do. :)
--=20
Sam "Eddie" Couter  |  mailto:sc...@bi...
Debian Developer    |  mailto:ed...@de...
                    |  jabber:sa...@ja...
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

[orbitcpp-list] lib patch for .spec

[Brian C. <bc...@th...>]

The .spec still has problems. It tries to package files that don't exist
in the 'install' target, and it fails to run ldconfig after installing the
libs.

Here's a patch.

b.c.

[orbitcpp-list] Re: spec patch

[Brian C. <bc...@th...>]

... some thing for the .spec.in, which makes a bit more sense.

b.c.

Re: [orbitcpp-list] spec patch

[Sam C. <sc...@bi...>]

Brian Craft <bc...@th...> wrote:
> Here's a fix for the .spec changelog, so rpm won't barf on it.

And it's really as simple as that? The order of the entries was wrong?

Anyway, I've made these edits to the .spec.in file (the .spec file is
generated at configure time) and committed them.
--=20
Sam "Eddie" Couter  |  mailto:sc...@bi...
Debian Developer    |  mailto:ed...@de...
                    |  jabber:sa...@ja...
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

[orbitcpp-list] spec patch

[Brian C. <bc...@th...>]

Here's a fix for the .spec changelog, so rpm won't barf on it.

b.c.

[orbitcpp-list] ORBit-C++ 0.30.4

[Sam C. <sc...@bi...>]

Okay, so I goofed the previous release. The orbitcpp-config script and
the orbitcpp.m4 file (contains M4 macros used by autoconf) were
incorrect.

These problems have been corrected, and the 0.30.4 release is available
from SourceForge:

http://sourceforge.net/projects/orbitcpp/
--=20
Sam "Eddie" Couter  |  mailto:sc...@bi...
Debian Developer    |  mailto:ed...@de...
                    |  jabber:sa...@ja...
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

[orbitcpp-list] Re: cpp: Gratuitous code formatting change

[Chris W. <xt...@de...>]

On Thu, Feb 28, 2002 at 09:14:50AM +1100, Sam Couter wrote:

> Any reason why ORBit-C++ can't do the same when 'indent' is available?
> Never mind, I just read the man page... C only, not C++. Bugger.

From the info file:

  "While an attempt was made to get `indent' working for C++, it will
not do a good job on any C++ source except the very simple."

That's not the (quite) same as not working.  I actually ran indent on
the example Murray provided, and the result looked fine.  I've also
used indent on other C++ code in the past and been perfectly satisfied
with the results.  Maybe we should try out some more complex
real-world examples, and see if it's good enough for our purposes.

-- 
Chris Waters           |  Pneumonoultra-        osis is too long
xt...@de...       |  microscopicsilico-    to fit into a single
or xt...@sp... |  volcaniconi-          standalone haiku

Re: [orbitcpp-list] build issues, work-around

[<bb...@ya...>]

I would prefer to see an autoconf test. 
All STL implementation from now on must support ostringstream to have
a hope of calling themselves standard compliant. For this reason I'd
prefer to leave the ostringstream in there. It is legal code and it
follows "the C++ way" of doing things. Only legacy implementations of
the STL would have a problem.

From memory there is a standard compliant STL drop-in for gcc-2.95
(libstdc++-2.95.10 from memory) which supports ostringstream.

Note that gcc 2.95 requires the -fhonor-standard flag in some cases
to make the standard compliance code kick in.


--
Rich

 --- Brian Craft <bc...@th...> wrote: 
> Would you accept a patch to fix the ostringstream thing? This could
> be either a
> patch to conditionally use ostrstream (which I believe would
> require an
> autoconf test to see which is available), or a patch to ditch it
> entirely and
> use sprintf to a static buffer. The latter has the disadvantage
> that it could
> overflow, but I think it's a safe call that no one will have more
> than a google
> or two of skeleton wrappers. So, say, 100 bytes is way more than
> needed.


http://movies.yahoo.com.au - Yahoo! Movies
- Vote for your nominees in our online Oscars pool.

Re: [orbitcpp-list] build issues, work-around

[Brian C. <bc...@th...>]

I seem to have the build working on RH 6.x, now. I punted egcs and installed
gcc 2.95, as someone suggested. There's still the issue of the stdc++ not
supporting ostringstream.

Would you accept a patch to fix the ostringstream thing? This could be either a
patch to conditionally use ostrstream (which I believe would require an
autoconf test to see which is available), or a patch to ditch it entirely and
use sprintf to a static buffer. The latter has the disadvantage that it could
overflow, but I think it's a safe call that no one will have more than a google
or two of skeleton wrappers. So, say, 100 bytes is way more than needed.

b.c.

Re: [orbitcpp-list] OrbitCpp (Urgent, please help)

[<bb...@ya...>]

Try orbitcpp-0.30.3, this has some work in it to make the skel output
ISO compliant (works OK for me on gcc-3.0.2). This also requires
ORBit-0.5.10 so you'll need to update that.

But it looks like you have another problem in here.

Was the Makefile built by the top-level configure script? Neither
example links the object files for the stubs.

You will see in the compilation section at the top that various
helloworld-cpp*.cpp files are compiled, but I don't see their object
files in the compile and link command line for client.cpp.

--
Rich


 --- Marcus Blikra Akre <Mar...@st...> wrote: > Hi.
> 
> We are a group of students trying to to develop
> a CORBA application in Linux. Sorry to say we have
> some problems so we hope that you can help us.
> 
> This is the case:
> 
> We have compiled Orbit 0,5.8 and OrbitCpp 0.27,
> and it seems to work. (Eg echo client/server works,
> orbit-idl works etc)
> 
> But when compiling the helloworld example with gcc 3.0.1
> som errors occur.
> 


http://movies.yahoo.com.au - Yahoo! Movies
- Vote for your nominees in our online Oscars pool.

[orbitcpp-list] OrbitCpp (Urgent, please help)

[Marcus B. A. <Mar...@st...>]

Hi.

We are a group of students trying to to develop
a CORBA application in Linux. Sorry to say we have
some problems so we hope that you can help us.

This is the case:

We have compiled Orbit 0,5.8 and OrbitCpp 0.27,
and it seems to work. (Eg echo client/server works,
orbit-idl works etc)

But when compiling the helloworld example with gcc 3.0.1
som errors occur.

The idl file was compiled with orbit-idl helloworld.idl
and orbit-idl -lc++ helloworld.idl.

I really hope you can help us, or know someone who can.
We have been trying to fix this for at lest 20 hours now. :)

Best regards

Marcus Akre & Co.


Makefile output:

$ make
g++ -D__linux__ -DNEW_CPP_STD -D__STL_PTHREADS -DSTDC_HEADERS
-I/usr/local/include/g++-v3/ -I/usr/local/lib/glib-2.0/include/
-I/usr/local/include/glib-2.0/ -I/usr/lib/glib-2.0/include/
-I/usr/local/include/orb/ -I. -c helloworld-cpp-stubs.cc

g++ -D__linux__ -DNEW_CPP_STD -D__STL_PTHREADS -DSTDC_HEADERS
-I/usr/local/include/g++-v3/ -I/usr/local/lib/glib-2.0/include/
-I/usr/local/include/glib-2.0/ -I/usr/lib/glib-2.0/include/
-I/usr/local/include/orb/ -I. -c helloworld-cpp.cc

g++ -D__linux__ -DNEW_CPP_STD -D__STL_PTHREADS -DSTDC_HEADERS
-I/usr/local/include/g++-v3/ -I/usr/local/lib/glib-2.0/include/
-I/usr/local/include/glib-2.0/ -I/usr/lib/glib-2.0/include/
-I/usr/local/include/orb/ -I. -c helloworld-cpp-common.cc

g++ -D__linux__ -DNEW_CPP_STD -D__STL_PTHREADS -DSTDC_HEADERS
-I/usr/local/include/g++-v3/ -I/usr/local/lib/glib-2.0/include/
-I/usr/local/include/glib-2.0/ -I/usr/lib/glib-2.0/include/
-I/usr/local/include/orb/ -I. -c helloworld-cpp-skels.cc

g++ -D__linux__ -DNEW_CPP_STD -D__STL_PTHREADS -DSTDC_HEADERS
-I/usr/local/include/g++-v3/ -I/usr/local/lib/glib-2.0/include/
-I/usr/local/include/glib-2.0/ -I/usr/lib/glib-2.0/include/
-I/usr/local/include/orb/ -I. -c helloworld-impl.cc

g++ -D__linux__ -DNEW_CPP_STD -D__STL_PTHREADS -DSTDC_HEADERS client.cc
-o client -
I/usr/local/include/g++-v3/ -I/usr/local/lib/glib-2.0/include/
-I/usr/local/include/glib-2.0/ -I/usr/lib/glib-2.0/include/
-I/usr/local/include/orb/ -I. -L/usr/local/lib -lORBit -lIIOP
-lORBitutil -lglib -lm -L/usr/lib -L/lib -L.

/tmp/cc1FOs4T.o: In function `main':
/tmp/cc1FOs4T.o(.text+0x1f): undefined reference to
`CORBA::ORB_init(int&, char**, char const*)'
/tmp/cc1FOs4T.o(.text+0x4c): undefined reference to
`CORBA::ORB::string_to_object(char const*)'
/tmp/cc1FOs4T.o(.text+0xa4): undefined reference to
`_orbitcpp::stub::hellomodule::Hello::helloWorld(char const*)'
/tmp/cc1FOs4T.o(.rodata+0xa4): undefined reference to
`TC_hellomodule_Hello_struct'
/tmp/cc1FOs4T.o: In function `CORBA::release(CORBA::Object*)':
/tmp/cc1FOs4T.o(.gnu.linkonce.t._ZN5CORBA7releaseEPNS_6ObjectE+0x16):
undefined reference to
`_orbitcpp::release_guarded(CORBA_Object_struct*)'
/tmp/cc1FOs4T.o: In function
`hellomodule::Hello::_duplicate(_orbitcpp::stub::hellomodule::Hello*)':
/tmp/cc1FOs4T.o(.gnu.linkonce.t._ZN11hellomodule5Hello10_duplicateEPN9_o
rbitcpp4stub11hellomodule5HelloE+0x16): undefined reference to
`_orbitcpp::duplicate_guarded(CORBA_Object_struct*)'
collect2: ld returned 1 exit status
make: *** [all] Error 1



Another try:

c++ client.cc -I/opt/test/ex/helloworld/ -I/usr/local/include/orb \
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include/ -I. -I.. \
-L/usr/local/lib -lORBit -lIIOP -lORBitutil -lglib -lm -lorbitcpp \
-lIDL -lorbit-c-backend -lomapi -DSTD_PTHREADS

/tmp/ccpeegtl.o: In function `main':
/tmp/ccpeegtl.o(.text+0xa4): undefined reference to
`_orbitcpp::stub::hellomodule::Hello::helloWorld(char const*)'
/tmp/ccpeegtl.o(.rodata+0xa4): undefined reference to
`TC_hellomodule_Hello_struct'

c++ server.cc -I/opt/test/ex/helloworld/ -I/usr/local/include/orb \
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include/ -I. -I.. \
-L/usr/local/lib -lORBit -lIIOP -lORBitutil -lglib -lm -lorbitcpp \
-lIDL -lorbit-c-backend -lomapi -DSTD_PTHREADS

/tmp/ccVLTgYK.o(.rodata+0x64): undefined reference to
`TC_hellomodule_Hello_struct'
/tmp/ccVLTgYK.o: In function `hellomodule::Hello_impl::Hello_impl()':
/tmp/ccVLTgYK.o(.gnu.linkonce.t._ZN11hellomodule10Hello_implC1Ev+0x1e):
undefined reference to `VTT for hellomodule::Hello_impl'
/tmp/ccVLTgYK.o(.gnu.linkonce.t._ZN11hellomodule10Hello_implC1Ev+0x2a):
undefined reference to `POA_hellomodule::Hello::Hello()'
/tmp/ccVLTgYK.o(.gnu.linkonce.t._ZN11hellomodule10Hello_implC1Ev+0x32):
undefined reference to `vtable for hellomodule::Hello_impl'
/tmp/ccVLTgYK.o(.gnu.linkonce.t._ZN11hellomodule10Hello_implC1Ev+0x49):
undefined reference to `vtable for hellomodule::Hello_impl'
/tmp/ccVLTgYK.o: In function `hellomodule::Hello_impl::~Hello_impl()':
/tmp/ccVLTgYK.o(.gnu.linkonce.t._ZN11hellomodule10Hello_implD1Ev+0x7):
undefined reference to `vtable for hellomodule::Hello_impl'
/tmp/ccVLTgYK.o(.gnu.linkonce.t._ZN11hellomodule10Hello_implD1Ev+0x1e):
undefined reference to `vtable for hellomodule::Hello_impl'
/tmp/ccVLTgYK.o(.gnu.linkonce.t._ZN11hellomodule10Hello_implD1Ev+0x2f):
undefined reference to `VTT for hellomodule::Hello_impl'

Re: [orbitcpp-list] build issues, overloading new()

[Brian C. <bc...@th...>]

hm. Well, the new()/delete() problem can be avoided by creating static
functions that do the real work. But later in the build I run into this:

c++ -DORBITCPP_MAJOR_VERSION=0 -DORBITCPP_MINOR_VERSION=30 -DORBITCPP_MICRO_VERSION=3 -DPACKAGE=\"orbitcpp\" -DVERSION=\"0.30.3\" -DSTDC_HEADERS=1 -I. -I. -I../.. -I../.. -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/include/orbit-1.0 -O2 -march=i386 -mcpu=i686 -Wp,-MD,.deps/CosNaming.pp -c CosNaming.cc  -fPIC -DPIC -o .libs/CosNaming.lo
../../orb/orbitcpp_smartptr.hh: In method `::_orbitcpp::::_orbitcpp::ObjectPtr_out<::CosNaming::BindingIterator,::_orbitcpp::stub::CosNaming::BindingIterator *>::operator CORBA_Object_struct **<::CosNaming::BindingIterator, ::_orbitcpp::stub::CosNaming::BindingIterator *>()':
CosNaming.cc:304:   instantiated from here
../../orb/orbitcpp_smartptr.hh:180: non-lvalue in unary `&'
make: *** [CosNaming.lo] Error 1


Err. yeah. From CosNaming.cc, that's

void _orbitcpp::stub::CosNaming::NamingContext::list(CORBA::ULong how_many,::CosNaming::BindingList_out bl,::CosNaming::BindingIterator_out bi) {
  ::_orbitcpp::CEnvironment _ev;
  ::_orbitcpp::c::CosNaming_NamingContext_list(_orbitcpp_get_c_object(),reinterpret_cast< const CORBA_unsigned_long&>(how_many),reinterpret_cast< ::_orbitcpp::c::CosNaming_BindingList**>(&bl.ptr()),bi,_ev);
  _ev.propagate_sysex();
  if (_ev->_major == ::CORBA_USER_EXCEPTION) {
    throw CORBA::UnknownUserException();
  }
}

... and people think perl is unreadable. ;)

b.c.

[orbitcpp-list] ORBit-C++ 0.30.3 released

[Sam C. <sc...@bi...>]

I've just added the 0.30.3 release of ORBit-C++ to the SourceForge
downloads page.

Summary of changes:

26 February 2002:
    * Release 0.30.3

    - Update IDL compiler to produce legal ISO C++ code (needed for GCC 3.0=
).
      (Richard Andrews)

    - Modify IDL compiler build environment to only build a shared backend
      library, no static library.
      (Braden McDaniel)

    - Fix libtool versioning.
      (Braden McDaniel)

Just like 0.30.2, it requires ORBit 0.5.10 or later to build.

Get it while it's hot from http://sourceforge.net/projects/orbitcpp/
--=20
Sam "Eddie" Couter  |  mailto:sc...@bi...
Debian Developer    |  mailto:ed...@de...
                    |  jabber:sa...@ja...
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

Re: [orbitcpp-list] build issues

[<bb...@ya...>]

From memory RH 6.2 comes with gcc 2.95 - or it is at least available
as RPM in a mirror of contrib packages. Of course you might have
trouble finding an old version like that. rpmfind.net is your friend.

 --- Brian Craft <bc...@th...> wrote: 
> The project I'm working on supports RedHat 6.x, which uses egcs
> 1.1.2. It's
> supposed to support partial specialization, but the orbitcpp build
> fails, like
> so:
> 


http://movies.yahoo.com.au - Yahoo! Movies
- Vote for your nominees in our online Oscars pool.

Re: [orbitcpp-list] build issues, overloading new()

[Brian C. <bc...@th...>]

Looks like overloading new() is the real problem. I get the same error
with this code:

template <class T, class CSEQTYPE>
class UnboundedSequenceTmpl {
  public:
    void* operator new(int size);
};

void* UnboundedSequenceTmpl<char*, int>::operator new(int size)
{
  return 0;
}

Changing this to operator+ avoids the compile error. Dunno what's going on
here.

b.c.

Re: [orbitcpp-list] build issues

[Brian C. <bc...@th...>]

On Tue, Feb 26, 2002 at 09:12:49AM +1100, Sam Couter wrote:
> > o The template partial specialization in orbitcpp_sequence.hh also seems to
> >   only work with recent gcc, though older versions reportedly support partial
> >   specialization. I'm not sure what the problem is.
> 
> I've been building with GCC 2.95 and 3.0, which both work fine. GCC has
> historically had many many problems with templates.
> 
> However, templates are a C++ black art that I don't fully understand,
> and I don't even know what partial specialization is, so I can't help
> with this either. Are you unable to use a recent GCC for some reason?

The project I'm working on supports RedHat 6.x, which uses egcs 1.1.2. It's
supposed to support partial specialization, but the orbitcpp build fails, like
so:

c++ -DORBITCPP_MAJOR_VERSION=0 -DORBITCPP_MINOR_VERSION=30 -DORBITCPP_MICRO_VERSION=3 -DPACKAGE=\"orbitcpp\" -DVERSION=\"0.30.3\" -DSTDC_HEADERS=1 -I. -I. -I.. -I.. -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/include/orbit-1.0 -O2 -march=i386 -mcpu=i686 -Wp,-MD,.deps/orbitcpp_poa.pp -c orbitcpp_poa.cc  -fPIC -DPIC -o .libs/orbitcpp_poa.lo
In file included from orbitcpp_poa.cc:30:
../orb/orbitcpp_poa.hh:48: template-id `operator new<>' for `::_orbitcpp::::_orbitcpp::UnboundedSequenceTmpl<unsigned char,PortableServer_sequence_octet>::operator new<>(size_t)' does not match any template declaration
../orb/orbitcpp_poa.hh:48: confused by earlier errors, bailing out
make: *** [orbitcpp_poa.lo] Error 1

Debugging template problems is like divining stock prices from cloud
formations, in my experience. 

b.c.

Re: [orbitcpp-list] build issues

[Sam C. <sc...@bi...>]

Brian Craft <bc...@th...> wrote:
> I'm having a number of problems with the build. I'm building from cvs, si=
nce it
> has a spec file.
>=20
> o Generating autoconf/automake/libtool files. Is there a doc anywhere on
>   this? They don't seem to be decending into the compiler directory
>   correctly, and so I end up having to manually run half a dozen commands
>   to get the build off the ground.
>=20
> o After running all the above, "make dist" fails to work because standard
>   files (like AUTHORS) are missing in the compiler directory, as well as=
=20
>   CosNaming-cpp-common.hh, and perhaps others. Seems to be the same probl=
em
>   as above.

There is a script provided, called "autogen.sh", which will run
automake, autoconf and friends correctly. This should solve both of the
above problems.

> o The changelog in the .spec file is broken such that rpm refuses to atte=
mpt a
>   build.

I've forgotten most of what I used to know about RPM, so I can't help
you with this. Braden may be able to provide more help, since he's
worked on the .spec file in the past.

You could just nuke the changelog to get it to build.

> o There's an unchecked (by configure or rpm) dependency on <sstream>, whi=
ch=20
>   appears to be supported only by recent gcc. I think this is supposed to
>   be handled by checking HAVE_STD_IOSTREAM and typedef'ing ostrstream to
>   ostringstream.

The stringstream is only used in one place, to convert an integer into a
string, so the dependency could be removed with very little trouble.

> o The template partial specialization in orbitcpp_sequence.hh also seems =
to
>   only work with recent gcc, though older versions reportedly support par=
tial
>   specialization. I'm not sure what the problem is.

I've been building with GCC 2.95 and 3.0, which both work fine. GCC has
historically had many many problems with templates.

However, templates are a C++ black art that I don't fully understand,
and I don't even know what partial specialization is, so I can't help
with this either. Are you unable to use a recent GCC for some reason?
--=20
Sam "Eddie" Couter  |  mailto:sc...@bi...
Debian Developer    |  mailto:ed...@de...
                    |  jabber:sa...@ja...
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

[orbitcpp-list] build issues

[Brian C. <bc...@th...>]

I'm having a number of problems with the build. I'm building from cvs, since it
has a spec file.

o Generating autoconf/automake/libtool files. Is there a doc anywhere on
  this? They don't seem to be decending into the compiler directory
  correctly, and so I end up having to manually run half a dozen commands
  to get the build off the ground.

o After running all the above, "make dist" fails to work because standard
  files (like AUTHORS) are missing in the compiler directory, as well as 
  CosNaming-cpp-common.hh, and perhaps others. Seems to be the same problem
  as above.

o The changelog in the .spec file is broken such that rpm refuses to attempt a
  build.

o There's an unchecked (by configure or rpm) dependency on <sstream>, which 
  appears to be supported only by recent gcc. I think this is supposed to
  be handled by checking HAVE_STD_IOSTREAM and typedef'ing ostrstream to
  ostringstream.

o The template partial specialization in orbitcpp_sequence.hh also seems to
  only work with recent gcc, though older versions reportedly support partial
  specialization. I'm not sure what the problem is.

b.c.

Re: [orbitcpp-list] Re: cpp branch: CORBA_Object struct hidden?

[Michael M. <mi...@xi...>]

Hi Richard,

	Having claimed I knew what I was talking about - it seems I'm a totally
wally; so ...

On Thu, 2002-02-21 at 22:37, Richard Andrews wrote:
> CORBA::XXX_ptr 
> CORBA::XXX_ptr::narrow( const CORBA::Object_ptr & rhs )

	You can override a narrow operation such that it equates to a method
invocation ? and the compiler will chain multiple narrows if you narrow
(A -> B -> C) C to A ? fascinating.

	That would indeed localize the internal CORBA_Object, but could a
similar effect not be achieved by having an overrided assignment to
CORBA_Object from Foo:C++Object ? - [ this would be nice also since we
need to do a load of casts to / from CORBA_Typecodes  etc. ].

	So; hmm ... we could then swing this as long as no C++ method that used
data on the inherited instance was inline on the Foo:C++Object. Clearly
this might well have some performance implications, so I think it's best
to go with a non-inherited wrapper - as before ;-)

	Regards,

		Michael.

-- 
 mm...@gn...  <><, Pseudo Engineer, itinerant idiot

Re: [orbitcpp-list] packages, etc.

[Sam C. <sc...@bi...>]

Brian Craft <bc...@th...> wrote:
> Requiring my users to compile support libraries isn't an option. Near as =
I can
> tell there are no vendors that ship orbitcpp. Guess I'll use C wrappers.=
=20

Debian includes orbitcpp in the unstable and testing distributions, and
it will most likely be included in the release of woody (due Real Soon
Now).

Actually, I have to get it building under GCC 3.0 for it to be included
in woody, so that might not happen.

I don't know of any other distributions which include it though.
--=20
Sam "Eddie" Couter  |  mailto:sc...@bi...
Debian Developer    |  mailto:ed...@de...
                    |  jabber:sa...@ja...
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C