Im learning java, do they have a forum as simple and easy going as this one

[JLBorges]

> I didn't know about std::copy_if

std::copy_if() came with C++11; it was inadvertently left out of C++98.
Funnily enough, C++98 did have std::replace_copy_if()


> I can use .NET libraries with C++/CLI.

Yeah, that is yet another thing that .NET got right and Java didn't - seamless interoperability with native code.

[LB]

There's always JNA, bu really JNI should have had better support for when you couldn't control the implementation to Javafy the function calls with JNIEnv pointers and such.

[devonrevenge]

Right just to back up what was saying about other forums take a peek at my java question at stack over flow

http://stackoverflow.com/questions/14742100/how-do-i-dynamically-add-an-object-to-an-arraylist-of-objects

It was closed on a very obscure technicality that it wasnt a real question!

theres a title at the top of the page and it says "HOW DO I DYNAMICALLY ADD AN OBJECT TO AN ARRAYLIST OF OBJECTS?"

Technically that's not a question some how :/ some help would be nice too, i had this problem at dream in code, everything i needed help with i could never ask in the right way, its problem solving gone wrong, they think; "hrm n00bs are messy i need to find a latteral way to deal with his problems, i know, i will make him go away"

I will become powerful and destroy all snarks and spitefull-pedants

[LB]

You ask a question in the title, giving the impression that it is actually a real question, but then in your question you just post your code and explain your problem, making your question fake. The cake you offered was a lie.

You could just have posted that in the lounge here with a [Java] prefix in the title.

[chrisname]

StackOverflow is probably not the right place for beginners, from what I've seen it's more for intermediate to advanced programmers. This place is a lot more mixed.

[devonrevenge]

kay will post it here, lets test what everyone has been saying :)

[BHX]

chrisname wrote:

StackOverflow is probably not the right place for beginners, from what I've seen it's more for intermediate to advanced programmers. This place is a lot more mixed.

Not really the right place for anyone apparently, you have to be super detailed on your question as it seems even the slightest vague spot and they close it saying it is too general. I quit bothering with that site because of that as almost all my posts got closed saying it was too vague heh.

[Cubbi]

It is hard to ask a good question that hasn't been asked before. I asked only 12 in my 3 years there :)

[BHX]

Cubbi wrote:

It is hard to ask a good question that hasn't been asked before. I asked only 12 in my 3 years there :)

Well of course! You don't need to ask many questions when you know everything ;).

[Cubbi]

But SO gives special badges for good questions.

[naraku9333]

Well of course! You don't need to ask many questions when you know everything ;).

No, you don't need to ask many questions when someone else already has. SO has a huge volume of users with millions of asked and answered questions, and considering SO's size I don't blame them for not having patience for duplicate and vague threads.. It is an incredible resource and usually if I am searching for an answer to a programming issue the most relevant answers are on SO.

[BHX]

Well they don't close duplicate threads that much, they just close it if any part of the question has an 'open ended' part as they deem that not specific enough. I had an account before I made a new one (think it was vgdesigner or something to that effect) and I asked a specific C++ question, but followed it with a question along the lines of recommended languages and it was closed because the language part was open ended and vague. I have a new account, but only asked two questions as I get better responses here without fear of wondering if it is too vague or (according to you) getting closed for duplicate questions.

[rapidcoder]

C# LINQ version is nice from the user's perspective, but the downside of it is it complicates the syntax. From the language designer perspective it is a hack, not a properly engineered solution, and good they didn't add it into Java. Java 8 and Scala achieve exactly the same without need to resort to a builtin DSL, just by reusing the core concepts like lambdas and iterables.

C++ version is ridiculously verbose (lots of boilerplate) and ugly. My wife who is not a programmer could understand the C# LINQ version, Java version or Scala version in almost no time; while after looking at that C++ code, she said "WTF? Is it Perl?".

std::vector< std::reference_wrapper<Customer> > customerQuery ;
std::copy_if( customers.begin(), customers.end(), std::back_inserter(customerQuery),
                [] ( const Customer& c ) { return c.City == "London" ; } ) ;

for( const auto& c : customerQuery )
    std::cout << c.get().LastName << ", " << c.get().FirstName << '\n' ;

Java version:

Iterable<Customer> customerQuery = customers.parallel().filter(c -> c.city.equals("London"))

for (Customer c : customerQuery)
    System.out.println(c.lastName + ", " + c.firstName);

Scala version:

val customerQuery = customers.par.withFilter(_.city == "London");

for (c <- customerQuery)
  println(c.lastName + ", " + c.firstName);

As a bonus, my code is parallel. Now I'm especially interested in an equivalent parallel C++ solution.

BTW: I looked at your C++ code closer again and besides being obviously longer and uglier (ok, I know it is a matter of opinion) there are several flaws that make it not-equivalent to the C# code:

1. If the original collection changes, the customerQuery results won't.
2. It requires more memory than Java, C# and Scala versions.
3. Picking just a first few results from the query requires filtering the whole collection.

So it is not only ugly, but also inefficient, both CPU-wise and memory-wise.

--------------

