Do you use C++11

Pages: 1... 345678
continuing the offtopic, arrays of runtime bound are really low-class citizens in C++14 - there are no pointers to them, no references to them, no arrays of them, sizeof, typeid, and decltype don't work on them, range for doesn't work, etc. If you need those things, there's std::dynarray

They are really only there because VLAs are such a widespread existing practice, it's not even feasible to create a new C++ compiler without them (clang tried)
Pointer arithmetic is invalid on void pointers
/facepalm. It should be char pointer. Bad attempt at joke, ok.

it's not even feasible to create a new C++ compiler without them
Using -pedantic-errors, so no VLA for me. I use either containers, or smart pointers to dynamically created arrays.

I think C++14 VLA is so limited to make people use containers for anything serious. It is only useful for student assigments and partial C99 compatibility here.
That's just the rationale from the proposal:

n3497 wrote:
There is well-established existing practice with gcc, Clang, and Intel C++ all implementing a similar, if not identical feature. In fact, Douglas Gregor reported in c++std-ext-12553 on 2012-01-30:

Users really seem to want this feature. It's a fairly common extension, and when we tried to ban it out of principle (in Clang), our users reacted *very* strongly.
I think C++14 VLA is so limited to make people use containers for anything serious. It is only useful for student assigments and partial C99 compatibility here.

Agreed, lack of sizeof will be a deal breaker... and also a language breaker: "sometimes sizeof on arrays works, sometimes it doesn't, depending on the kind of array". Gah!
closed account (zb0S216C)
LB wrote:
"It is clear that it iterates over all elements in the container, is it not?"

No. I've said it's obscure so may times already.

LB wrote:
"are you really going to specialize for arrays and convert them to std::array first?"

I always specialise for arrays. Besides, you shouldn't specialise functions :)

LB wrote:
"Can you link me to some of your projects? I want to see how you manage without the standard library."

None of my projects are openly accessible -- I like to work alone. Besides, the standard library is almost never suited to my projects. Therefore, I never incorporate the standard library, so even if my projects were open-source, you wouldn't find many references to the "std" name-space.

Oh, yeah, the standard library isn't a vital organ, so to speak, so I can manage just fine without it.

Wazzak
Last edited on
Framework wrote:
I always specialise for arrays. Besides, you shouldn't specialise functions :)
These two sentences contradict each other.

This is a really bad joke, please stop trolling us.
closed account (zb0S216C)
LB wrote:
"These two sentences contradict each other."

Let me clear things up: I specialise for arrays for classes, but I don't specialise functions. Clear enough for you?

LB wrote:
"This is a really bad joke, please stop trolling us."

Joke? Where's the joke in what I said? Also, where did you get trolling from?

Wazzak
No. I've said it's obscure so may times already.

That's kind of ridiculous. If it's not obvious looking at it the first time what it does, then you only have to look it up once to figure it out.

I would argue that these examples are just as obscure if not more,

x += 2 vs x = x + 2
if (exp) vs if (exp == true)

And your point about knowing exactly how the container is iterated over is a primary reason why range based for is so much more readable. If you see a range based for loop, you immediately know exactly how the iteration goes. But with the standard loop, you have to do a bit of scanning to figure out how it goes. This hurts readability substantially and slows you down quite a bit.
Last edited on
Since when is joking trolling?
Framework wrote:
I specialise for arrays for classes, but I don't specialise functions. Clear enough for you?
1
2
3
4
5
6
7
template<typename T>
void DoSomethingToContainer(T const &t)
{
    //auto start = std::begin(t);
    //auto end = std::end(t);
    //...
}
How do you expect to process arrays without std::begin and std::end? It must handle both arrays and STL containers.

Also, I agree 100% with htirwin.
Last edited on
closed account (zb0S216C)
@htirwin: If someone used a "for( x; y; z )", I would know the exact range of the iteration, and how the container was being iterated. If someone used a RBF, however, I would simply replace it with a more descriptive construct.

@Fredbill30: It's not; he just put "trolling" because he probably thought it was funny.

@LB: Use "std::array".

@chrisname (below): What are you talking about?

Wazzak
Last edited on
Framework wrote:
I always specialise for arrays. Besides, you shouldn't specialise functions

Classes are great, OOP is terrible. The STL is awesome, templates are awful. Polymorphism is uniformity. Monolithism is modularity. War is peace, freedom is slavery, ignorance is strength.
Framework wrote:
@htirwin: If someone used a "for( x; y; z )", I would know the exact range of the iteration, and how the container was being iterated. If someone used a RBF, however, I would simply replace it with a more descriptive construct.
This is what makes me think you're trolling.

Framework wrote:
@Fredbill30: It's not; he just put "trolling" because he probably thought it was funny.
I don't find it funny, I find it incredibly difficult to believe that you're being serious.

Framework wrote:
@LB: Use "std::array".
Implement that function without using std::begin or std::end, and do not specialize it. It must work for both arrays and STL containers.
If someone used a "for( x; y; z )", I would know the exact range of the iteration, and how the container was being iterated. If someone used a RBF, however, I would simply replace it with a more descriptive construct.

