|
In C and C++ it doesn't really matter. In fact it's compiled into constant nothings basically (removed).
In C# it's a ValueType which makes it closer to a struct than a class in terms of how it behaves - stack vs heap, etc.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
diligent hands rule....
|
|
|
|
|
|
|
It's easy. Start a new project in the target language of your choice. Copy the bare minimum from the source language, paste it in the new language target husk, and attempt to compile.
You'll get tons of errors and warnings. Pick through them and eliminate them one-by-one.
Obviously there's a lot of personal experience in "attempting" to do anything using a compiler and a linker.
Done this, have I. Learned much have I.
modified 8-Jan-24 14:55pm.
|
|
|
|
|
RedDk wrote: You'll get tons of errors and warnings. Pick through them an eliminate them one-by-one.
It's hard to tell if that's sage advice or sarcasm.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
It sounds like the advice to start with a block of stone and remove the parts which don't look like an elephant.
|
|
|
|
|
This is exactly how I converted about 10,000 lines of VB6 code to VB 2005. The biggest changes were file handling and error reporting. To this day I'll occasionally use On Error Resume Next in short Subs and Functions when it's appropriate. Otherwise I use Try/Catch/Finally.
|
|
|
|
|
That's it exactly. Initially posting line-numbered QBASIC code into a C++ project ... I was surprised how little squawking the VS interface returned. I like that "On Error Resume" trick. Next time ...
|
|
|
|
|
obermd wrote: To this day I'll occasionally use On Error Resume Next
as long as you put something in between...   
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
On Error Resume Next is really useful for short clean up routines where the code would look like this
try {statement1} catch {}
try {statement2} catch {}
...
|
|
|
|
|
what (empty catch blocks) actually is something I do not like, have already lost some precious time tracking down things done by people thinking it is not needed.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
At least to me the OP suggested that they want to use WinForms and that existing code does not use that.
So that is a complete rewrite at least for that part.
|
|
|
|
|
Does it 'need' to be C#? Or can you use C++/CLI? Because the latter would be much simpler, in the sense that you can keep your algorithms and the back end stuff in C++, and do the user interface in C++/CLI.
Is your user interface in MFC, or WTL or something else?
The user interface would have to be re-built from scratch
|
|
|
|
|
You're going to have to rewrite UI code regardless. The one advantage going to WinForms would be correspondence in the UI. WinForms is something of a wrapper around Windows GDI controls for C#, in the same sense that MFC is a wrapper for C++.
Software Zen: delete this;
|
|
|
|
|
In my experience of rewriting from one language into C#, there are a few principles I applied that helped me.
1 - Understand the requirements, architecture, and intent of the original code (which may have to be determined with only the original code at hand).
2 - Understand WHAT the original code is doing.
3 - In the new language (e.g. C#), determine how it best does what the original code did. Just translating code from original to new is a trap.
4 - What does the new language offer (including third party components if you want) that would be useful, that was not used for the original app with the original language?
5 - What new language architecture gives you the lowest total SDLC cost with the best acceptable performance, scalability, and support?
Apply these principles and you will avoid a myriad of booby-traps and sloughs of despond.
|
|
|
|
|
Isn't it better to use an existing product? Have you looked at ScottPlot ?
Behzad
|
|
|
|
|
|
Nothing hard. After C++ you'll write C# code like a song.
|
|
|
|
|
There are good charting controls available off the shelf for WPF, maybe for winforms but just go WPF.
If those just won't do, you probably want to look for "using GDI+ from WPF" if you're looking to draw your own charts.
If you're really wanting to visualize data in interesting ways, it might not be insane to look into using Unity.
Custom rendering with GDI+ is.... hard to get a positive return on investment unless you're a company that sells components for WinForm/WPF.
|
|
|
|
|
I needed a project to ward of boredom in the wee hours.
I decided to do something I can't do - Reflection Emit from C#
I built a Compile() feature into my regular expression engine that works like .NET's does.
After wrestling with it for a little over a day, pay dirt!
Gosh, IL is weird, but pretty simple once you get the hang of it. The VM is a very basic stack machine. It's extremely minimalist compared to modern CISC CPUs.
Anyway, now I need to figure out how to write an article around it once I'm done basking in my accomplishment.  Edit: I wrote the article: Compiling DFA Regular Expressions into .NET Assemblies[^]
I'm pretty proud of this code.
Edit 2: Updated the timing to remove the time for console writing and I'm blown away.
Microsoft Regex "Lexer": [■■■■■■■■■■] 100% Done in 1556ms
Microsoft Regex Compiled "Lexer": [■■■■■■■■■■] 100% Done in 1186ms
Expanded NFA Lexer: [■■■■■■■■■■] 100% Done in 109ms
Compacted NFA Lexer: [■■■■■■■■■■] 100% Done in 100ms
Unoptimized DFA Lexer: [■■■■■■■■■■] 100% Done in 111ms
Optimized DFA Lexer: [■■■■■■■■■■] 100% Done in 6ms
Table based DFA Lexer: [■■■■■■■■■■] 100% Done in 4ms
Compiled DFA Lexer: [■■■■■■■■■■] 100% Done in 5ms
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
modified 6-Jan-24 20:42pm.
|
|
|
|
|
Congratulations!
I am always amazed at the brilliant accomplishments of the CP members!
|
|
|
|
|
honey the codewitch wrote: works like .NET's does
And how is that? I use the Compiled option when I make a RegEx I know I'll use a bunch of times, but I don't know what that actually does.
|
|
|
|
|
Normally Regular Expressions (using Microsoft's or my engine) are interpreted at runtime.
That is, the engine turns the expression into a state machine graph and traverses that at runtime to match text.
When you compile it, it is no longer interpreted at runtime. Instead, the state traversal for that expression is hardcoded into machine language instructions, and optimized in the process.
The upshot is longer startup times but faster execution.
However, my engine allows you to operate on state machines that are packed into a simple flat integer array. (int[]), and runs nearly as fast as the compiled version, or faster in some cases.
Pick your poison.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
My main thing is that I don't know what the Compiled Option actually does. I have an idea what it might or should do, but then it doesn't seem to make much sense not to include it every time.
The "Compiled" option can't instruct the compiler to make IL of the expression at compile time, it has to be at runtime.
I can definitely understand that "compiling" can help when a RegEx is used many times, but does it slow down a RegEx which is used only once or a few times? Is there some number of calls where performance matches (for a particular expression)?
I also found that (apparently) the RegEx class caches the expressions and I suspect that it must "compile" them as well, otherwise why bother?
I just read this:
https://stackoverflow.com/questions/513412/how-does-regexoptions-compiled-work[^]
Which I don't consider canon, though it may be correct.
So Compiled makes it IL at some cost -- great, perfect.
But non-Compiled must do something (at lower cost) as well which can be cached -- "turns the expression into a state machine graph" or similar?
Might it then be kinda:
0) Take Expression in as text
1) Create state machine graph of the Expression and cache it
2) If requested, compile the state machine graph into IL -- and maybe cache that as well?
There is also the question of performance between the static RegEx methods and an instance of a RegEx. Using an instance should at least eliminate the cost of a cache look-up.
Part of why I ask is that I have written a number of methods which use Regular Expressions, and some of these get used by CLR Functions in SQL Server. I therefore want them to run as efficiently as they can as they may be called several million times during a query.
Also, in your response, I suspect that when you say "runtime" you may mean "on each call", not just "on the first call".
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