As for the Java and C# generics, I'm really curiosus, where C# generics are more expressive than Java's.

[JLBorges]

> C++ version is ridiculously verbose

It is not difficult to create any DSEL - repeat any DSEL - with LINQ-like inline syntax of ones choice using C++. However, one needs to know a reasonable amount of C++ to be able to realize that.


> My wife who is not a programmer could understand the C# LINQ version

C++ is designed to be used by programmers with a ceryain degree of skill. Your wife may also find it easier to chop vegetables with a kitchen knife rather than with a scalpel.

Needless to say, the fault lies entirely with the scalpel. "Why, oh why, doesn't everyone use a knife like our lovely kitchen knife for everything?"



> If the original collection changes, the customerQuery results won't

No, the results refer to the original elements. However, one needs to know a little bit of C++ to be able to realize that.



> It requires more memory than Java, C# and Scala versions.

It requires less memory than the Java, C# or Scala versions. However, one needs to know a little bit of C++ to be able to realize that.



> 3. Picking just a first few results from the query requires filtering the whole collection.

If one needed to pick a few results, the query would have been different. However, one needs to know a little bit of C++ to be able to realize that.



> but also inefficient, both CPU-wise and memory-wise.

It is more efficient both CPU-wise and memory-wise; an order of magnitude more efficient CPU-wise and, about twice as more efficient memory-wise. However, one needs to know a little bit of C++ to be able to realize that.

[LB]

rapidcoder wrote:

Java version:

Iterable<Customer> customerQuery = customers.parallel().filter(c -> c.city.equals("London"))

for (Customer c : customerQuery)
    System.out.println(c.lastName + ", " + c.firstName);

What extension to Java adds that -> operator and makes it optional to use semicolons? Is that lambda syntax proposed for Java 8?

rapidcoder wrote:

1. If the original collection changes, the customerQuery results won't.

Thank god for that. Having that lambda run unexpectedly is a scary idea.

[rapidcoder]

It is not *proposed*. It is already accepted by the committee and *implemented* in JVM from Oracle, although not officially released yet. But you can grab a feature complete EAP from the Oracle site. It is mostly bug-fixing now. So this is more complete than C++11 , with still no feature-complete implementation.

Thank god for that. Having that lambda run unexpectedly is a scary idea.

Having *that* lambda is. Because *that* C++ lambda is not really a lambda but a monad. Moreover, it is not even a function. But in all the other non C++ examples it is a function and then there is nothing scary about it.

No, the results refer to the original elements. However, one needs to know a little bit of C++ to be able to realize that.

No, it is *you* who didn't get the LINQ example. LINQ query is lazy, yours is eager. Results refer to the original elements... so what? That is completely unrelated. I add a new element to the original collection and... *your code does not work*.

It requires less memory than the Java, C# or Scala versions. However, one needs to know a little bit of C++ to be able to realize that.

Again you are wrong. LINQ, Scala and Java solutions are O(1) memory-wise. Yours is O(n). QWhich means yours is worse. And it is already worse for a very small values of n.

If one needed to pick a few results, the query would have been different. However, one needs to know a little bit of C++ to be able to realize that.

Even if I need to pick them all, yours would be still much slower. A few times slower on single core, and an order or two of magnitude slower if I ran my Scala code on a GPU through ScalaCL. However one needs to know something more about algorithms, structures, memory management and programming in general to realize that (knowing only one limited language, particularly C++ which does only imperative programming right, is not enough).

[LB]

rapidcoder wrote:

I add a new element to the original collection and... *your code does not work*.

So, his code works with 80 elements but not 81?

rapidcoder wrote:

Again you are wrong. LINQ, Scala and Java solutions are O(1) memory-wise. Yours is O(n). Which means yours is worse. And it is already worse for a very small values of n.

O(1) memory usage has no relation to the actual memory being used.

rapidcoder wrote:

Even if I need to pick them all, yours would be still much slower.

I would like to see your Scala interpreter that can optimize the code better than an Intel compiler can optimize the C++.

We're tired of you making up facts to make C++ sound inefficient and useless just because you don't like its syntax and usage. I can't imagine how you think your code samples run faster than the C++, the overhead of tracking when new elements are added must be insane, let alone the base language overhead. Does Scala compile to machine code or byte code? Don't you dare say the bytecode is faster.

I'll redact my statements if you can prove without a doubt that in a majority of common cases the Scala and Java versions are faster than the C++ version.

[rapidcoder]

So, his code works with 80 elements but not 81?

His "customerQuery" will return 80 elements even if the original collection already contains 81. So this is not a query at all. He just created a new collection in a fancy way. This is not what the original LINQ example did.

O(1) memory usage has no relation to the actual memory being used.

Oh, yeah. So Donald Knuth was wrong when he created his O() notation, because it... doesn't really matter at all, right?

Anyway, the Java/Scala solution requires just additional few bytes to store and process the query (mostly to hold the predicate), regardless of the size of the collection. C++ code requires at least 8 * number of the elements in the collection. And what if the collection was infinite?

I would like to see your Scala interpreter that can optimize the code better than an Intel compiler can optimize the C++.

