Board index › Topical Discussion › Computers, Math, Science, and Technology

What is the programming language of the future?

Page 4 of 4 [ 53 posts ]  Go to page Previous  1, 2, 3, 4

Previous topic | Next topic

morslilleole
Veteran
Veteran

User avatar

Joined: 17 Dec 2011
Age: 36
Gender: Male
Posts: 511
Location: Norway

15 Jun 2014, 5:37 pm

beneficii wrote:
For this:

Code:
std::string str = "a string";
container.emplace_back( str );


You'll want to change it to:

Code:
std::string str = "a string";
container.emplace_back( std::move(str) )  /* note the use of std::move, which tells the compiler to do move assignment/construction instead of copy assignment/construction; you can also use push_back here.  str will be left in "an undefined but valid state" (most likely, it would be empty).  emplace and emplace_back/front allow for construction of the object in place within the container without first constructing it at all outside of the container by accepting any number of arguments that work as long as they match up to one set of parameters of the object's constructor.  The arguments are forwarded to the constructor using move semantics.*/


So emplace_back() is only intended to work for inplace construction, not passing existing objects? And std::move() means it will call the move ctr.

I think I tested this out, but it didn't call the move ctr. I might remember it wrongly though...

Also, can I ask about your background? From reading your post about the container you made, you seem to be knowing a whole lot about C++. I assume you work with C++? STL implementer?


_________________
Want to learn to make games? http://headerphile.com/


beneficii
Veteran
Veteran

User avatar

Joined: 10 May 2005
Age: 40
Gender: Female
Posts: 7,245

16 Jun 2014, 10:33 pm

morslilleole wrote:
beneficii wrote:
For this:

Code:
std::string str = "a string";
container.emplace_back( str );


You'll want to change it to:

Code:
std::string str = "a string";
container.emplace_back( std::move(str) )  /* note the use of std::move, which tells the compiler to do move assignment/construction instead of copy assignment/construction; you can also use push_back here.  str will be left in "an undefined but valid state" (most likely, it would be empty).  emplace and emplace_back/front allow for construction of the object in place within the container without first constructing it at all outside of the container by accepting any number of arguments that work as long as they match up to one set of parameters of the object's constructor.  The arguments are forwarded to the constructor using move semantics.*/


So emplace_back() is only intended to work for inplace construction, not passing existing objects? And std::move() means it will call the move ctr.

I think I tested this out, but it didn't call the move ctr. I might remember it wrongly though...

Also, can I ask about your background? From reading your post about the container you made, you seem to be knowing a whole lot about C++. I assume you work with C++? STL implementer?


I am an "advanced" amateur in C++. (My dad says he talked to a coworker about my range_map project and the co-worker said that my ability to tackle that kind of project was the sign of an "advanced" programmer.)

Anyway, std::string should have a move constructor in C++11.


_________________
"You have a responsibility to consider all sides of a problem and a responsibility to make a judgment and a responsibility to care for all involved." --Ian Danskin


eric76
Veteran
Veteran

User avatar

Joined: 31 Aug 2012
Gender: Male
Posts: 10,660
Location: In the heart of the dust bowl

19 Jun 2014, 4:18 am

K_W wrote:
Ultimate programing language... Plain speech.

If someone could create a compiler that used plain speech to formulate the program, it would instantly dominate the computing world.


I think that is rather doubtful. Plain speech is far too ambiguous for use in computers.



Ancalagon
Veteran
Veteran

User avatar

Joined: 25 Dec 2007
Age: 45
Gender: Male
Posts: 2,302

04 Aug 2014, 5:33 pm

mrrhq wrote:
Lambda calculus, what is that?

Later in the same post, you refer to "good-old simple lisp", but lisp is really quite similar to the lambda calculus. They're really nearly the same thing, if you don't count some of the imperative features of lisp that aren't part of (and wouldn't make sense in) the mathematical theory of lambda calculus.

Quote:
In that case, I guess Haskell might be the, er, "language of the future" but I seriously doubt it. Maybe someone can please, please tell me why, even from a marketing standpoint.

I think Haskell is the language of the future in the same way Smalltalk was the language of the future in the 80's. Smalltalk had a huge influence on OOP, but never became popular itself.

Languages are already importing some of the nice features Haskell has (like C++ with lambdas). F# is Microsoft's .Net version of OCaml, which is in many ways closely related to Haskell. Lisp dialects already had a bunch of these features, but not necessarily the focus on immutability/referential transparency. Clojure is a new lisp dialect that's become somewhat popular, and it does have the focus on immutability. Scala is a somewhat popular new language that also takes a lot from functional programming.

Quote:
Like really, do NOT bother with Haskell unless you know what you are doing.

Haskell is not anywhere near as hard as it's made out to be. The problem people have with it is that it's so different from what they're used to, they have to learn a lot more new stuff. The stuff they learn isn't harder than what they're used to, they just aren't used to it (yet).


_________________
"A dead thing can go with the stream, but only a living thing can go against it." --G. K. Chesterton


Coolguy
Blue Jay
Blue Jay

User avatar

Joined: 28 Jun 2014
Age: 38
Gender: Male
Posts: 95

12 Aug 2014, 11:15 am

Project COSA

Everything in this article is highly speculative at his point. However, it will give you an idea of where the computer world MIGHT be headed at some point in the future.