|
Lewis Carroll said it all: Quote: “Then you should say what you mean,” the March Hare went on.
“I do,” Alice hastily replied; “at least—at least I mean what I say—that’s the same thing, you know.”
“Not the same thing a bit!” said the Hatter. “Why, you might just as well say that ‘I see what I eat’ is the same thing as ‘I eat what I see’!”
“You might just as well say,” added the March Hare, “that ‘I like what I get’ is the same thing as ‘I get what I like’!”
“You might just as well say,” added the Dormouse, which seemed to be talking in his sleep, “that ‘I breathe when I sleep’ is the same thing as ‘I sleep when I breathe’!”
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
I get what you "mean".
I've transitioned to using mostly "getters"; instead of coding logic "inline".
e.g. if ( zone.IsRunning ) {}
where IsRunning (for example) is a PROPERTY:
bool IsRunning { get { return this.Status > Zone.Status.Idle && this.Status != Zone.Status.Paused && ... }};
This can be extended to "last", "first", etc. by wrapping SIMPLE queries in a "getter".
The code then takes on the "flavor" of the original "english-like" spec. It then becomes easier to "validate" the two against each other; assuming the spec was reasonably structured to start with.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
I have this problem, but before I tell you the problem I need to tell you what my goal is. I'm building an application where there is a main form(I'm using c# and winforms) and a bunch of mini tool forms that go along with the main one. I understand there are frameworks already like this, but I want to create my own. I would like the tool forms to be able to dock to the main form based off of percentages(unless there are other ideas) so that when you scale the main form the tool windows change with it. The tool forms should also be reshape-able inside the main form, and therefore should have an affect on the other forms in the layout.
Another necessity is that you can save the current "workspace" and load it from a file. So, whichever method I choose has to be able to call a finished loadWorkspaceFromFile(); and saveWorkspaceToFile(); on the main form.
Right now I have all the tool forms as separate forms, and I want to keep it that way. I've messed around with windows tracking other windows in my application, and I think the speed and performance is fine, so I wouldn't want to go to a resize-able panel system.
I know my way around c# I'm just looking for some insight and inspiration on how to go about solving this algorithmic problem. Any help is greatly appreciated. Thanks in advance for your time, Carson
|
|
|
|
|
You can do all of that with standard .NET classes.
|
|
|
|
|
new Human("Carson"); wrote: and therefore should have an affect on the other forms in the layout.
You are going to need to define that requirement more.
If I drop two boxes in a window and resize one of them the other should not change shape.
|
|
|
|
|
In WPF you have a dock attribute, I'm not sure it is in winforms but I think it should be. That will not solve you resizing issue but may give you some pointers.
As for saving a layout that is simply trapping the onclose() event and recording the tool forms positions within the form. I write that information to the users app data folder.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Visual Studio IDE like Dock Container[^]
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
new Human("Carson"); wrote: The tool forms should also be reshape-able inside the main form, and therefore should have an affect on the other forms in the layout.
... Right now I have all the tool forms as separate forms, and I want to keep it that way.
First, do not put a WinForm inside another WinForm by adding it to the other Form's Controls collection. While it's possible, it's a needlessly "heavy" choice, and you can use a Panel to implement the same functionality.
The question you need to answer is whether you want these tool windows inside the Main Form, or outside: if outside, you can set the 'Owner property of the tool form to the Main Form, which will keep the tool form always above the Main Form.
For Panels in the Form, you can use 'Dock and 'Anchor properties to simulate docking and dynamic re-size; you can easily make a Panel re-sizable at run-time with very little effort.
However, if your goal is to allow the run-time user to change the tool form docking, that's a major effort, and I suggest you download and study the code of the open-source DockPanel Suite: [^]. Note that this project is not being actively maintained.developed.
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For that which is alone in your own power—a right use of things as they appear.» Discourses of Epictetus Book I:12
|
|
|
|
|
Hi!
TLDR:
I want a programming language that fulfills the following requirements:
Musthaves:
1) can compile to small executables that run as fast as C++ (maybe ideally the language transpiles to C++)
2) static typesystem (for speed and cleanness, a C++-like template system is also cool)
3) not a hell of torture and despair to program in
4) free
5) big standard (math) library or c++ bindings
6) compiles on all platforms
Nicetohaves:
- scripting and stepping through the code while debugging
- designed for matrix operations like matlab or julia (so I can write A*B instead of matrixMultiply(A, B))
- usable GPU bindings
- nice graphics and plots would be nice but I'm fine doing that in three.js and communicating via socket
Where famous things fail:
c++: point 3!!
python: point 1, 2
matlab: point 1, 2, 4
octave: point 1, 2
julia: point 1 (such a shame!!! it seemed so perfect!)
Things I did not try yet but might checkout: Go, cython and Felix
I appreciate if you could share any experiences with those and why they might suck for my purposes. And I happily take suggestions if you know the perfect thing for me!
The long story:
I am an engineer and the main things I program are mathematical algorithms (often involving a lot of spacial transformation and trajectory planning and such) and games. Over the years I have tried many programming languages. I started in VB and then moved to C++ at some point. I often go back to C++ when I need the performance but it's just such a pain to develop in it... Just the thing with the h and cpp files which entails that I have to write everything twice is ultra annoying. I know the IDE can assist me but I just want lean code. At university I learned matlab. Developing in matlab is orders of magnitude more pleasant, lemmetellya... However, I can only distribute my code to people who have a matlab license. Which does not include myself anymore. I heard numpy and python are alternatives, so I tried them. They are nice to work with but the code runs terribly slow.
During yet another fed-up-with-all-this look through the internet, I stumbled upon Julia. Julia seemed to have it all. I binge-read the documentation and loved so many aspects about it! UTF-8 source code so you can write a cross for cross product and a dot for dot product! Greek variable names! Scripting and compiling capabilities! Nested for-loops that can be escaped with a single break (so there is actually no reason to use goto anymore  ), matrix operations and functions with multiple return parameters are nice! Arbitrary precision built in! Everything seemed too good to be true! But then, when I wanted to create a stand-alone executable, it created 50 dll files with 200MB in sum for a helloworld program. That's just not cool. I hope the developers tackle this last thing, then it might really become my home language.
So I went back to C++ yet again. This time I tried to nicen it up as much as I could. The Lazy C++ project took the h/cpp pain away. But I didn't want to stop there. I wrote my own pre-pre-processor that does many search-n-replaces with the files that I write and turns them into lzz code (which is then turned into h and cpp). For instance:
func divide maps (int x, int y) to [int q; int r] sothat
return {x/y, x%y};
endfwhich is translated into:
struct divide_result{int q; int r;};
divide_result divide(int x, int y){
return {x/y, x%y};
}or
for i from 0 to 9 do
loop
And many things like that. And I'm happy with it, I like the syntax much more than the brackety C++ gibberish. And a lot of typing redundancy is gone. However... I found that - surprisingly - no IDE supports syntax highlighting, code folding and all that for my own code. If the compiler finds an error, I have to check where it is in C++ and then find that place in my code. This extra step becomes annoying over time. Also, my transpiler is far from intelligent and there are many pitfalls that it does happily run into, not telling me what's wrong because it just does regex replaces. And writing a proper parser is just too much work. And also, I feel like I stumble into every pitfall that c++ offers, resulting in much more debugging than in any other language. I know that good practice can avoid much of that but therefore one has to know all the good practices and that takes... well.. a lot of practice.
So. Before I continue my everlasting pilgrimage in search of the perfect programing language, I seek advice in you, dear internet, for I cannot be the only one who has embarked on this quest of disappointment and pain!
Guide me!
|
|
|
|
|
|
|
Back in the 60s or 70s I would agree.
|
|
|
|
|
Nope.
All the compiler optimizations designed since the 1979s are applied to FORTRAN compilers so that FORTRAN remains the fastest language for implementing mathematical algorithms.
Plus, since memory is statically allocated at compile time, there is no runtime memory allocation and deallocation or garbage collection for FORTRAN.
|
|
|
|
|
One uses "spec machines" that have the horse power to tackle VR, face recognition, tracking (i.e. math and games).
Then it's just a question of whose SDK and peripherals you prefer: MS; HP; Oculus Rift.
Cobbling things together; starting with the "fastest and bestest" software (without the "bestest" hardware and SDK) is a guess.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Thanks for the responses! And sorry for being so unspecific in the title... But by fast I address both performance of the compiled code and development time. I would like to have a programming language that is less complicated and error-prone than c++ without sacrificing too much runtime performance. It must be possible! It must!
|
|
|
|
|
I would take a look at Rust if I were you. Once you get used to it, it's very pleasant to use.
This space for rent
|
|
|
|
|
The "best" for me has been the one with the most / best samples; because I write for other people; who then pay me.
No other combo interests me ... unless it's for "pure" research; and then the "familiar" is still more usefull.
.Net framework and C#.
Maybe not the "fastest"; but it is the best and fastest "to market" for me. Which includes plotting thousands of points per second and managing a few hundred PLC "ladders".
Part of being the "fastest" is having good "libraries" (Unity; Unreal Engine; Quake / Doom engine) if you get into "gaming".
No one will see how "fast" your game is if it never gets out of development (and no one develops their own game / graphics engine any more).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
If there was a language that does all that; imagine, speed of C++, ease of VB6 (yuch), and all the works, then why would people still use C++? Wouldn't it already be replaced, and these forums buzzing with new articles on the language that can do all?
mirkocontroller wrote: Everything seemed too good to be true! But then, when I wanted to create a stand-alone executable, it created 50 dll files with 200MB in sum for a helloworld program. That's just not cool. I hope the developers tackle this last thing, then it might really become my home language.
They won't; those features aren't built in to the hardware, and those libraries need to be present if you want to use them. If you want to write very small apps, you'll be using a language that compiles to native.
mirkocontroller wrote: Before I continue my everlasting pilgrimage in search of the perfect programing language
There isn't one that fits all, because we do not value the same things 
Even the "compiles on all platforms" is long known to be a holy grail in IT. Imagine, you go for C++ because you want small executables - next you need a UI. Which cross-platforms UIs exist?
If you want to write games, you want to use a framework that is built for that purpose. You don't want to focus on having the smallest executable in that case. Most modern games are "several floppy disks" in size - not counting dependencies like DirectX. For games, I'd point to Unity/C#.
For cross-platform compiling, I'd point to C#/WinForms, with the sidenote that I know nothing about the Mac and intend to keep it that way. Which platforms would you target btw? Windows obviously, but next to that?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
mirkocontroller wrote: 1) can compile to small executables that run as fast as C++
Performance is not a matter of technology but rather of knowledge.
Performance is going to be based on requirements, design and implementation with technology bringing of the rear.
mirkocontroller wrote: At university I learned matlab. Developing in matlab is orders of magnitude more pleasant, lemmetellya... However, I can only distribute my code to people who have a matlab license. Which does not include myself anymore.
Oddly enough people that develop solutions like to get paid for that. Probably has something to do with paying rent and putting the kids through college.
mirkocontroller wrote: But I didn't want to stop there. I wrote my own pre-pre-processor that does many search-n-replaces with the files
Many, many people write their own languages. I suggest strongly that before one makes a serious attempt at that they take at least one and perhaps two college courses specifically about that. Look for one that says "Compiler" in the title and one that uses the 'Dragon' book (it has a dragon on the cover.)
The reason of course for doing that goes back to my first point - knowledge.
|
|
|
|
|
Perhaps D is something that fits. It's C/C++ like, but without many of the things you mention as irritants. It aims to produce speedy binaries, it runs on Win and Linux, there are many libraries available. It's free (AFAIK) and will require some toolchain assembly, but it might just be what you're looking for.
|
|
|
|
|
Hi,
I've been wondering about something for some time now. In assembly (Masm32), which I believe C and C++ are being compiled into (at least Visual C++ is) the largest integer type is the 80-bit TBYTE type, and the largest float type is REAL10, which is also 80 bit big.
So the question is this: how come C++ can have a "long double"-type that can hold 96 bit? There's even a __int128 keyword, even if it is not supported by my version of Visual Studio (it is still being syntax highlighted though, which by itself is strange). And what about C#'s decimal-type?
When I disassemble a C++-program that uses a long double-type, I can see it is given the REAL10 type, but sizeof(long double) does not yield 10, but 12. The MSIL-code for a .NET-app that uses a System.Decimal doesn't specify what happens "behind the scenes" as it is still called System::Decimal in IL. But how come it can hold values greater than 2^80?
|
|
|
|
|
deXo-fan wrote: how come C++ can have a "long double"-type that can hold 96 bit?
It doesn't really. Long double most commonly refers to the 80bit float type, but that's a weird size so it might be rounded up for eg alignment purposes. __m128 (and its integer relative, __m128i) really is a 128bit type, but it is a SIMD type that does not support many operations that interpret it as a single 128bit quantity (it's more about doing k operations at once on (128/k)bit quantities). If you find that your compiler does not support it, it must be over a decade old.
Apart from those odd exceptions, types wider than natively supported can easily be supported as structs that contains several fields that make up a value together, as happens for __int128, long long in 32bit C++ code, (u)long in C# running as 32bit code, C#'s decimal (which is a soft-float and therefore extremely slow), etc. Since many operations on those things are not directly supported by the processor, more code is generated to implement those operations. For example addition can be "chained" by using the adc instruction, and there are somewhat more complicated algorithms for multiword arithmetic in general (actually you are already familiar with some of them, since you probably learned decimal arithmetic and that requires non-trivial algorithms to deal with any numbers that have more than 1 digit).
|
|
|
|
|
Thank you for the very quick and useful reply. I'm using Visual Studio 2017. What I meant was that when I type "__int128" it turns blue as if it were a native, intrinsic type like int or char. I didn't know it was a struct.
What is a "soft-float"? And can you elaborate a little on why it is slow?
Also, it seemed you wanted to emphasize on the 32bit when you wrote this:
long long in 32bit C++ code, (u)long in C# running as 32bit code
Does that mean the types behave differently or are somehow different, for instance in size, when I either compile a program as 64-bit or run it as 64-bit rather than 32-bit?
|
|
|
|
|
__m128 is supported in VS 2017, you'd need #include <intrin.h>
deXo-fan wrote: What is a "soft-float"? And can you elaborate a little on why it is slow?
It just means that the operations on it are all emulated in software, which is fairly complex. In a circuit that cost can be significantly hidden thanks to the flexibility (eg extracting bits is "free", just a wire, but in software it would cost a shift and mask) and parallel nature of the medium, but in software it's all a major pain, so much that depending on the benchmark decimals may be one to two orders of magnitude slower than doubles. For integer operations, emulating bigger types in software is much less harmful to performance.
deXo-fan wrote: Does that mean the types behave differently or are somehow different, for instance in size, when I either compile a program as 64-bit or run it as 64-bit rather than 32-bit?
Not that, but a 64bit program can use native 64bit instructions (so operations on an (u)long are natively supported), while a 32bit program mostly cannot (at least it cannot operate on 64bit GPRs since those do not exist, it could cheat a bit with 64bit SIMD but that isn't fully featured). For example the normal add instruction has a 64bit version, which is only available in 64bit mode.
|
|
|
|
|
My BigInt[^], shows how you can create a "VeryLargeBigInt" type, and calculate numbers that are larger than a typical "int" type can hold.
Basic idea is that you can use smaller operations to do the complex one, in software.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