First, it is not an interpreter. It is an optimizing compiler. Second, all the low-level optimizations don't count here, because the obvious bottleneck for the C++ code will be reallocating the result vector. And on-heap memory reallocation in C++ is slower than in Java. Some time ago I posted a benchmark where Java slightly outperformed C++ in appending to a vector and no-one on this forum could beat it. So how *not-appending* to a vector can be slower than appending to it?

As for the optimizations, right, the Intel compiler will be probably slightly better in many cases. Sometimes 1%, sometimes 50%. But this advantage can be easily destroyed by algorithmically inefficient code like the one posted here.

[LB]

rapdicoder wrote:

His "customerQuery" will return 80 elements even if the original collection already contains 81. So this is not a query at all. He just created a new collection in a fancy way. This is not what the original LINQ example did.

So, this is an issue of it not replicating the behavior of the original. I apologize. I don't like the behavior of the original, though.

rapidcoder wrote:

Oh, yeah. So Donald Knuth was wrong when he created his O() notation, because it... doesn't really matter at all, right?

It doesn't matter because you're using it to compare different languages. O(1) in Java is different from O(1) in C++, or my goose is a duck.

rapidcoder wrote:

Anyway, the Java/Scala solution requires just additional few bytes to store and process the query (mostly to hold the predicate), regardless of the size of the collection. C++ code requires at least 8 * number of the elements in the collection. And what if the collection was infinite?

Which implementations are we talking about here? Also, I'm not sure about your infinite size thing - does this have to do with performance analysis?

rapidcoder wrote:

the obvious bottleneck for the C++ code will be reallocating the result vector

Why would it need to be reallocated? Are you seriously going to try an account for concurrent code and want to have your results up to date at all times? What if you have to perform two separate operations and they can't be done at the same time for each object? Does the second operation affect more/less objects than the first?

rapidcoder wrote:

on-heap memory reallocation in C++ is slower than in Java

o_o this...I could believe, but I want some proof first. Though I honestly don't see why unless Java interfaces directly with the ram and uses a more efficient technique of memory allocation.

rapidcoder wrote:

Some time ago I posted a benchmark where Java slightly outperformed C++ in appending to a vector

So you're comparing the standard libraries now. Excellent.

rapidcoder wrote:

So how *not-appending* to a vector can be slower than appending to it?

How does the Scala code intrnally track when a new element is added or an element is removed? Answer this and I could be wrong, because I can only guess at the implementation.

[rapidcoder]

It doesn't matter because you're using it to compare different languages. O(1) in Java is different from O(1) in C++, or my goose is a duck

And Knuth invented this notation especially *because* of this problem.
To objectively compare algorithms performance despite different constant factors.

* Pointer in C++ takes 8B (raw) or 16B-24B (shared) and in Java 4B (compressed) or 8B (uncompressed).
* A dynamically allocated object in C++ takes usually 8B-24B overhead (memory allocator bookkeeping + eventual vtable ptr), in Java it is always 16B overhead (vtable ptr + lock/GC record).
* C++ is better at object inlining, because you can manually inline objects - a huge win for arrays of small objects like Point2D. In some extreme cases this leads to saving 2/3 of memory that would Java use.
* C++ can waste quite a lot of memory on fragmentation, Java does not.
* Java can waste quite a lot of memory if you allow for GC being too "lazy", C++ does not.

Anyway, summing it all up, the differences are not *that* huge as you may think. I just checked memory usage of my IDE and guess what... more than 2/3 of memory usage is code. Heap is only 170MB, and I have a several MLOC project open.

How does the Scala code intrnally track when a new element is added or an element is removed? Answer this and I could be wrong, because I can only guess at the implementation.

Ah, this is the problem. So you don't understand what that LINQ / Java / Scala code is doing. No, it doesn't track the original collection. It creates a *lazy filtered view* of the collection. Which means, whenever you iterate it, it applies the filter to the original collection. Therefore no data need ever be copied. The operations filter() in Java or withFilter() in Scala run in O(1) time and memory. That's why it can be called "query". Lazy computation is a very important part of CS. I guess C++ STL designers aren't there yet (they were too busy adding threads and atomics which have been in Java for 10 years or so).

So you're comparing the standard libraries now. Excellent.

Nope. realloc / malloc is slow in C++ not because it is poorly implemented, but because it can't be implemented better in this memory management model. Simply Java model is faster for allocating lots of short-lived objects, e.g. like reallocating vectors, when you don't know the target size. C++ model is better for huge, long lived objects, and better for latency. In Java I can use both, where appropriate.

Whatever, in this particular case Java/Scala/C# do not reallocate any vectors. There are no dynamic allocations happening while the query is running.

Though I honestly don't see why unless Java interfaces directly with the ram and uses a more efficient technique of memory allocation.

It does both.
The memory allocation technique in Java can be illustrated by this pseudocode:

void* malloc(int size)
{
  void* ptr = current_ptr;
  current_ptr += size;
  return ptr;
}

This is comparable to a speed of a hand-coded slab allocator in C++, ye much faster than generic new (underlying std vectors and strings).