I learnt C++ in 2018 and have no regrets • Hacker News Board

Re: I learnt C++ in 2018 and have no regrets

#241

Post by Const-me » Tue, Jan 08, 2019, 6:48 AM UTC

pjmlp wrote: post #240

Const-me wrote: post #234

Earlier quoted context omitted.

I think Delphi and C++ Builder were only good enough while WinAPI meant “C API”. JavaScript is OK for platform-independent development with electron. For platform-specific i.e. WinRT not that good, .NET is just better, and MS put the JS libraries in maintenance mode: https://github.com/winjs/winjs Python was never good. I’ve tried using winapi through C interop a few times, didn’t like it at all despite what I did wa…

Delphi and C++ Builder have first class support for COM and UWP. In fact, both had better COM support before VB migrated from VBX to COM with VB 6.0. JavaScript has first class support on UWP. Of course WinJS is in maintenance BB mode. The future of JavaScript on UWP are PWA apps, with direct access to UWP APIs, no more need for WinJS, which was a Windows 8 library. Python has supported COM with help from PyWin32 sin…

> first class support for COM and UWP

When I search “Delphi DirectX”, I only find some Russian website last updated in 2009 and offering Direct3D 10.1 bindings. The newest one is 12, the oldest supported is 11.2.

When I search “Delphi Media Foundation” it’s better, finds bindings updated 4 years ago.

These COM-based technologies are among reasons why I sometimes still pick C++ even for new projects.

Also, in both cases just bindings are not enough, the frameworks are complex, need code samples, stackoverflow community, sometimes books, etc. There’re tons of resources on using these from C++, many from C#, very few for the rest of the languages.

> JavaScript has first class support on UWP

Win32 GDI also has first class support on Win10, just because it’s supported doesn’t mean it will go anywhere. I have doubts MS will continue with that support, they haven’t achieved much and need to do something else, e.g. include CEF in the OS.

> Hardly any different from VBScript.

The difference is that VBScript _is_ COM. All VBScript variables are VARIANT, all strings are VARIANT of VT_BSTR type, and all objects are IDispatch. The interop is not required, COM is already native to the runtime. I can write a COM server in a page long text file with *.wsc extension and VBScript inside, register it with regsvr32.exe, and consume from any language, e.g. `#import "progid:..."` in VC++. I’m not sure you can do same in Python.

Re: I learnt C++ in 2018 and have no regrets

#242

Post by zvrba » Tue, Jan 08, 2019, 7:06 AM UTC

Const-me wrote: post #186

lmm wrote: post #71

Earlier quoted context omitted.

Making Rust work nicely with win32 is probably less effort (and more valuable) than getting enough momentum behind a good dependency manager for C++.

> work nicely with win32 is probably less effort Gonna be very hard to do. For the last 15+ years COM is essential part of WinAPI, and too many things in Rust conflict with COM: ownership, OOP, virtual tables, inheritance, they all too different. Not just in Rust, in all languages, actually. You only have 2 good choices for complex platform-dependent windows development: either C++, or a microsoft's language with COM…

> too many things in Rust conflict with COM

Do they? COM in its essence defines two things:

1. A binary ABI for interoperability of components written in whatever language. 2. Reference-counting mechanism and "casting" mechanism (IUnknown).

MS has an article that shows how to build a COM component from the ground-up using only plain C structs containing function pointers (which is how vtables are implemented anyway: array of function pointers). What you think of inheritance can be implemented with a struct containing nested structs of function pointers. Etc.

It's not insurmountable, e.g., PyWin32 has utilities for both consuming and implementing COM components.

Re: I learnt C++ in 2018 and have no regrets

#243

Post by TeMPOraL » Tue, Jan 08, 2019, 7:10 AM UTC

wbl wrote: post #115

wues wrote: post #74

Earlier quoted context omitted.

C compatibility was the very reason for which C++ is bigger, more complicated and less safe than a similar language not compatible with C could be.

Really? C++ accidentally has a Turing complete templating layer. I suppose one could point to Common Lisp but if you think that is simple....

