Re: [gcmd-dev] Migration to C++

[Michael]

Magnus,

> gcc version 3.4.4

Would it be affordable to try another version ?
Apparently i work with gcc version 4.1.2. which provides libstdc++6.
There may be C++ features in 3.4 which changed in 4.x. Maybe x64 related, too.

btw, I don't really understand what it's about but maybe this is interesting to 
Piotr:

(README.bugs from the Debian gcc package)


C++ exceptions don't work with C libraries
------------------------------------------

[Taken from the closed bug report #22769] C++ exceptions don't work
with C libraries, if the C code wasn't designed to be thrown through.
A solution could be to translate all C libraries with -fexceptions.
Mostly trying to throw an exception in a callback function (qsort,
Tcl command callbacks, etc ...). Example:

    #include <stdio.h>
    #include <tcl.h>

    class A {};

    static
    int SortCondition(void const*, void const*)
    {
        printf("throwing 'sortcondition' exception\n");
        throw A();
    }

    int main(int argc, char *argv[])
    {
        int list[2];

        try {
            SortCondition(NULL,NULL);
        } catch (A) {
            printf("caught test-sortcondition exception\n");
        }
        try {
            qsort(&list, sizeof(list)/sizeof(list[0]),sizeof(list[0]),
                 &SortCondition);
        } catch (A) {
            printf("caught real-sortcondition exception\n");
        }
        return 0;
}

Andrew Macleod <address@hidden> responded:

When compiled with the table driven exception handling, exception can only
be thrown through functions which have been compiled with the table driven EH.
If a function isn't compiled that way, then we do not have the frame
unwinding information required to restore the registers when unwinding.

I believe the setjmp/longjmp mechanism will throw through things like this, 
but its produces much messier code.  (-fsjlj-exceptions)

The C compiler does support exceptions, you just have to turn them on
with -fexceptions.

Your main options are to:
  a) Don't use callbacks, or at least don't throw through them.
  b) Get the source and compile the library with -fexceptions (You have to
     explicitly turn on exceptions in the C compiler)
  c) always use -fsjlj-exceptions (boo, bad choice :-)


g++: "undefined reference" to static const array in class
---------------------------------------------------------

The following code compiles under GNU C++ 2.7.2 with correct results,
but produces the same linker error with GNU C++ 2.95.2.
Alexandre Oliva <address@hidden> responded:

All of them are correct.  A static data member *must* be defined
outside the class body even if it is initialized within the class
body, but no diagnostic is required if the definition is missing.  It
turns out that some releases do emit references to the missing symbol,
while others optimize it away.

#include <iostream>

class Test
{
  public:
    Test(const char *q);
  protected:
    static const unsigned char  Jam_signature[4]   = "JAM";
};

Test::Test(const char *q)
{
  if (memcmp(q, Jam_signature, sizeof(Jam_signature)) != 0)
  cerr << "Hello world!\n";
}

int main(void)
{
  Test::Test("JAM");
  return 0;
}

g++: g++ causes passing non const ptr to ptr to a func with const arg
     to cause an error (not a bug)
---------------------------------------------------------------------

Example:

#include <stdio.h>
void test(const char **b){
        printf ("%s\n",*b);
}
int main(void){
        char *test1="aoeu";
        test(&test1);
}

make const
g++     const.cc   -o const
const.cc: In function `int main()':
const.cc:7: passing `char **' as argument 1 of `test(const char **)' adds 
cv-quals without intervening `const'
make: *** [const] Error 1

Answer from "Martin v. Loewis" <address@hidden>:

> ok... maybe I missed something.. I haven't really kept up with the latest in
> C++ news.  But I've never heard anything even remotly close to passing a non
> const var into a const arg being an error before.

Thanks for your bug report. This is a not a bug in the compiler, but
in your code. The standard, in 4.4/4, puts it that way

# A conversion can add cv-qualifiers at levels other than the first in
# multi-level pointers, subject to the following rules:
# Two pointer types T1 and T2 are similar if there exists a type T and
# integer n > 0 such that:
#   T1 is cv(1,0) pointer to cv(1,1) pointer to ... cv(1,n-1)
#   pointer to cv(1,n) T
# and
#   T2 is cv(2,0) pointer to cv(2,1) pointer to ... cv(2,n-1)
#   pointer to cv(2,n) T
# where each cv(i,j) is const, volatile, const volatile, or
# nothing. The n-tuple of cv-qualifiers after the first in a pointer
# type, e.g., cv(1,1) , cv(1,2) , ... , cv(1,n) in the pointer type
# T1, is called the cv-qualification signature of the pointer type. An
# expression of type T1 can be converted to type T2 if and only if the
# following conditions are satisfied:
#  - the pointer types are similar.
#  - for every j > 0, if const is in cv(1,j) then const is in cv(2,j) ,
#    and similarly for volatile.
#  - if the cv(1,j) and cv(2,j) are different, then const is in every
#    cv(2,k) for 0 < k < j.

It is the last rule that your code violates. The standard gives then
the following example as a rationale:

# [Note: if a program could assign a pointer of type T** to a pointer
# of type const T** (that is, if line //1 below was allowed), a
# program could inadvertently modify a const object (as it is done on
# line //2). For example,
# int main() { 
#   const char c = 'c'; 
#   char* pc; 
#   const char** pcc = &pc; //1: not allowed 
#   *pcc = &c; 
#   *pc = 'C'; //2: modifies a const object 
# }
# - end note]

If you question this line of reasoning, please discuss it in one of
the public C++ fora first, eg. comp.lang.c++.moderated, or
comp.std.c++.


 m°