request for help understanding a traceback

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

request for help understanding a traceback

R P Herrold

I see the following from a run report attachment
( full run report on another matter at:
  http://llvm.org/bugs/show_bug.cgi?id=6344 )

[ side matter: ... I am not so sure about the 'deprecated'
asserted -- standard reference so stating please?  but thanks
for the fix ;) ]


/usr/bin/clang++ -Wall     -g -I/usr/include/mysql
  -I/usr/include/c++/4.1.1/ -I/
  usr/include/c++/4.1.1/x86_64-redhat-linux  -c -o obj/bind.o
  src/bind.c
clang: warning: treating 'c' input as 'c++' when in C++ mode,
  this behavior is deprecated
In file included from src/main.c:8:
In file included from src/main-h.h:11:
In file included from src/glossary.h:18:
In file included from src/../lib/glossary.h:46:
src/../lib/exceptions.h:23:1: warning: struct  'out_of_range'
  was previously declared as a class  [-Wmismatched-tags]
struct out_of_range {
^~~~~~
class
In file included from src/main.c:8:
In file included from src/main-h.h:11:
In file included from src/glossary.h:18:
In file included from src/../lib/glossary.h:32:
src/../lib/type_names.h:19:47: note: previous use is here
                                         class out_of_range;
                                               ^

============================

I had understood these to be in separate namespaces, and no
not 'previously used'

[herrold@centos-5 shim-100205-clang]$ for i in \
  src/../lib/exceptions.h  src/../lib/type_names.h   ; do
  echo ; echo $i ; echo "------------------" ;
  grep -C 4 out_of_range $i ;
done


src/../lib/exceptions.h
------------------

namespace MinimalModeMultiParadigm {

#define OOR(Obj, Str)                                                   \
struct Obj : public out_of_range {                                      \
        Obj(int i) : out_of_range(i, Str) {}                             \
}

struct out_of_range {
        out_of_range(int i, char_0 s) : idx(i), msg(s) {}

        int    idx;
        char_0 msg;
};

OOR(nil_pointer_intern    , "refusing to intern non-string (null ptr)");
OOR(index_out_of_range    , "array index out of range");
OOR(invalid_graph_node    , "graph vertex is out of range");
OOR(matrix_indices_oor    , "matrix indices are invalid");
OOR(id_out_of_sequence    , "the sequence number is offset or out of order");
OOR(not_input_type_tag    , "input terminal token type is output/err");

src/../lib/type_names.h
------------------

namespace MinimalModeMultiParadigm {
                                         class Components;
                                         class MmmConstants;
                                         class out_of_range;
namespace SimpleEfficientAllocator {    class Memory;
                                         class MemConstants;
                                 typedef class MemConstants MemConst;
                                         class BootMemory;
[herrold@centos-5 shim-100205-clang]$

What am I not understanding?

-- Russ herrold
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: request for help understanding a traceback

Christopher Jefferson

On 18 Feb 2010, at 15:06, R P Herrold wrote:

>
> I see the following from a run report attachment
> ( full run report on another matter at:
> http://llvm.org/bugs/show_bug.cgi?id=6344 )
>
> [ side matter: ... I am not so sure about the 'deprecated'
> asserted -- standard reference so stating please?  but thanks
> for the fix ;) ]
>
>
> /usr/bin/clang++ -Wall     -g -I/usr/include/mysql
> -I/usr/include/c++/4.1.1/ -I/
> usr/include/c++/4.1.1/x86_64-redhat-linux  -c -o obj/bind.o
> src/bind.c
> clang: warning: treating 'c' input as 'c++' when in C++ mode,
> this behavior is deprecated
> In file included from src/main.c:8:
> In file included from src/main-h.h:11:
> In file included from src/glossary.h:18:
> In file included from src/../lib/glossary.h:46:
> src/../lib/exceptions.h:23:1: warning: struct  'out_of_range'
> was previously declared as a class  [-Wmismatched-tags]
> struct out_of_range {
> ^~~~~~
> class
> In file included from src/main.c:8:
> In file included from src/main-h.h:11:
> In file included from src/glossary.h:18:
> In file included from src/../lib/glossary.h:32:
> src/../lib/type_names.h:19:47: note: previous use is here
>                                         class out_of_range;
>                                               ^

The problem is that you should consistently either call a type a struct, or a class.

You write:
>
>
> namespace MinimalModeMultiParadigm {
>
> ...
>
> struct out_of_range {
...
>    
> src/../lib/type_names.h
> ------------------
>
> namespace MinimalModeMultiParadigm {
...
>
>                                         class out_of_range;
...

Notice how MinimalModeMultiParadigm::out_of_range is defined as a class in one place, and a struct in the other. While these two are basically equivalent in C++, you are being warned that you are being inconsistent. Change either both to a struct, or both to a class. It is probably easier to change the one in type_names.h, as changing the other will effect members in the object.

Does that help?

Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

request for help understanding a traceback

R P Herrold
On Thu, 18 Feb 2010, Christopher Jefferson wrote:

> Notice how MinimalModeMultiParadigm::out_of_range is defined
> as a class in one place, and a struct in the other. While
> these two are basically equivalent in C++, you are being
> warned that you are being inconsistent. Change either both
> to a struct, or both to a class. It is probably easier to
> change the one in type_names.h, as changing the other will
> effect members in the object.
>
> Does that help?

Thank you for the 'fast track' explanation from your trained
eyes  ;)  It permitted me to 'see' into the (what I take to be
a) warning more easily;  I read a bit more at
  http://en.wikipedia.org/wiki/C%2B%2B_classes
and think I see how this divergence crept in our code as it
has been re-worked over time

Commits into this part of the code are not wholly mine, and
we'll discuss approaches at the next code review, I am sure --
I take the matter to be 'lint' and pedantic (in the good
sense) review of a artifact of how the code evolved being
surfaced by 'clang' so that we might address it uniformly

Thank you, again

-- Russ herrold
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev