Stephan T. Lavavej: Digging into C++ Technical Report 1 (TR1) | Going Deep

dcuccia

[6:17]: "Mallocate"...I like it. Wink

obrienslalom
(2 2 2 3) *3 | 3 3 3

Where is the end of the video? (maybe he needed another mt dew).

With mention of functional stuff in c++ and boost in this video, I was recently encouraged to check out FC++. I'm sure many of you have ran across this already, but it seems on topic for those of you who haven't. http://www.cc.gatech.edu/~yannis/fc++/boostpaper/fcpp.html

Charles
Welcome Change

obrienslalom wrote:
Where is the end of the video? (maybe he needed another mt dew).

With mention of functional stuff in c++ and boost in this video, I was recently encouraged to check out FC++. I'm sure many of you have ran across this already, but it seems on topic for those of you who haven't. http://www.cc.gatech.edu/~yannis/fc++/boostpaper/fcpp.html

Not sure what happened at the end... Looking into it. Sorry 'bout that.
C

evildictaitor
if( !succeed( try() ) ) { while(true) try(); }

dcuccia wrote:
[6:17]: "Mallocate"...I like it.

That's standard C-speak don't-cha-know.

Oh, and it's an awesome first-half. Let us know when you get the next half up Charles. I'm wanting another hour Tongue Out

PhrostByte

This video has really nothing new to C++ developers, but I think it is a good introduction to those who use other languages and are thinking of dipping their feet into C++.

To be a little cliché here, C++'s biggest strength is also its biggest weakness: the shear power of it all. It typically takes newbies years before they realize the full strength of it and even after that you find yourself learning new useful things all the time. The result of this is that many will take a quick glance at it, label it overly complex, and proudly tell everyone they meet who mentions it how horrible it is.

Rarely will newbies be told of its strong benefits (like RAII), and Stephan very clearly explains a lot of them. Don't get me wrong - C++ is not the be-all-end-all of languages, but it definitely fits in a lot more places than some would give it credit for.

He does go off on a few tangents, but the meat of the interview is good enough to look past that!

Wizarr

Not meaning to downplay how cool these additions sound to c++, but as a c# developer, it seriously begs the question. Is it possible to enable a more declarative syntax to c# that allows you to create a special mode in the managed .net environment where you can bypass the garbage collection? If you can prove to the complier that you will have deterministic destruction via these "shared pointers" that will be enforced by the runtime and reference counted I think that will lessen the burden of garbage collecting to those individual resources and speed up your code and be more memory efficient.

I really like all the portability of MSIL being able to run managed code using mono, and having the JIT compile to either 32-bit or 64-bit on the fly. However, one of my biggest annoyance with the managed environment is that there is currently no way to prove to the compiler or the runtime with verifiable proof that basically says, hey, look at this code, you can see that I am following the rules of this abstraction. Let me setup this declarative optional feature that allows deterministic destruction of these resources and I will not only be more composable but my code will still bound by the .net type safety. At the same time, this will also negate the need to have parallel garbage collection, which by the way, may never be solved without more declarative honesty built into the language.

You have to get this guy talking with the guys from the Haskell camp with Erik Meijer and Gilad Bracha and maybe even talk with Anders Hejlsberg as a mediator discussing the future of dotnet and how to add declarative directives to the language and/or foundation and debate if it can improve both performance and composibility. I think it will be a way to increase the honesty factor of dotnet as well. I really want to see how they can mash this all out.

As a side note, I think it's an interesting idea of creating a complier to determine certain code patterns and convert them automatically to be a more efficient managed reference pointing model while providing all the benefits of a managed language. It could be an option on your compiler optimizer.

evildictaitor
if( !succeed( try() ) ) { while(true) try(); }

Wizarr wrote:

Not meaning to downplay how cool these additions sound to c++, but as a c# developer, it seriously begs the question. Is it possible to enable a more declarative syntax to c# that allows you to create a special mode in the managed .net environment where you can bypass the garbage collection? If you can prove to the complier that you will have deterministic destruction via these "shared pointers" that will be enforced by the runtime and reference counted I think that will lessen the burden of garbage collecting to those individual resources and speed up your code and be more memory efficient.

Sure it's possible, but this problem is being arrived at from different perspectives. In dotNET pretty much everything lives on the heap. When you do a new object() or a new array[] construction, the item is built onto the heap, and the thing you are storing in your variable is a reference to the object. In C++ when you use a non-indirected structure (such as T value or vector<X> values) you are creating the object on the stack. This means that with C++ it is plausible for the compiler to know which objects need to be disposed as you leave scope, whereas in dotNET leaving scope is independent of the objects on the heap.

This being said, deterministic garbage collection is possible for C#, but it is in general more expensive in terms of CPU cycles. Note that you can bypass the GC entirely by using unsafe code.

Wizarr wrote:

As a side note, I think it's an interesting idea of creating a complier to determine certain code patterns and convert them automatically to be a more efficient managed reference pointing model while providing all the benefits of a managed language. It could be an option on your compiler optimizer.

It's not entirely clear what you're getting at here. Please elaborate.

buggy123

The following point, made in this video, needs to be stressed,

deterministic reference counting is a universal resource management technique, whereas garbage collection is useless for anything other than memory. For that reason GC is simply not a replacement for ref counting no matter how much Patrick Dussud congratulates himself.

Cycles can be worked around but total lack of support for managing non memory resources in .net, can't be, you are back in the C world of malloc (new), free (dispose) with absolutely no help from the compiler/runtime.

dcook

garbage collection is useless for anything other than memory.

No. Garbage collection is useless for anything that cannot be released lazily based on reachability. Sometimes, not even memory fits here, but often many things other than memory works just fine.

GC is simply not a replacement for ref counting no matter how much Patrick Dussud congratulates himself.

True, but that doesn't mean it isn't useful. Use the right tool for the job. There are cases where reference counting is better. But in my experience, if a garbage collector is available to you, you'd be an idiot not to take advantage of it, and the garbage collector is the right tool for the job quite often.

Cycles can be worked around but total lack of support for managing non memory resources in .net, can't be, you are back in the C world of malloc (new), free (dispose) with absolutely no help from the compiler/runtime.

Not true. Reference counting can be used if you an appropriate and well-adopted smart pointer library (if you think malloc/free is bad, you should try getting different reference counting libraries to work together correctly). Cycles can be worked around if you are exceedingly clever, carefully meticulous, and have a good weak reference library available (again, have fun with the integration issues). Not to say it is unusable, just pointing out that it isn't as easy as pie (and if you think it is, you haven't done anything sufficiently complex with reference counting). And to make all of this work, you have to think very carefully about how to handle your destructors, make a class for every allocated resource, etc.

Garbage collection isn't without its problems either, but to say there isn't compiler or runtime support is not entirely accurate. The compiler supports it with the lock, using, and try/finally constructs. The runtime supports it with the IDisposable interface. There are still two primary weaknesses (lack of "Disposable" containers, and inability to mark a type as disposable after it has been released).

Performance is a completely separate discussion, and for every example you give me where reference counting wins, I'll give you one where garbage collection wins. Usability, programmer efficiency, and type safety are also areas where there are tradeoffs. There's always a pro and a con.

Just use the right tool for the job. For c++, the arrival of shared_ptr in VC 9.0 is very welcome because it is the right tool for a lot of jobs. But garbage collection is also the right tool for a lot of jobs.
Don't dismiss it just because you don't understand it (and if you're dismissing it, you really don't understand it).