|
Chris Maunder wrote: Send me a screenshot of the ad, please.
Email sent. Got the ad again at 18:10 AEDT.
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
Ta mate.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: If you have a miracle solution to life's woes you'll be a billionaire.
Vodka? Bourbon? etc...
Latest Article - Contextual Data Explorer
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Has Anyone Seen Mike Hunt wrote: I have an ad in the top right corner
You mean you actually read them, I seem to have an automatic blind spot and don't actually register the dammed things.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: You mean you actually read them, I seem to have an automatic blind spot and don't actually register the dammed things.
It had the NRL logo, which stands out pretty glaringly on a programming/foreign website.<bnr>
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
From an Ars Technica article -
Quote: He was asked by Facebook to stay through August for optics.
Facebook is moving in to Physics? Just say we wanted to appear as if we only screwed the pooch occasionally and not all the time.
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
|
Following loosely the awesome job of Kenny Kerr at Microsoft C++/WinRT | Modern C++ for the Windows Runtime and latest C++ specifications (v17 now), I am wondering if C++ is gonna make a come back?
And if it's worth doing large scale (home, Win10, UWP) app in C++?
Or I could just stick to C# - UWP.
In fact I'd like to see C++ make a big dent in the job market once again.. C++17 looks quite slick. But I don't hold my breath. Even AI people (the upcoming IT kid) doesn't use much C++ on public API, as far as I can see...
modified 19-Mar-18 21:22pm.
|
|
|
|
|
Super Lloyd wrote: I am wondering if C++ is gonna make a come back?
It never really went away, people just stopped talking about it in polite society except occasionally in jest/derision - sorta like picking your nose.
|
|
|
|
|
It definitely has [and will keep having] a place in high performance server-side applications. For desktop high-performance most glitzy games are still being written in C++. For less demanding stuff it is more a matter of taste, some companies like C++ others do not. E.g. Spotify R&D were 5 years ago discussing to leave C++ but I think they are still there. I think the long term desktop/phone future of C++ will be decided by the development of standardized libraries for GUI etc. Threading and networking are already nicely standardized with no OS-specific quirks.
... such stuff as dreams are made on
|
|
|
|
|
After years of working with C#, I am loathe to go back to a language where I have to work with OS native types that begin with the letter H shiver 
Latest Article - Contextual Data Explorer
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
That's the thing, C++ 17 looks almost like C#, lambda expression, async code, auto keyword (aka var in C#), etc...
And when you looks at some UWP App with C++/WinRT | Modern C++ for the Windows Runtime (to be included in next Windows SDK in .. April?) it really read and write as simple as C#.... (I just discovered today it's not in the current SDK  gotta keep an eye on SDK 17025)
I think I will start playing with it in earnest with then.. can't wait for that release!
|
|
|
|
|
Super Lloyd wrote: (I just discovered today it's not in the current SDK gotta keep an eye on SDK 17025)
It's available beginning today in the Windows 10 SDK Preview Build 17120[^]
Best Wishes,
-David Delaune
|
|
|
|
|
Ha, it's on the insider preview, will wait....
Not really keen on installing virtual machines at home...
+ my internet is just mere ADSL.. not up to speed to download zillion of gigabytes...
|
|
|
|
|
Kenny's work is wonderful for sure, but I am afraid it's too little too late. I don't see enough of a push from Microsoft presenting C++ as a cloud development language. I am not even sure if it's even possible without jumping through hoops to deploy C++ code into Azure. Azure functions support multiple languages including C#, JS, Python and even PHP (but not C++). And no one's going to write a web-app UI in C++. Even for UWP, most apps are thin UI clients that consume an API - and it's far easier to develop/debug those with C#. High performance backend code is the only area where I can see someone consciously wanting to use C++. Even there managed languages are getting so much better, and when the bottleneck is the database/network, it evens out the minimal differences in performance.
|
|
|
|
|
I agree. Managed languages really do cut the cost of software development, and I see that as a really strong motivator for companies to stick with them.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
There are at least 2 serious frameworks for Web using C++: Wt and cppCMS.
As for WinRT, the whole idea of writing sandboxed Windows applications is not very appealing to most C++ developers, since it has many limitations that feel uncomfortable, after all C++ is all about control.
|
|
|
|
|
As a C++ developer, WinRT is definitely not something I would want to use, because of its limitations, to me nothing sounds more boring than "sandboxed windows applications".
However, I am a bit biased here, since I am not a big fan of MS dev environment. Anyway, I would prefer MFC over WinRT any time (and Qt over MFC, for that matter).
In any case, to answer the C++17 part, the areas where C++ is more powerful than ever is:
1. embedded,
2. car infotaiment systems,
3. Heavy apps like Adobe Photoshop or AutoCAD
4. AAA games and game engines
5. Cross-platform apps (Java and C# really sucks at crossplatform desktop apps)
6. Libraries
|
|
|
|
|
our answer got me thinking...
In fact I was looking for a C++ API that I found comfortable enough to use everyday for writing desktop app. Kenny Kerr seems to finally be it!
Why, you ask, well I want to mix and match with DirectX, so C++ is mandatory... But I want the same level of comfort I have with C# + Xaml stack, or acceptably close.
So I guess I should just give a go to ModernC++ (Kenny's work) when it is available.
As for other system... is there something that compare to WPF / UWP? ...
I am not talking about the sandboxing here, I am talking how elegant it is to write GUI using XAML and data binding.
|
|
|
|
|
Well, I don't find UWP elegant or appealing, as you can understand.
As for WPF analogues for other systems, I'd say only Qt compares with it but it's not really analogue, you won't find any analogues for sure.
Also, Mac might have something similar, but I'm not a Mac user.
|
|
|
|
|
|
After many years of C/C++ programming, I took over a couple C# projects about six years ago, and was rather sceptical about the whole thing: Managed code, automatic garbage collection, ... But the code base was established long ago; language choice was not an option.
Then, after 3-4 years of C# coding I picked up one of my hobby projects ideas, returning to the efficient, full control, knowing-what's-really-going-on C++. ... I waded through a sump in a dense jungle of setup and initialization and management code that had no relatioship whatsoever to the problem I wanted to solve, but things like space management, interface to the OS, nitty-gritty I/O details... Trivial work that I really wish I could pay the neighbour's kid to do. But then I would loose control again.
And, I decided: I trust the C# compiler more than the neighbour's kid. It will do a professional job. And looking at e.g. the heap management methods, they are far more intelligent than my own C++ versions ever were. My C# code spends a far lower percentage of the code on non-problem-related setup and management: Execution dives right into the actual, application level, user visible task that the system is meant to solve. You don't need loads of code just to pet the programming language on its head.
I have done a few timings to see how "bad" performance C# has, compared to C++. Of course it varies with the kind of operations you do, and I haven't yet seen C# beating C++ (I never expected to) - but usually, running C++ code on the previous CPU generation, C# on the latest, they come out as roughly equal. My productivity being much higher, and my error rate much lower, when using C#, I have no desire to go back to C++.
When I tried to return to C++, I was still on Visual Studio 2010. I had been impressed with the programmer support it provided for C#, both in catching typos etc long before a build was attempted, and in helping me find the right functions etc. I expected the C++ support to be on the same level (previously, I had not been using a modern IDE when coding C++), but was very disappointed. I believe much of is the "flexibility" (or "You asked for it, you got it") of C++: The compiler (/VC syntax analyzer) simply cannot smack your fingers when you do something silly - it is silly, but legal C++ nevertheless... (prime example: Pointer arithmetic). Now I am on VC 2017, maybe C++ programmer support is now at the same level as for C#. I haven't tried C++ with VC 2017: Assembler coding (I've done my share of that!) belongs to history, so does C++. For me. (I would even start assembly coding again if I were paid a million, and again: so I would with C++.)
In my "computer humour" scrapbook, there is a discussion from 1998-99 (on NetNews/Usenet...) with this guy insisting that high level languages are a fad: They will never be able to compete with properly written assembly code. Well, it can. GC can compete with most hand-written heap management code. On-the-fly compilation of the intermediate language can be fine-tuned for the specific CPU in use. It will not go away. Even in the long run, a few people will need to know assembler language, a few will have to know Fortran, a few will have to know how to handle pointer arithmetic. But it won't be mainstream again.
|
|
|
|
|
I got you man! 
In fact I am not in love of C++ nor want deep control but
- I want C++ to be as easy as C# + Xaml stack
- I want to use DirectX seamlessly
and speaking of which Kenny Kerr work in upcoming SDK 17025 seems to be it. Really impressed. Upcoming C++ 17 standard helps too.
- I would like C++ to be as easy as C# to integrate with other .NET work, with off chance I hit a scenario offers critically more performance.
And, could you believe it, I hit that scenario today at work. In an UWP app we were accessing some low level hardware but some operation was 100x times faster in C++. Turns out it is because, I believe, any high level device operation requires reading and writing lots of small array. Having a huge cross ABI boundary cost.
Luckily writing a C++ UWP component available usable by my C# project proved easy. Although I couldn't get to reference a C# interface in the C++ component, ending making it standalone.
Finally thanks for your feedback. It was interesting and relevant.
|
|
|
|
|
Quote: Luckily writing a C++ UWP component available usable by my C# project proved easy.
I think this is the best approach, for now. Need a high-performance/control module? Make a C++ library and just integrate the project. BAM! Best of both worlds, with some "overhead".
|
|
|
|
|
Most of my C# coding has been GUI and file system related. Timing comparisons are relevant only on selected parts with no user interaction. For file system operations, disc waiting time may easily be ten times the processing time - and that waiting is roughly programming language independent, unless the language libraries use different buffering strategies (and then you are comparing buffering strategies, not languages).
So, for a long time I had overlooked the "Optimize code" chekcbutton in the VC project properties: For the GUI/disk related projects it really didn't matter. When I checked it, CPU bound code became approximately 4 times as fast(!) (but cannot be properly debugged). Now I would certainly like to rewrite some of that CPU bound code in C++ to see if there is anything to gain. I guess that it will be very little!
(By the way: There is no noticable speed difference between x64 code produced directly by the C# compiler, compared to CIL generated by the compiler with final code generated by dotNet to x64 on the first run. I didn't expect there to be - but lots of people believe that the just-in-time code generating imposes a heavy perfomance penalty.)
As you say: C++ (or just plain C) has its place as a CPU independent (high level) assembly language, e.g. for interfacing to hardware. In the old days, libraries were written in assembly, nowadays in C/C++. They make the interface available to e.g. C#, but you won't get completely away from assembly/C to create the interface library.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
