41–50 of 63 posts
I'm not sure why you would want something like that, unless you really have a lot of existing code C++ business code you want to reuse, or you really love C++.
I really love C++ and I bet with the currently developing standard (C++11, C++14) more people will start loving C++ again :-)
It's a slow morning, so this was good for a chuckle: " Bring the robustness and proven scalability of C++ programming to the Web " Ha. Ha ha. Ha ha ha.
Earlier quoted context omitted.
A bit unrelated, but does anyone know at what comment score one gets to downvote non-constructive comments, or is that what the flagging is for?
Downvoting comes around 500 maybe? Not actually sure. Anyways, lest you think my observation is just a "non-constructive comment": The great thing about the browser is that it is free of a lot of garbage we have to deal with in C++. The antics required to make C++ work in the browser, while laudable, are absurd. If you need cross-platform code, write in Java and avoid native extensions. If you need cross-platform cod…
Earlier quoted context omitted.
Pray tell us, where does C++ need to be? All C++ programmers who I have talked to welcome most things in C++11. It simplifies their C++-code in many ways. As an example: specifying how to capture variables was something they were already dealing with when writing functors manually, now they have a shorthand syntax for it. As for the reason why non-C++ programmers don't like C++, perhaps you are in a better position t…
"Pray tell us, where does C++ need to be?" In my honest opinion, C++ needs to separate low level concerns from high level constructs. How variables are captured in lexical closures is a very low-level concern, but lexical closures are a high-level construct -- by mixing in such low-level details, the overall utility of closures in C++ is reduced. This is made even worse by the fact that the programmer must manually m…
That said, I very much agree with your point--the middle ground between those two modes is cluttered and there lies madness.
The problem with the new features of C++11/14/42 is that they are never going to remove the existing jank of the language; these folks don't seem to understand--or want to understand--that there is never going to be a magical fucking tabula rasa onto which they'll scrawl their code, unless they want to rewrite all the things from scratch (which may actually be a good idea).
That being the case, they're going to get run circles around by people who either stick to existing jank and libraries or use a language with a better set of batteries and more flexibility (Ruby, Python, etc.).
The power and speed of C++ is not worth the difficulty, usually, of finding people who can use it properly.
Earlier quoted context omitted.
"I bet with the currently developing standard (C++11, C++14) more people will start loving C++ again" I doubt it. C++11 takes C++ even further from where it needs to be. Every high-level feature is bogged down by low-level annoyances. Do you capture variables by value or by reference? Do you need a weak pointer to break this cycle, or can you use a weak pointer somewhere else (or maybe just not both with smart pointe…
Pray tell us, where does C++ need to be? All C++ programmers who I have talked to welcome most things in C++11. It simplifies their C++-code in many ways. As an example: specifying how to capture variables was something they were already dealing with when writing functors manually, now they have a shorthand syntax for it. As for the reason why non-C++ programmers don't like C++, perhaps you are in a better position t…
Earlier quoted context omitted.
Is there a book that teaches best practice C++11 without teaching any of the old cruft?
Only the good parts: http://www.amazon.com/C-Programming-Language-2nd-Edition/dp/...
Earlier quoted context omitted.
We have written a detailed post a few months ago comparing duetto to emscripten. We also explain why we think it's not a good idea to use a pre-allocated typed array heap: http://leaningtech.com/duetto/blog/2013/05/28/Comparing-to-a...
Disclaimer: speaking strictly from a game-devs perspective: I remember that post and from a game dev's perspective the pre-allocated-memory vs. reclaimed-through-garbage-collection argument is a bit weak IMHO. Games have predictable memory usage, and game devs are used to see memory as a static, finite resource anyway (since that's how it is on consoles). Grabbing a chunk of memory upfront is quite common for games.…
"Since I do not expect native platforms (i.e. GLibc) to preallocate gigs of memory at application startup to make it faster when dynamic memory is actually used, I do not expect this from a compiler for the JavaScript target either."
So, it would actually make very good sense to have the thing slab allocate a big honking array upfront, and then manage it with brk/sbrk/malloc, and perhaps just add more memory as needed.
Like, if we're going to be writing C/C++ in the browser, why not do this? Why make us deal with the GC at all?
Earlier quoted context omitted.
Done.
I really appreciate it. We are doing our best with the limited capabilities of three persons. Thanks a lot. - Alessandro of Leaningtech
Earlier quoted context omitted.
Pray tell us, where does C++ need to be? All C++ programmers who I have talked to welcome most things in C++11. It simplifies their C++-code in many ways. As an example: specifying how to capture variables was something they were already dealing with when writing functors manually, now they have a shorthand syntax for it. As for the reason why non-C++ programmers don't like C++, perhaps you are in a better position t…
"Pray tell us, where does C++ need to be?" In my honest opinion, C++ needs to separate low level concerns from high level constructs. How variables are captured in lexical closures is a very low-level concern, but lexical closures are a high-level construct -- by mixing in such low-level details, the overall utility of closures in C++ is reduced. This is made even worse by the fact that the programmer must manually m…
To generalize a bit: a lot of the things that might seem odd to non C++-programmers are perfectly natural to C++-programmers.
It's not often that I hear that C++ is too narrow. Being able to add new operators and changing the way the type checker works both seem like niche things and something that is more fit for a research language.