MSVC++-problem

[Bonita Montero]

I've got a problem with MSVC++.

The following code doesn't compile:

struct X
{
struct B;

struct A
{
int dummy;
operator B();
};

struct B
{
int dummy;
};
};

X::A::operator B()
{
B b;
return b.dummy = dummy, b;
}


If I write ...

X::A::operator X::B()

... the code does compile!


And if I have a template-version:

template<typename T>
struct X
{
struct B;

struct A
{
T dummy;
operator B();
};

struct B
{
T dummy;
};
};

template<typename T>
X<T>::A::operator X<T>::B()
{
B b;
return b.dummy = dummy, b;
}

... the code doesn't even compile with the prefix "X<T>::"


But if i prefix "X<T>::" with typename ...

template<typename T>
X<T>::A::operator typename X<T>::B()

... the code does compile!


As my Linux-pc has a malfunctional graphics-card, I can't verify which
code does compile with gcc and clang. And this wouldn't even tell me
which variants are conforming and which are non-conforming.

[Öö Tiib]

On Sunday, 24 December 2017 20:05:00 UTC+2, Bonita Montero wrote:
> I've got a problem with MSVC++.
>
> The following code doesn't compile:
>
> struct X
> {
> struct B;
>
> struct A
> {
> int dummy;
> operator B();
> };
>
> struct B
> {
> int dummy;
> };
> };
>
> X::A::operator B()
> {
> B b;
> return b.dummy = dummy, b;
> }
>
>
> If I write ...
>
> X::A::operator X::B()
>
> ... the code does compile!

I am strongly convinced that both should compile.

>
>
> And if I have a template-version:
>
> template<typename T>
> struct X
> {
> struct B;
>
> struct A
> {
> T dummy;
> operator B();
> };
>
> struct B
> {
> T dummy;
> };
> };
>
> template<typename T>
> X<T>::A::operator X<T>::B()
> {
> B b;
> return b.dummy = dummy, b;
> }
>
> ... the code doesn't even compile with the prefix "X<T>::"
>
>
> But if i prefix "X<T>::" with typename ...
>
> template<typename T>
> X<T>::A::operator typename X<T>::B()
>
> ... the code does compile!
>
>
> As my Linux-pc has a malfunctional graphics-card, I can't verify which
> code does compile with gcc and clang. And this wouldn't even tell me
> which variants are conforming and which are non-conforming.

Here I trust that even ...

template<typename T> X<T>::A::operator B() {/* and what was in it */}

... should compile. Pehaps MSVC has somehow different understanding of
implicit qualification and dependent names. Or may be it is again that
c++/cli (that they made and that no one uses) blowing up otherwise.

[Bonita Montero]

>> If I write ...
>>
>> X::A::operator X::B()
>>
>> ... the code does compile!

> I am strongly convinced that both should compile.

I found some online-compilers for clang and gcc, and
both accept the simplified version ("X::A::operator B()").

> Here I trust that even ...
> template<typename T> X<T>::A::operator B() {/* and what was in it */}
> ... should compile. Pehaps MSVC has somehow different understanding of
> implicit qualification and dependent names. Or may be it is again that
> c++/cli (that they made and that no one uses) blowing up otherwise.

Right, both online-compilers for gcc and clang accepted this version.

[James Kuyper]

On 12/24/2017 01:04 PM, Bonita Montero wrote:
> I've got a problem with MSVC++.
>
> The following code doesn't compile:

Saying that something doesn't compile is nearly useless - you should
provide the full text of the error message(s) produced by the compiler,
so that we can better understand what it was your compiler objects to.

[Bonita Montero]

> Saying that something doesn't compile is nearly useless - you
> should provide the full text of the error message(s) produced
> by the compiler, so that we can better understand what it was
> your compiler objects to.

I don't want to discuss why my compiler acceppts variation a and not
variation b. My first tquestion was which variation is acceptet by
gcc and clang. And the second question is which of those variations
is standard-conformant. Therefore your objection isn't necessary.

