Whole Tomato Software Forums

Whole Tomato Software Forums

All Forums

Visual Assist

Technical Support

Bug: Weird placement of throw() confuses parser

You must be registered to post a reply.
Click here to register.

Screensize:

UserName:

Password:

Format:

Message:

Forum code is on.
Html is off.

[quote][i]Originally posted by bressler[/i]
[br][b]Versions[/b]
VA Assist X 10.2.1437.0
Visual Studio 2005 Team Ed for S/W Archs, us-en, 8.0.50727.42

[b]Summary[/b]
This is easy to repro. If you define a constructor but put a throw() [i]before[/i] the initializer list, it freaks out the parser such that a) all the initializer lines to show up with red underlines, and b) the in the function menu, the constructor will occur as many times as there are initializers. And yes, this placement of throw() [i]does[/i] compile; whether or not it's legal ANSI C++ I don't know.

[b]Example[/b]
[code]MyClass::MyClass() throw()
  : [red][u]m_member1[/u][/red](0),
    [red][u]m_member2[/u][/red](L"wow"),
    [red][u]m_member3[/u][/red](1.0f)
{
}[/code]
The above definition compiles fine. But in the text editor, the three m_member* lines are all red-underlined (which I've artfully tried to demostrate within the confines of Forum Code above). In the function menu, MyClass.MyClass() shows up three times. If you add more initializer lines, you'll get more copies of your constructor.

If you simply move the throw() like this:
[code]MyClass::MyClass()
  : m_member1(0),
    m_member2(L"wow"),
    m_member3(1.0f) throw()
{
}[/code]

The bug goes away. If it compiles, I'd argue the VAX parser should handle it right. Let me know if you need any clarification.

Thanks and keep up the great work.

-Bryan
VA users since VS6

--------------------
VA_X.dll file version 10.2.1437.0  built 2005.12.10
Licensed to:
  VA X: bressler@pallium.com (1-user license) Support ends 2006.06.27
  VA.NET 7.1: bressler@pallium.com (1-user license)
VAOpsWin.dll version 1.3.3.0
VATE.dll version 1.0.4.2
DevEnv.exe version 8.0.50727.42
msenv.dll version 8.0.50727.42
Font: ProFontWindows 11(Pixels)
Comctl32.dll version 6.0.2900.2180
WindowsNT 5.1 Build 2600 Service Pack 2
4 processors

Platform: Win32

Microsoft Visual Studio 2005
Version 8.0.50727.42  (RTM.050727-4200)
Microsoft .NET Framework
Version 2.0.50727

Installed Edition: Enterprise Architect

Microsoft Visual C# 2005   77637-163-9000005-41450
Microsoft Visual C# 2005

Microsoft Visual C++ 2005   77637-163-9000005-41450
Microsoft Visual C++ 2005

Microsoft Visual Studio Tools for Office   77637-163-9000005-41450
Microsoft Visual Studio Tools for the Microsoft Office System

Visual Studio 2005 Team Edition for Architects   77637-163-9000005-41450
Microsoft Visual Studio 2005 Team Edition for Software Architects

DirectX extensions for Visual Studio   
DirectX extensions for Visual Studio .NET

Visual Assist X   
For more information about Visual Assist, see the Whole Tomato Software website at http://www.WholeTomato.com. For customer support, email Support@WholeTomato.com. Copyright (c) 1997-2004 Whole Tomato Software,  Inc.

[/quote]

Check to include your profile signature.
Check to subscribe to this topic.

T O P I C R E V I E W
bressler	Posted - Dec 19 2005 : 8:50:23 PM Versions VA Assist X 10.2.1437.0 Visual Studio 2005 Team Ed for S/W Archs, us-en, 8.0.50727.42 Summary This is easy to repro. If you define a constructor but put a throw() before the initializer list, it freaks out the parser such that a) all the initializer lines to show up with red underlines, and b) the in the function menu, the constructor will occur as many times as there are initializers. And yes, this placement of throw() does compile; whether or not it's legal ANSI C++ I don't know. Example MyClass::MyClass() throw() : m_member1(0), m_member2(L"wow"), m_member3(1.0f) { } The above definition compiles fine. But in the text editor, the three m_member* lines are all red-underlined (which I've artfully tried to demostrate within the confines of Forum Code above). In the function menu, MyClass.MyClass() shows up three times. If you add more initializer lines, you'll get more copies of your constructor. If you simply move the throw() like this: MyClass::MyClass() : m_member1(0), m_member2(L"wow"), m_member3(1.0f) throw() { } The bug goes away. If it compiles, I'd argue the VAX parser should handle it right. Let me know if you need any clarification. Thanks and keep up the great work. -Bryan VA users since VS6 -------------------- VA_X.dll file version 10.2.1437.0 built 2005.12.10 Licensed to: VA X: [email protected] (1-user license) Support ends 2006.06.27 VA.NET 7.1: [email protected] (1-user license) VAOpsWin.dll version 1.3.3.0 VATE.dll version 1.0.4.2 DevEnv.exe version 8.0.50727.42 msenv.dll version 8.0.50727.42 Font: ProFontWindows 11(Pixels) Comctl32.dll version 6.0.2900.2180 WindowsNT 5.1 Build 2600 Service Pack 2 4 processors Platform: Win32 Microsoft Visual Studio 2005 Version 8.0.50727.42 (RTM.050727-4200) Microsoft .NET Framework Version 2.0.50727 Installed Edition: Enterprise Architect Microsoft Visual C# 2005 77637-163-9000005-41450 Microsoft Visual C# 2005 Microsoft Visual C++ 2005 77637-163-9000005-41450 Microsoft Visual C++ 2005 Microsoft Visual Studio Tools for Office 77637-163-9000005-41450 Microsoft Visual Studio Tools for the Microsoft Office System Visual Studio 2005 Team Edition for Architects 77637-163-9000005-41450 Microsoft Visual Studio 2005 Team Edition for Software Architects DirectX extensions for Visual Studio DirectX extensions for Visual Studio .NET Visual Assist X For more information about Visual Assist, see the Whole Tomato Software website at http://www.WholeTomato.com. For customer support, email [email protected]. Copyright (c) 1997-2004 Whole Tomato Software, Inc.
3 L A T E S T R E P L I E S (Newest First)
bressler	Posted - Dec 20 2005 : 4:53:06 PM Wait a minute, you're right. If you put the throw() at the end (after the last initializer) VS 2005 won't compile either. You get Error C2612: trailing 'throw' illegal in base/member initializer list So the way that compiles is the way that causes the bug to happen in VS 2005 too. Thanks for assigning the bug. Have a great holiday, Bryan
feline	Posted - Dec 20 2005 : 4:09:29 PM case=939
feline	Posted - Dec 20 2005 : 4:09:12 PM thank you for a nice clear bug report our general policy is that VA should not make the user change their coding habits, so given this compiles VA should accept it. as a test i tried moving the throw to the end of the member variable list, and in VS2003 this refuses to compile, due to an invalid position of the throw() statement. i am not sure if VS2003 is behaving properly in this regard, but this certainly lends weight to your cause

Snitz Forums 2000