But for(x; y; z) is pretty obscure if you think about it. You need to know what the first section is for, the second, and the last, when their actions take place, and in what order. This knowledge only seems clear to you because you've memorized the behavior.
Last edited on
closed account (zb0S216C)
LB wrote:
"This is what makes me think you're trolling."

I'm not trolling, so stop throwing that damn word ["trolling"] around, would you. Also, why do you assume I'm trolling? Is it because I haven't agreed with anything you've said on the subject?

LB wrote:
"I don't find it funny, I find it incredibly difficult to believe that you're being serious."

I am being serious -- if you don't like what I have to say, there are better ways to reply to me other than "you're trolling" like a child.

LB wrote:
"Implement that function without using std::begin or std::end, and do not specialize it. It must work for both arrays and STL containers."

I would use classes, but I'll let you figure that out.

htirwin wrote:
"But for(x; y; z) is pretty obscure if you think about it."

If it was obscure, I would've said so by now. Also, I'll always prefer the "for( x; y; z )" variation due to the level of control I have over it.

Wazzak
Last edited on
If it was obscure, I would've said so by now.

I think the root of the disagreement is that we are speaking too generally. What I should have said was, range based for loops are more readable and clear to me. I look at them and I immediately know exactly what they do.

You should have said, range based for loops confuse me. I look at them and I don't immediately know what they do; or something like that.

That they are or are not more obscure generally is a difficult claim to prove. I think that a poll, or an experiment would be the best bet at coming to a conclusion.

My hunch is that the results would not be consistent with your opinion.
Last edited on
closed account (zb0S216C)
htirwin: That's exactly what it is, "my opinion", so others' views will not be the same as mine.

Wazzak
Another example of usefulness of std::begin:

Let's say you have third-party library which defines a class which works like container, but does not defines .begin() and .end() member functions, however there is way to find beginning and end of it. You have a bunch of functions which iterates over container and do something with it.
You want to make that thirrd-party container to work with your functions.
You have 2 ways to do that:
1) overload all your functions with those taking explicitly that container. (Code duplication)
2) specialize std::begin() and std::end for your class
Last edited on
Framework wrote:
I'm not trolling, so stop throwing that damn word ["trolling"] around, would you. Also, why do you assume I'm trolling? Is it because I haven't agreed with anything you've said on the subject?
No, it's because you're making statements that I expect to be false in all cases - I have no other way of knowing whether people are trolling me or not, sorry for not being omniscient. It has nothing to do with agreeing on anything.

Framework wrote:
I am being serious -- if you don't like what I have to say, there are better ways to reply to me other than "you're trolling" like a child.
Sorry, it's just a very very unbelievable situation. I'll believe you now.

Framework wrote:
I would use classes, but I'll let you figure that out.
A whole class for a simple function, obscuring syntax and adding complexity? If I didn't know you were being serious, I'd use that word you don't like.

Framework wrote:
If it was obscure, I would've said so by now. Also, I'll always prefer the "for( x; y; z )" variation due to the level of control I have over it.
Both varieties give the same level of control, I've even made an example proving it several posts back. To everyone I know, for(x; y; z) is very obscure and for(v : c) is much less obscure. I've been working with the traditional for loops for years now and they still look obscure.

This isn't about being able to tell how it does its job, this is about being able to tell what it does.

for(x; y; z) tells you how it behaves, but you have to think and figure out what it actually does.

for(v : c) tells you what it does, and you don't have to worry about how it behaves because you only need to know what it does.


I'm sorry if you feel insulted or otherwise attacked - I'm just having a very hard time believing that you mean what you're writing.
L B wrote:
[quote=Framework]I'm not trolling, so stop throwing that damn word ["trolling"] around, would you. Also, why do you assume I'm trolling? Is it because I haven't agreed with anything you've said on the subject?
No, it's because you're making statements that I expect to be false in all cases - I have no other way of knowing whether people are trolling me or not, sorry for not being omniscient. It has nothing to do with agreeing on anything.

Framework wrote:
I am being serious -- if you don't like what I have to say, there are better ways to reply to me other than "you're trolling" like a child.
Sorry, it's just a very very unbelievable situation. I'll believe you now.

Framework wrote:
I would use classes, but I'll let you figure that out.
A whole class for a simple function, obscuring syntax and adding complexity? If I didn't know you were being serious, I'd use that word you don't like.

Framework wrote:
If it was obscure, I would've said so by now. Also, I'll always prefer the "for( x; y; z )" variation due to the level of control I have over it.
Both varieties give the same level of control, I've even made an example proving it several posts back. To everyone I know, for(x; y; z) is very obscure and for(v : c) is much less obscure. I've been working with the traditional for loops for years now and they still look obscure.

This isn't about being able to tell how it does its job, this is about being able to tell what it does.

for(x; y; z) tells you how it behaves, but you have to think and figure out what it actually does.

for(v : c) tells you what it does, and you don't have to worry about how it behaves because you only need to know what it does.


I'm sorry if you feel insulted or otherwise attacked - I'm just having a very hard time believing that you mean what you're writing.[/quote]


@MiiNiPaa: perfect example, in this case it is impossible without the use of std::begin and std::end.
Pages: 1... 345678