On 4/8/13 5:30 AM, Manu wrote:
> ... so where's your dconf talk then? You can have one of my slots, I'm
> very interested to hear all about it! ;)

Just a note - we may be able to accommodate that schedule change if you all move fast.

Andrei

On 4/8/13 6:04 AM, Dicebot wrote:
> On Monday, 8 April 2013 at 09:31:03 UTC, Manu wrote:
>> ... so where's your dconf talk then? You can have one of my slots, I'm
>> very
>> interested to hear all about it! ;)
>
> Meh, I am a more of "poor student" type and can't really afford even a
> one-way plane ticket from Easter Europe to USA :( Latvia is India branch
> in Europe when it comes to cheap programming workforce. Will be waiting
> for videos from DConf.

Getting a talk approved would have guaranteed transportation expenses covered.

Andrei

On Mon, 08 Apr 2013 16:16:07 +0100, Minas Mina <minas_mina1990@hotmail.co.uk> wrote:

> Sorry, if it wasn't clear. I was talking about C++.
>
> Even if you are not mixing the two, you can still get f*** up.
>
> struct S
> {
> 	S()
> 	{
> 		cout << "S()\n";
> 	}
> };
>
> int main()
> {
> 	S *s = new S(); // constructor is called
> 	
> 	S *s2 = (S*)malloc(sizeof(S)); // constructor is NOT called
> }
>
> So you see an innocent struct type and you decide to use malloc instead of new... If it has a constructor/destructor/... those will not be called. It's just asking for trouble.

This is exactly what I was talking about.. you're expecting memory allocation to perform object construction.. it doesn't, never has, never will.  :p

There is a reason malloc returns void* you know, because it doesn't return an initialised S*, it doesn't return a initialised anything, not even an initialised char*, it just returns a block of memory which you are expected to initialise yourself.

Separate the 2 concepts of memory allocation and object construction/initialisation in your head and and you'll never make this mistake again :)

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Am Mon, 08 Apr 2013 11:57:08 +0100
schrieb "Regan Heath" <regan@netmail.co.nz>:

> On Mon, 08 Apr 2013 09:58:15 +0100, Manu <turkeyman@gmail.com> wrote:
> > I suspect Andrei for one knows this, and that's why the D
> > containers are so... barely existing. The language is not yet ready
> > to say with confidence
> > how they should look.
> 
> That, and before you can design the containers you need a concrete allocator interface design.  Actually, this is likely the same blocker for GC-free D as well.
> 
> D should have a set of global allocator hooks.  If it did, you could easily catch unexpected allocations in tight loops and realtime code.  If it did, GC-free D would be trivial - just replace the default GC based allocator with a malloc/free one, or any other scheme you like.
> 

IIRC stuff like closures and dynamic array appending rely on a gc and it wouldn't be trivial to change that to a normal alloc/free allocator.

A good & simple start would be a -vgc switch, similar to -vtls which prints out all hidden memory allocations. Custom allocators are still important for the library (toString etc). Apart from that I would just stay away from language features which allocate. For example instead of using the concatenate operators I'd just use something like appender (which should then support custom allocators).

08-Apr-2013 19:17, Andrei Alexandrescu пишет:
> On 4/8/13 3:35 AM, Jacob Carlborg wrote:
>> Scott Meyers had a talk about what he called red code/green code. It was
>> supposed to statically enforce that green code cannot call red code.
>> Then what is green code is completely up to you, if it's memory safe,
>> thread safe, GC free or similar.
>>
>> I don't remember the conclusion and what could be implemented like this,
>> but here's the talk:
>>
>> http://www.google.com/url?sa=t&rct=j&q=scott%20meyers%20red%20green%20code&source=web&cd=1&cad=rja&ved=0CCsQtwIwAA&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DJfu9Kc1D-gQ&ei=fXJiUfC3FuSB4gS41IHADQ&usg=AFQjCNGtKwLcr2jNjsC4RJ0_5k8WmAFzTw&bvm=bv.44770516,d.bGE
>>
>
> Article: http://www.artima.com/cppsource/codefeaturesP.html
>
> It's one of Scott's better works but it went underappreciated. I think
> it would be worthwhile looking into how to implement such with D's
> features (notably attributes).
>

I guess that the implementation far behind the beauty of concept.

IRC I once proposed something to the same affect of the red/green code. I was trying to see what kind of general feature could supersede @safe/@trusted/@system, pure and nothrow. The end result of that exercise for me was that there is exactly 2 orthogonal features:

- tags on code with policies that manage the relation of these
	(much like routing policy)
- a tool to define restrict blocks of code to a certain subset of language(here goes nothrow, nogc, pure - various sets of restrictions)

The problem is picking cool syntax, implementation :o) and doing some crazy field testing.

