I'm using VS 2017 and ReSharper Ultimate 2016.3.2.
The code builds fine but in text editor I'm getting something like errors:
and
When I suspend ReSharper the errors are gone. What is the problem?
Initial support for C# 7.0 was introduced only a month ago by Resharper team, so it's basically isn't ready:
C# 7 and VB.NET 15 come with some additional language enhancements that we’re also adding support for in ReSharper but are still in early stages in our nightly builds
Right now these features are supported:
C# 7.0/VB.NET 15 binary literals and digit separators (parsing, several context actions, support for literals written in different base/separated differently)
Support for C# local functions (parsing, analyzing null)
Limited support for C# pattern-matching expressions (as the language design itself is not finished), C# output variables, C# tuples and C# deconstruction
There was a new release earlier this week, yet to support the features you're pointing to. So you should wait for a while.
Related
Groovy added the --indy option in version 2.0, back in 2012. It wasn't the default at the time because invoke dynamic required Java 7, and many people at the time used Java 6.
Now even the forthcoming Groovy 3.0 still requires the --indy option in order to force it to use invoke dynamic. That's in spite of the fact Groovy 3.0 requires Java 8 or later.
Is there any technical advantage in still having the default be non-indy compilation, and the default run-time libraries being non-indy? I would have thought there's no need to even have a non-indy option nowadays.
Having --indy by default is on the roadmap for Groovy 3.0 (currently in alpha). The team wanted feedback on the new parser so didn't wait for all features to be available before releasing alpha versions.
The Groovy 3.0 compiler will likely keep a non-indy option of some kind available for a version or two to assist people wanting to recompile old libraries and produce like-for-like bytecode.
Currently, there are some primitive handling optimisations in play when producing non-indy bytecode. Very early benchmarks (on quite old JVMs now) showed some performance regressions since the indy bytecode didn't have those same optimisations. Also on the roadmap for 3.0 is to re-look at performance in those specific cases with a view to considering possible optimisations if still needed.
Exact specifics of whether some non-indy jars will be required for a version or two depend on some other parallel changes to remove some legacy classes that aren't really needed for the indy case but which would be required for all existing libraries written in Groovy to run. That will be detailed in the documentation and release notes once finalised.
There are some more details in [1].
[1] http://groovy.markmail.org/thread/yxeflplf5sr2wfqp
We have large commercial app that we want to convert from Delphi 6 to 2010. Approx 10 3rd party component sets, all with source code... I have heard warnings about Unicode with 2010 - Does anyone have experience and or suggestions?
There are many resources available that you can read and that you will assist in the migration from Delphi 6 to Delphi 2009/2010 (Unicode).
You can use these articles as a guide.
Unicode Migration Statistics Tool (This utility will hopefully assist you in collecting useful statistics
on how hard (or not) it would be to migrate your older applications to
Unicode.)
Delphi 2009 and Unicode
Delphi 2009 strings explained by example
Upgrading a major project to Delphi 2009
Delphi and Unicode
Dr. Bob Delphi 2009 Unicode
Delphi 2009 - Unicode in Type Libraries
On Strings and Unicode in Delphi 2009
Delphi in a Unicode World Part I: What is Unicode, Why do you need it, and How do you work with it in Delphi?
Delphi in a Unicode World Part II: New RTL Features and Classes to Support Unicode
Delphi in a Unicode World Part III: Unicodifying Your Code
CodeRage 4 : Using Unicode and Other Encodings in your Programs
Bye.
You'll find some useful answers in these StackOverflow questions:
Move project from Delphi 3 to Delphi 2010
When and Why Should I Use TStringBuilder?
Convert function to delphi 2009/2010 (unicode)
Unicode problems with Delphi 2009 / 2010 and windows API calls
Also, for what it is worth, I purchased Marco Cantu's Delphi 2009 Handbook. It was all I needed to make a relatively smooth converstion from Delphi 4 to Delphi 2009 in only a few weeks.
I do, however, recommend that you ensure your 3rd party packages have a Delphi 2009 upgrade, or you may have some real difficulties. Converting your own code is one thing. Converting someone else's is another.
I use two 3rd party packages, both with source code. Both had upgrades available, and the developer of one of them wrote that he had a lot of trouble upgrading his very complex component to the Unicode of Delphi 2009. It took him a few months, but he completed it. And as a result, I had little trouble with my implementation of his component when I did my upgrade.
i've been in the same circumstance recently. you mostly need to pay attention to the "edges" of the app. INI files, file I/O, log files, etc. win API calls from delphi work since they've now connected the unicode API calls instead. check each 3rd party component set to make sure they're at least ready for Delphi 2009...better yet 2010. even my use of databases simply wasn't an issue...nearly everything worked right away. it just wasn't a big deal. anything that relies on the size of a character should be reviewed.
really the transition of most concern is 2007_or_earlier --> 2009_or_later.
there are plenty of discussions/blog entries about it. you could read, read, read...or you could get started & see what happens. (i did some of both). i'm sure there are "stack overflow" issues discussing your question. i'm not pretending to give a detailed description of what could happen.
it's simply not as scary as it sounds.
Approx 10 3rd party component sets, all with source code.
One thing I'd add is if the component doesn't support Delphi 2009/2010, don't try to upgrade it by hacking the code.
Following is what I posted on How do the new string types work in Delphi 2009/2010?:
See Delphi and Unicode, a white paper written by Marco Cantù and I guess
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!), written by Joel.
One pitfall is that the default Win32 API call has been mapped to use the W (wide string) version instead of the A (ANSI) version, for example ShellExecuteA If your code is doing tricky pointer code assuming internal layout of AnsiString, it will break. A fallback is to substitute PChar with PAnsiChar, Char with AnsiChar, string with AnsiString, and append A at the end of Win32 API call for that portion of code. After the code actually compiles and runs normally, you could refactor your code to use string (UnicodeString).
I must add this article from Carey Jensen to others mentioned. It is labeled: "Delphi Unicode Migration for Mere Mortals: Stories and Advice from the Front Lines" (in english).
http://www.danysoft.com/free/delphiunicodemigration.pdf
As you can see in the title of it, you will find many experiences and hints and tips. I think it is the answer to your question. After carefully read it, you will sure knows what to do next. :)
Found in: http://www.danysoft.com/productos/migrar-aplicaciones-a-delphi-xe-o-cbuilder-xe.html
Another point to take care of, is the usage of Variant types with strings and the VarType function testing for strings: one needs to use varUString instead of varString.
Assuming AValue is of type Variant and has being assigned a Unicode string value, the following won't work:
if VarType(AValue) = varString then ...
and needs to be changed to
if VarType(AValue) = varUString then ...
On the ANTLR download page it states that the latest version of ANTLR is 4.4. From the C# Target section on the same page, clicking "ANTLR 4 C# Target (Latest Release)" brings me to the 4.3 Target Release GitHub page that has a link for Readme.md, which when clicked, results in a 404.
Question 1: Although the download page states that the latest version for C# 4.4, the version I get via NuGet is 4.3. Does this mean 4.4 isn't available for C#?
Question 2: Where do I find the tools for code generation that correspond to the version I got from NuGet (that is, Antlr 4.3)?
We attempted using antlr-4.4-complete.jar for code generation - we substituted that jar for the previous (antlr4-csharp-4.0.1-SNAPSHOT-complete.jar) in our build script and now we get: "error(31): ANTLR cannot generate CSharp_v4_5 code as of version 4.4" (which we didn't get previously). We also tried antlr-4.3-complete.jar and got similar results.
What do we need to take advantage of the latest release?
First of all, I corrected the link to the Readme.md in the release notes. Thanks for pointing it out, although a more reliable way to notify the maintainer is to file an issue directly for the project.
Second, the C# target is not based on the version of ANTLR posted on antlr.org, but instead on a fork of the project I created to optimize performance and (especially) memory overhead associated with parsing highly complex grammars. The tools use different serialization formats and are not interchangeable.
The C# code generator is distributed via NuGet, as described in the readme file.
ANTLR 4.4's primary differences over ANTLR 4.3 are the following:
Inclusion of additional targets (irrelevant for the C# target, since the runtime libraries are not C# and also use the other serialization format)
A bug-fix in the tool that has minimal effect on users (it throws an exception instead of reporting an error at code generation time for a specific type of grammar error)
Fixes a bug that occurs when an unknown target is specified (also not applicable to the C# target, since the MSBuild integration automatically selects the correct target language)
Based on this, the 4.3 release of the C# target is functionally equivalent to 4.4. I'm waiting to release a "4.4" version until I can address other performance concerns and functionality which doesn't apply to the reference version. In particular, I'm working on the following:
Improving concurrency by reducing contention (sharwell/antlr4#13)
Supporting indirect left recursion (currently a work-in-progress in the indirect-lr and java8-grammar branches)
Supporting a new baseContext option, shown here for a Java 8 grammar
Been using VS2010 express. Writing in C# which i figured was a good middle step towards object oriented languages. One thing that has made my code somewhat repetitive is the inability to use multiple class inheritance in C#. I.e. I can't say class A inherits from class B and class C.
c# is great because you can quickly and easily get windows with buttons textboxes and dials up and running. This is not available in C++ in the express version since the MFC libraries are not included.
Now, I have thought of just desinging a C# front end which saves parameters to a file then execute a c++ which reads the file, runs and then saves a file which i open with another(or the same) c# backend exec to read and play ard with the results. But this would make it cumbersome always executing the whole sequence again if you want to change something. Not to mention debugging, will probably need to have to instances running.
Reading on of the Visual studio 2012 Express for desktop announcment, it stated that "You can also combine C++, C#, and Visual Basic projects into a single solution, making it easy to write a single application using any of the available languages." http://blogs.msdn.com/b/visualstudio/archive/2012/09/12/visual-studio-express-2012-for-windows-desktop-is-here.aspx?PageIndex=3
Now I would be happy with that, after all I dont expect and dont need at this stage to do any wizbank stuff i.e special button functionality/design which is easier and provided with the MFC in C++.
My question is: Has anyone tried this in Visual Studio 2012 in the Express for windows desktop version in Windows 7''? I.e can you combine a c++ and a c# projects which interact, trace the code form one project to another when debugging for example? Are there any special restrictions? I mean if its combining executables only its not much use, but i expect its more than that, but how much more? For example, can an object designed in C# instanciate an object designed in c++ pass it a reference to other objects like classes which hold inputs and outputs or data which are proccessed in the c++ class and still accesible in the c# code to display results etc?
I am asking this before downloading the new express version because I expect it will set me back a couple of months since going from C# to C++ i would think is like going from Visual Basic to C. I wouldnt want to get into all the trouble (i dont mind really but it would be huge step back) to find out i cant "seemlesly" integrate a c# front end with a C++ proccesing solution.
You have three options for interfacing C++ with C#:
pinvoke: You specify function signatures in C# and give them an attribute specifying what DLL they reside in. This is fairly painful to do if you need to pass around any complex types at all.
COM: A C++ DLL would implement a COM object called by the C# code.
C++/CLI: Allows mixing of managed and unmanaged C++ code in a single C++ project. It is very nice for interfacing with other libraries but, in VS 2010 at least, lacks helpful features such as intellisense. If you really wanted to go this route, I would write three projects: Your core C++ code as a static library, your C++/CLI DLL to wrap it, and your C# application.
I've been playing around with Direct3D 11 a little bit lately and have been frustrated by the lack of documentation on the basics of the API (such as simple geometry rendering). One of the points of confusion brought on by the sparse documentation is the (apparent) move away from the use of effects for shaders.
In D3D11 all of the effect (.fx) support has been removed from the D3DX libraries and buried away in a hard to find (sparsely documented, of course) shared source library. None of the included examples use it, preferring instead to compile HLSL files directly. All of this says to me that Microsoft is trying to get people to stop using the effect file format. Is that true? Is there any documentation of any kind that states that? I'm fine doing it either way, but for years now they've been promoting the .fx format so it seems odd that they would suddenly decide to drop it.
Many professional game and graphics developers don't use the effects interfaces in Direct3D, and many of the leading game engines do not use them either. Instead, custom material/effects subsystems are built on top of the lower-level shader and graphics state state management facilities. This allows developers to do things like target both Direct3D and OpenGL through a common asset management pipeline.
The main issue is that the fx_5_0 profile which is needed to compile Effects 11 shaders with the required metadata is deprecated by the HLSL compiler team. The runtime is shared-source, but the compiler is not. In the latest D3DCompiler (#47) it emits a warning about this. fx_5_0 was never updated for some newer language aspects in DirectX 11.1 and 11.2, but works "as is" for Direct3D 11.
The second issue is that you need D3DCompile APIs at runtime to make use of Effects 11. Since D3DCompile was 'development only' for Windows Store apps for Windows 8.0 and Windows phone 8.0, it wasn't an option there. It is technically possible to use Effects 11 today with Windows Store apps for Windows 8.1 and Windows phone 8.1 since D3DCompile #47 is part of the OS and includes the 'deprecated/as-is' compiler support for fx_5_0, but this use is not encouraged.
The bulk of the DirectX SDK samples and all the Windows Store samples avoid use of Effects 11. I did post a few Win32 desktop samples that use it to GitHub.
UPDATE: With the release of the legacy Microsoft.DXSDK.D3DX NuGet repacking of the original D3DX #43, I was able to update the rest of the legacy DirectX SDK samples so they can build with the modern Windows SDK and not require the legacy DirectX SDK to be installed. Most of the Direct3D 9 and Direct3D 10 samples, and a few Direct3D 11 samples, all use legacy Effects. See GitHub.
So in short, yes you are discouraged from using it but you still can at the moment if you can live with the disclaimers.
I'm in the exact same position, and after Googling like crazy for even the simplest sample that uses D3DX11CreateEffectFromMemory, I've too come to the conclusion that .fx file support isn't their highest prio. Although it is strange that they've added the EffectGroup concept, which is new to 11, if they don't want us to use it.
I've played a little with the new reflection API, so it looks like it will be pretty easy to hack together your own functions for setting variables etc, in essence creating your own Effect-class, and the next step is going to be to see what support their is for creating render state blocks via the API. Being able to edit those directly in the .fx file was very nice, so hopefully something like that still exists (or, at worst, I can rip that part from the Effect11 code).
There is an effect runtime provided as a sample in the DirectX SDK that should be able to help you to use .fx files.
Check out the directory: %DXSDK_DIR%\Samples\C++\Effects11
http://msdn.microsoft.com/en-us/library/ff476261(v=VS.85).aspx
This suggests that it can take a shader or an effect.
http://msdn.microsoft.com/en-us/library/ff476190(v=VS.85).aspx
Also, what is the difference between a shader and an effect?