Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Oberon_Command

Member Since 07 May 2003
Offline Last Active Yesterday, 07:47 PM

Posts I've Made

In Topic: Equipment/modules for ships

Yesterday, 10:20 AM

 

hull type is irrelevant.

A ship might have a 50 year old hull barely capable of sub light speeds. 

 

Why wouldn't it be capable? There's no friction in space. All that matters is whether the hull can take the acceleration of the engines firing.


In Topic: Is it pronounced "tomato" or is it pronounced "tomato"?

16 April 2015 - 09:03 PM

It's actually pronounced "Solanum lycopersicum."


In Topic: SpaceX !

16 April 2015 - 12:08 PM

Here is a video of the landing from the surface of the barge:

 

https://vid.me/i6o5


In Topic: Gamedevs presenting language problems to C++ standards working group

16 April 2015 - 11:41 AM

 

--- 3 ---
 
Manual struct layouts. Something like...

struct large_int
{
    uint32_t high @ 0;
    uint32_t low @ 4;
    uint64_t wide @ 0; // overlaps both previous members
};

This would simplify data structures and their reinterpretation, allow to define interface structs (such as event type/data structs) easier.
 
--- 4 ---
 
An "I know what I'm doing" cast: "jiggabyte* ptr = %% &car_object.private_thing;" I realize that auto solves many of those problems (the horrible reinterpret_cast type retyping) but it doesn't solve all. For example, it is still impossible to cast from member function pointers and access private member variables. This is necessary sometimes as it happens to be a better solution than messing with the source. And, of course, an optional compiler warning could be created that prints all occurrences of this cast.
 
--- 5 ---
 
Setters and getters: defining a function with a __set__ or __get__ prefix would create a function that is triggered on a property. __get__ could return either a reference or value, to help avoid the issues that are present in C# and similar languages. Additionally, a prefix could be added for accessing such properties, to make the user acknowledge the presence of a getter (and the performance hit that may come with it).
 

 

3. We already have this with unions.

4. We already have "I know what I'm doing" casts with C-style casts and (I think?) function-style casts.

5. Is this really that useful? How many getters/setters are you even writing? If you really need a getter/setter, why not just write methods with the name of the variable, ie. "X/X" instead of having "GetX()"/"SetX"?

 

On lambdas and std::function:

A lot of developers seem to think that capturing lambdas allocate because std::function can heap-allocate and lambdas are often passed around with std::function. I recently had just that belief challenged in a code review at work. But lambdas and std::function aren't the same thing (the type returned by a lambda isn't a std::function, it's an anonymous type), and lambdas themselves don't heap-allocate. They don't need to since defining the lambda is defining a new type which has a size known at compile time. Using auto and lambda to define a local function, or passing a lambda to a std::algorithm should never allocate as far as I'm aware.

 

If std::function allocating is a problem, could it be useful to allow one to specify the maximum size of a captured lambda object in the std::function instance declaration at compile time? Or even better, have the compiler infer it somehow? 


In Topic: SpaceX !

16 April 2015 - 09:59 AM

They're landing at sea because the FAA won't let them land on land yet. They're hoping that if they stick a few barge landings they'll get permission to land back at the launch site. Also, it takes less fuel to land downrange than to boost back to the launch site because the rocket is already heading quickly out to sea on its usual trajectory. But a landing pad on land doesn't move around, is easier to target than the barge, and it's easier to actually get the stage back in a reusable form.

 

 

 

Is that on fast forward, it seems like the rocket is approaching the landing site too fast.

 

Actually, according to this tweet it's in slow-motion.

 

It's coming down so quickly because the engine has too much thrust to hover with the fuel load it has. The thrust to weight ratio is somewhat above 1 at all throttle settings. There are limitations to how deeply any particular rocket engine can throttle without combustion instability. I believe for the Merlin 1D (which Falcon 9 uses) that limit is about 40% thrust. The Grasshopper test rockets that did some of the VTOL testing for this design were ballasted so they could hover. Falcon 9 cannot hover, it can only "hover-slam."

 

I hear they scrapped the idea of recovering the second stage due to the fact that it would be too difficult to make it survive atmospheric reentry, though.

 

Yes, they could have done it but would have eaten into the payload mass too much.


PARTNERS