[jacobnavia]

Le 24/12/2017 à 21:17, Öö Tiib a écrit :
> As my Linux-pc has a malfunctional graphics-card, I can't verify which
> code does compile with gcc and clang.

You can have a linux screen in a mac using vnc. Of course it runs on
linux too, so if your linux machine is connected to the network, it
should work.

I have only one screen. I connect 4 machines, (a mac, a PC, and two
small machines running on ARM/Debian) and it looks amazing to me.

No games, of course. I just ned a ssh text interface for work. I still
use vi (eclipse is too huge to try to move it to those small CPUs).
Maybe I should write a debugger for that machine, usable through the
network in some phone. A phone debugger :-)

Allo?

What?

It crashed again?. Where?

Gosh that dammed class!

Just restart it. Maybe we get new data that avoids that bug.

:-)

[James R. Kuyper]

Your code looks fine to me, but I'm far more reliable when I say "I see
a problem" than when I say "I see no problems".

It compiles without a problem when I use gcc with my preferred set of
options: -std=c++98 -pedantic -Wall -Wpointer-arith -Wcast-align
-ffor-scope -fno-gnu-keywords -fno-nonansi-builtins -Wctor-dtor-privacy
-Wnon-virtual-dtor -Wold-style-cast -Woverloaded-virtual -Wsign-promo.

I don't have sufficient interest in this issue to justify testing with
other combinations of options.
I don't have a copy of clang installed, so I can't test that.

However, it's entirely possible that gcc has missed out on a subtle
issue that MSVC++ is handling correctly. gcc is open source, widely
used, and has been reviewed by a wide variety of developers. It's
correspondingly well tested, but it's not perfect. MSVC++ was developed
by a company with a reputation for poor quality control and a disrespect
for standards, but it's not always wrong when it disagrees with gcc.

If MSVC++ does happen to be right in this case, the error message it
produces might provide a clue what that issue might be. If you're not
interested in finding out whether or not that's the case, feel free to
remain silent about what the error message says.

[David Brown]

On 26/12/17 22:33, jacobnavia wrote:
> Le 24/12/2017 à 21:17, Öö Tiib a écrit :
>> As my Linux-pc has a malfunctional graphics-card, I can't verify which
>> code does compile with gcc and clang.
>
> You can have a linux screen in a mac using vnc. Of course it runs on
> linux too, so if your linux machine is connected to the network, it
> should work.

vnc works as viewer and server on any "big" system (Linux, Mac, Windows,
BSD, etc.). I find it particularly useful to access Windows systems
remotely, because they don't normally have sshd and you often need a gui
for them.

But if you are using ssh and text mode editors like vi, why bother with
vnc? It is a lot more efficient to use ssh directly to the Linux
machines than to go via VNC. (Of course, I may be misunderstanding your
setup.)

>
> I have only one screen. I connect 4 machines, (a mac, a PC, and two
> small machines running on ARM/Debian) and it looks amazing to me.

If you have the desk space, multiple screens are worth the investment -
you can never have too many (nor too many pixels or inches).

>
> No games, of course. I just ned a ssh text interface for work. I still
> use vi (eclipse is too huge to try to move it to those small CPUs).

You can happily use eclipse on your Mac to work with files on your ARM
boards. A common setup would be to have eclipse on your "host" system
(a relatively big and fast Mac or Linux PC, or Windows if you are
willing to work much harder on the setup), and have a cross-compiler on
it. You do all your development - editing, compiling, debugging,
documentation - on that machine. Export the filesystem as NFS and mount
it on the ARM boards remotely. Then via ssh to the ARM boards, you can
run the program as though it were local to the machine. Debugging is
done with remote gdb - your host machine has the debugger gui, while the
code runs on the ARM board. It can take a little effort (and guides on
the internet) to get it all set up, but it is a lot more efficient to
work with than to do the editing and compiling on the small ARM board.