Well, Common Lisp is simple. Except maybe the Metaobject Protocol (which ultimately didn't make it into standard, but it sort of still is). And except eval-when. Eval-when is magic.

Re: I learnt C++ in 2018 and have no regrets

#244

Post by zvrba » Tue, Jan 08, 2019, 7:11 AM UTC

smallstepforman wrote: post #236

mhh__ wrote: post #185

Earlier quoted context omitted.

Only if you write unidiomatic ( Read crap) C++. In modern C++ it is very much possible to write fast and safe code, but the tradeoff is now put into the amount of stuff the developer needs to know to be productive (Which in my experience isn't as bad as people like to go on about on here/reddit, even if it still pretty shoddy)

> Only if you write unidiomatic (Read crap) C++. Thats a bit unfair. A recent headache for my C++ project was mixing audio buffers. The buffers are cached to avoid repeated reads, the channel count differs, the sample rate can differ, the output rate can differ, and mixing has gain limiters applied etc. Lots of buffers, lots of copying, lots of boundary cases (eg. sample #1 doesnt start until t=100ms, sample #2 ends…

> I struggled for days getting all the buffer copying right (raw pointers to many interrim buffers).

It seems like you struggled with math (indexing logic) rather than C++.

> how else can you tackle this problem in a modern way?

You could try to write an iterator that takes into account sample rate, channel count, etc. That way the logic for handling buffer formats and iteration over samples is encapsulated into a single reusable component.

Re: I learnt C++ in 2018 and have no regrets

#245

Post by newdaynewthrow » Tue, Jan 08, 2019, 7:14 AM UTC

Hi, I guess I'm a little out of the loop... Why would someone generally have regrets? What language "should" be learned in 2018 instead of something like C++ (which it sounds like is becoming obsolete)

Re: I learnt C++ in 2018 and have no regrets

#246

Post by gshack » Tue, Jan 08, 2019, 7:15 AM UTC

jandrewrogers wrote: post #171

gshack wrote: post #134

Earlier quoted context omitted.

Why would one use menson over cmake ?

Meson is much easier to use and configure for C++, being quite obviously designed specifically with C++ builds in mind. It automagically does the right thing for setting up most C++ build environments by default with virtually no config or quirks you need to learn. It is built on top of Ninja, and generally very fast and efficient. The only real knock against it is that the documentation isn't as good as could be, an…

Menson's syntax is very similar to Cmake, would u say it's a better/faster version of Cmake ?

Re: I learnt C++ in 2018 and have no regrets

#247

Post by zvrba » Tue, Jan 08, 2019, 7:16 AM UTC

vasilipupkin wrote: post #133

lmm wrote: post #86

Earlier quoted context omitted.

Nonsense. C++'s template system behaves unlike any other language (things like SFINAE and the techniques that use it do not transfer), C++-style RAII is relatively unusual, I don't think any other language requires the programmer to think about virtual versus non-virtual inheritance, the C-derived sequence point rules are obscure and much looser than most languages' evaluation rules, the exception-safety rules are un…

well, that's just like, your opinion, man ( big lebowski reference for those too young to know ). The reason I disagree with you is because I have never met a C++ programmer who only knew C++ and couldn't easily do work in some other language, but of course plenty of people know other languages and can't do C++. Yes, SFINAE and RAII - you can go for many years of working in C++ without writing much code using either…

> Yes, SFINAE and RAII - you can go for many years of working in C++ without writing much code using either one of those.

WTF, RAII is the corner-stone of C++ development. And I miss it (deterministic destruction) in every other language I use.

These days I use C# in parallel with C++, C# has using statement, but it relies on IDisposable, and IDisposable itself is a kludge (just look at guidelines on how to implement it "properly").

Re: I learnt C++ in 2018 and have no regrets

#248

Post by Const-me » Tue, Jan 08, 2019, 7:22 AM UTC

zvrba wrote: post #242

Const-me wrote: post #186

Earlier quoted context omitted.

> work nicely with win32 is probably less effort Gonna be very hard to do. For the last 15+ years COM is essential part of WinAPI, and too many things in Rust conflict with COM: ownership, OOP, virtual tables, inheritance, they all too different. Not just in Rust, in all languages, actually. You only have 2 good choices for complex platform-dependent windows development: either C++, or a microsoft's language with COM…

> too many things in Rust conflict with COM Do they? COM in its essence defines two things: 1. A binary ABI for interoperability of components written in whatever language. 2. Reference-counting mechanism and "casting" mechanism (IUnknown). MS has an article that shows how to build a COM component from the ground-up using only plain C structs containing function pointers (which is how vtables are implemented anyway:…

> COM in its essence defines two things

COM is quite a lot of things. Also threading model, date-time-currency formats, late binding/dynamic dispatch/scripting, type info both runtime and design time, IPC, RPC, security, and more.

> What you think of inheritance can be implemented with a struct containing nested structs of function pointers

What I think of inheritance in the context of COM is called “aggregation” and it’s more complex than that.

> It's not insurmountable

It’s not, but you’ll spend ~2x more time doing that compared to C++, and ~4x more time compared to VBScript or .NET.

Update: that 2x-4x is for implementation. For consumption C++ and .NET are close, but anything else is more complex due to FFI in between. C++ or VBScript don’t need FFI, .NET runtime is designed around many key parts of COM e.g. they have reused HRESULT’s and type info format.

Re: I learnt C++ in 2018 and have no regrets

#249

Post by pjmlp » Tue, Jan 08, 2019, 7:49 AM UTC

Const-me wrote: post #241

pjmlp wrote: post #240

Earlier quoted context omitted.

Delphi and C++ Builder have first class support for COM and UWP. In fact, both had better COM support before VB migrated from VBX to COM with VB 6.0. JavaScript has first class support on UWP. Of course WinJS is in maintenance BB mode. The future of JavaScript on UWP are PWA apps, with direct access to UWP APIs, no more need for WinJS, which was a Windows 8 library. Python has supported COM with help from PyWin32 sin…

> first class support for COM and UWP When I search “Delphi DirectX”, I only find some Russian website last updated in 2009 and offering Direct3D 10.1 bindings. The newest one is 12, the oldest supported is 11.2. When I search “Delphi Media Foundation” it’s better, finds bindings updated 4 years ago. These COM-based technologies are among reasons why I sometimes still pick C++ even for new projects. Also, in both cas…

So I talk about COM, and you move the goal posts about DirectX in particular, that only implements a subset of COM, which requires writing wrappers by hand, including in .NET, hence Managed DirectX, XNA and SharpDX projects.

Apparently you missed the news regarding PWAs in Windows and its support for native UWP. Again, WinJS got dropped, because it was tied to the Windows 8 programming model, which got improved on Windows 8.1, only to be replaced by UWP on Windows 10.

Win32 GDI actually has "we wish you were all using Win2D and DirectDraw" support on Windows 10.

Here are some examples of automating Excel with Python, http://pbpython.com/windows-com.html, hardly any different from using VBA.

Re: I learnt C++ in 2018 and have no regrets

#250

Post by Const-me » Tue, Jan 08, 2019, 8:22 AM UTC

pjmlp wrote: post #249

Const-me wrote: post #241

Earlier quoted context omitted.

> first class support for COM and UWP When I search “Delphi DirectX”, I only find some Russian website last updated in 2009 and offering Direct3D 10.1 bindings. The newest one is 12, the oldest supported is 11.2. When I search “Delphi Media Foundation” it’s better, finds bindings updated 4 years ago. These COM-based technologies are among reasons why I sometimes still pick C++ even for new projects. Also, in both cas…

So I talk about COM, and you move the goal posts about DirectX in particular, that only implements a subset of COM, which requires writing wrappers by hand, including in .NET, hence Managed DirectX, XNA and SharpDX projects. Apparently you missed the news regarding PWAs in Windows and its support for native UWP. Again, WinJS got dropped, because it was tied to the Windows 8 programming model, which got improved on Wi…

> you move the goal posts about DirectX in particular

In my first comment I wrote that COM became an essential part of WinAPI. Excel runs on Windows but it’s not Windows. DirectX on the other hand is in OS kernel, mayor parts are dxgkrnl.sys. Same applies to media foundation, Windows shell and clipboard, WMI, and many other OS components.

> which requires writing wrappers by hand, including in .NET, hence Managed DirectX, XNA and SharpDX projects.

Right, and all except SharpDX are first-party i.e. made by MS. MS made even more wrappers, WPF, Direct2D and UWP are also manually written wrappers around D3D 9 or 11.

How many wrappers MS made for Delphi or C++ builder?

> you missed the news regarding PWAs in Windows and its support for native UWP

I’m a bit skeptical about the technology.

> examples of automating Excel with Python

Simple IDispatch not that hard even in pure C. It’s more advanced things that require better support for COM: servers, events-callbacks, data structures like arrays and dictionaries, etc.