[Bug c++/13484] Addition of -fenable-msvc-relaxations option

["gdr at integrable-solutions dot net" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From gdr at integrable-solutions dot net  2003-12-24 19:55 -------
Subject: Re:  Addition of -fenable-msvc-relaxations option

"s_gccbugzilla at nedprod dot com" <gcc-bugzilla@gcc.gnu.org> writes:


| Firstly to answer pinskia's point, from my understanding const
| temporaries are not specified absolutely by the ISO C++ standard -
| it appears to be one of interpretation (I don't have an up to date
| copy myself to check though).

I don't understand that.  What do you mean by cont temporaries?

The standard is specifically crystal-clear that an rvalue (which a
temporary is) cannot be bound to a non-const reference.  If you happen
to get a temporary whose type is const-qualified, then there is even
more reason not to bind it to non-const reference.

[...]

| class dllHandle
| {
|    dllHandle(); // private constructor as dllOpen() is a friend
| public:
|    dllHandle(dllHandle &other); // move constructor
| };
| 
| static dllHandle FXProcess::dllOpen(const char *dllname);
| static void FXProcess::dllResolve(const dllHandle &h, const char *symbol);
| static void FXProcess::dllFree(dllHandle &h);
| 
| Here we have an ideal case of why move constructors are so
| useful.

None of the above uses the "move semantic" proposal syntax.  And even more,
while the problems identified in the move semantics proposal are real,
many people do feel that it is a lot of complication of the C++
already complex type system.

In the above specific example, you can use standard syntax and acheive
the same goal.

| Yes, the ISO C++ standard will get them eventually. 

How can you be so sure?  At the last two meetings I've attended, they 
were not subject of work -- I'm not saying they were dismissed,
but I find your assertion too definitive, which is why I'm asking.

| Now try porting that to GCC. Answer is you can't unless you make the
| contents of dllHandle all mutable which defeats the point of const.

Trying to port deliberately wrong written, invalid codes to another
compiler is a dubious task.  Asking GCC to support it, is even more
dubious, IMNSHO.

| As I said before, for such a small *optional* addition to GCC you greatly 

If it is optional, then we can ignore the corresponding
implementation in GCC, right?

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13484