>
> Andrei
>
>


-- 
Dmitry Olshansky

On Monday, 8 April 2013 at 15:37:23 UTC, Andrei Alexandrescu wrote:
> Getting a talk approved would have guaranteed transportation expenses covered.
>
> Andrei

I'll quote that before DConf 2014 ;)

On 2013-04-08 17:29, Andrei Alexandrescu wrote:

> Would be interesting to analyze where the bloat comes from.

I'll see if I can resurrect that code from the D1 grave.

-- 
/Jacob Carlborg

On 2013-04-08 17:17, Andrei Alexandrescu wrote:

> Article: http://www.artima.com/cppsource/codefeaturesP.html
>
> It's one of Scott's better works but it went underappreciated. I think
> it would be worthwhile looking into how to implement such with D's
> features (notably attributes).

Didn't know there was an article.

-- 
/Jacob Carlborg

On 04/08/2013 05:17 PM, Andrei Alexandrescu wrote:
> Article: http://www.artima.com/cppsource/codefeaturesP.html
>
Great I already searched that article for quite a while to support an enhancement request.
http://d.puremagic.com/issues/show_bug.cgi?id=9511

On Mon, 8 Apr 2013 17:57:57 +1000
Manu <turkeyman@gmail.com> wrote:
> 
> But yes, also as you say, the move towards 'casual' games, where the
> performance requirements aren't really critical.
> In 'big games' though, it's still brutally competitive. If you don't
> raise the technology/performance bar, your competition will.
> 

I can't help wondering how big the "big games" world really is anyway, though. I know there's huge sums of money involved, both cost and revenue, and lots of developers, but...well, let me put it this way:

Maybe I'm just projecting my own tastes into this, or maybe this is just because I don't have sales/profits/etc charts for the last 10-20 years to examine, but lately I'm finding it difficult to believe that "AAA" games aren't becoming (or already) a mere niche, much like high-performance sports cars. (Ie, big money, but small market.)

Part of this is because, as I see it, the "big/AAA games" *as they used to exist* up until around the early 2000's don't seem to be around much anymore. The big business development companies have, for the most part, split their non-sports product lines into two main areas:

1. Mobile, Casual IP tie-ins, "Free-2-Play", etc.
2. Interactive movies.

Note that *neither* of those two categories include the sorts of games the "big games/AAA  developers" were commonly making from around late-80's to about 2000 or so. Those sorts of games are now almost exclusively the realm of the indie (Although there are still some exceptions, mainly from Japanese developers - which incidentally is why I still respect the Japanese games industry more than their western counterparts.)

Now, of those two categories currently made by the big name developers, only the second category, "Interactive movies", are actually AAA/big-budget titles.

So my question is, who really plays the current crop of AAA/big-budget titles, and can it really be considered much more than a niche?

First off, they cost $60. Plus $100's for hardware (a standard "email
and MS Word" machine isn't going to cut it). And often either no
or minimal demos. And it typically takes at least half-an-hour to even
reach any core gameplay (Yes, I've timed it). So right there it's
already looking a bit more "muscle car" than "sedan". High
cost-of-entry.

So is it the "core" gamers buying the modern AAA/big-budget titles? Honestly, I'm not seeing it. From what I can tell, these days they're mostly switching over to indie games. As for why that's happening, I figure "Core" gamers are core gamers *because* they play videogames. Modern AAA/big-budget titles, are *not* videogames except in a very loose sense, and core gamers *do* frequently take issue with them. Modern  AAA/big-budget titles are interactive movies, not videogames, because their focus is story, dialog and cinematics, not gameplay. So core gamers have been moving *away* from AAA/big-budget titles and towards indie games.

So is it the "casual" crowd buying the modern AAA/big-budget titles? Definitely not. They're the ones who tend to be intimidated by 3D environments and game controllers and spend their time on Words With Friends, Wii Waggle, PopCap, etc., rarely spend much money on gaming and rarely venture outside iOS, Android and Web.

I know there is and will always be an audience for the modern AAA/big-budget cinematic interactive-movie "games". But I don't see where there's a *large non-niche* audience for them. There's maybe the multiplayer-FPS enthusiasts, but that's a bit of a niche itself. And I don't see a whole lot else. It's the "Italian sports-cars" of videogaming: Just a big-budget niche.