Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Problems with parser


We do plan to open the parser up to further dialects of C++.  
Unfortunately, we aren't entirely there just yet, and our first attempt to do so impacted performance somewhat.  

Some of the more particularly gruesome extensions can be skipped over by adding preprocessor defines to your properties that basically nullify them.  

That being said, we need to provide the full solution:
  - Managed Build toolchain
  - Scanner Discovery Mechanism
  - Source code parser dialect support.

As of today, for non-GCC projects, I'd encourage keeping the problem markers/syntax error squiggles off.  

Thanks
JohnC
www.eclipse.org/cdt


cdt-dev-admin@xxxxxxxxxxx wrote on 08/26/2004 03:04:02 PM:

> BTW., how can one extend the parser for dialects like the Keil/Tasking/...
> with code like
>
> void _interrupt(0x0A) vi_inthandler(void)
> {
> }
>
> or stuff like
>
> char xdata myvar;
> ulong data[] _at(0x40000000);
>
> Right now, all parsing is based on C/GCC dialect and above will almost all
> of your code mark yellow or red, as its unknown. Ok, I could disable all the
> indexer stuff.
>
> Also, I'd like to see some kind of extension point on the editor/ui stuff.
> I think about something like using the indexer to provide a table of
> typedef's, though editor could pick it up. Or some other dialect, or...
>
>
> > Hello Philip,
> >
> > Bugs can be reported @ http://bugs.eclipse.org w/Product = CDT,
> > Component=CDT-parser.
> > For CDT source code parser development/usage questions, we generally use
> > the cdt-core-dev list.
> >
> > Regarding templates: Andrew estimates that our current implementation
> > handles ~ 60% of the ISO Spec.
> > Bugs are not unexpected.  :-)
> >
> > Thanks,
> > JohnC
> > www.eclipse.org/cdt
> >
> > cdt-dev-admin@xxxxxxxxxxx wrote on 08/23/2004 04:31:40 PM:
> >
> > > Hi,
> > >
> > > I do hope that this is the right mailing list to report bugs / ask for
> > help.
> > >
> > > I'm using eclipse 3.0 and cdt 2.0.
> > >
> > > I get a lot of parsing errors in my project (using a standard make
> > > project out of an existing project).
> > >
> > >
> > > For instance in the following snippet (at the end of mail) will cause
> > > problems.
> > >
> > > It looks like although the parser could determine which specialisation
> > > of my template is used it will always use the default one, which in my
> > > case will lead to the problem that _all_ of my types are unkown to cdt.
> > >
> > > Aw, after fixing that I've found another nasty problem with templates:
> > >
> > >
> > > I've got a template class with a template parameter which specifies it's
> >
> > > subclass. In this case the methods inherited from this subclass are not
> > > visible to cdt and I get parsing errors whereever I use them.
> > >
> > > At least thats what I think is happening, is there an easy way to get
> > > more detailed output on what causes parse errors?
> > >
> > > My Code is perfectly legal (compiles on a lot of platforms), so I dont
> > > think that the problems are due to coding errors.
> > >
> > > And, both visual studio .net 2003 and visual assist x parse the source
> > > correctly and provide me with (more or less) usefull code completion.
> > >
> > > with kind regards Philip
> > >
> > >
> > > -------8<-----------------
> > >
> > > namespace XYZ_
> > > {
> > >
> > >     enum
> > >     {
> > >        OS_TYPE_UNKOWN=0,
> > >        OS_TYPE_WINDOWS,
> > >        OS_TYPE_LINUX,
> > >        OS_TYPE_UNIX
> > >     };
> > >
> > >     template <int os_type>
> > >     struct FF_BaseTypes
> > >     {
> > >     };
> > >
> > > #ifdef OS_WINDOWS
> > >     int const OS_TYPE = OS_TYPE_WINDOWS;
> > > #endif
> > > #ifdef OS_LINUX
> > >     int const OS_TYPE = OS_TYPE_LINUX;
> > > #endif
> > > }
> > >
> > > #ifdef OS_WINDOWS
> > > #include "FF_BaseTypesWindows.h"
> > > #endif
> > > #ifdef OS_LINUX
> > > #include "FF_BaseTypesLinux.h"
> > > #endif
> > >
> > > namespace XYZ_
> > > {
> > >     typedef FF_BaseTypes<OS_TYPE>::FF_Int32 FF_Int32;
> > >     typedef FF_BaseTypes<OS_TYPE>::FF_Uint32 FF_Uint32;
> > > }
> > >
> > > In FF_BaseTypesLinux.h I just have a specialistation of the FF_BaseTypes
> >
> > > template providing the types i then use in my Namespace
> > > ------8<-------------------
> > >
> > >
> > > _______________________________________________
> > > cdt-dev mailing list
> > > cdt-dev@xxxxxxxxxxx
> > > http://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
>
> --
> NEU: Bis zu 10 GB Speicher für e-mails & Dateien!
> 1 GB bereits bei GMX FreeMail http://www.gmx.net/de/go/mail
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top