Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-8081-

[C++] delete considered harmful

Name: Anonymous 2016-01-02 14:13

The unbridled use of the delete statement has as an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress. ... The delete statement as it stands is just too primitive, it is too much an invitation to make a mess of one's program.

Never use delete, use smart pointers, memory pools, stack allocations. Don't break RAII.

Name: AiHasBeenSolved 2016-01-02 14:26

Switch to Perl6.

http://www.infoworld.com/article/3017418/application-development/developers-can-unwrap-perl-6-on-christmas.html

Use perl6 to code Strong AI (artificial intelligence)

http://ai.neocities.org/AiSteps.html

Name: Anonymous 2016-01-02 14:43

C++ considered harmful.

Name: Anonymous 2016-01-02 15:32

>>3

prove it?

Name: Anonymous 2016-01-02 16:10

>>4
no?

Name: Anonymous 2016-01-02 16:24

>>5
why don't you explain to me? Did I do anything wrong?

Name: Anonymous 2016-01-02 16:30

>>6
yes?

Name: Anonymous 2016-01-02 16:35

*grabs dick?*

Name: Anonymous 2016-01-02 16:40

>>7
please tell me my mistake and I fix it.

Name: Anonymous 2016-01-02 16:53

The way to do it in Seeples is to combine new[] with free().

Name: Anonymous 2016-01-02 17:00

>>1
Wow, it's 2016 already and you only now realize this?

Well, what can I say, http://natethesnake.com/

Name: Anonymous 2016-01-02 20:23

>>11
Wow, it's 2016 already and you still are forgetting dubs.

Name: Anonymous 2016-01-02 20:56

>>12

2 - 0 - 1 - 6

2 + 1 = 3
6 / 2 = 3
33 = dubs year

Name: Anonymous 2016-01-02 21:21

>>13
2 / 0 / 1 / 6 = oh shit!

Name: Anonymous 2016-01-02 21:51

2 more years is 2018

20 / 18

put that into your calculator and check ‘em

Name: Anonymous 2016-01-02 21:55

>>13,14
666+666+666+6+6+6
999+9+666+6+333+3

"If you only knew the magnificence of the 3, 6 and 9, then you would have a key to the universe.” - Nikola Tesla

Name: Cudder !cXCudderUE 2016-01-03 2:49

>>1
7/10, but you forgot to mention endofunctors and homozygotic Abelian group theory.

Name: Anonymous 2016-01-03 6:57

>>1
The delete statement as it stands is just too primitive, it is too much an invitation to make a mess of one's program.

EVERYTHING in C and C++ are primitive operations. That's kind of the entire point of those shit languages. You don't deal with those if you want proper high level computational expression.

Name: Anonymous 2016-01-03 8:37

>>18
new and delete ARE high level computational expressions and are also overloadable to run init functions or data generation procedures.
free/malloc/calloc/alloca is the primitive operation. and are just a layer above heap management code.

Name: Anonymous 2016-01-03 8:45

>>19
No! malloc is not primitive, it depends on OS's memory manager.

Name: Anonymous 2016-01-03 10:05

>>19
overloading ≠ abstraction

Name: Anonymous 2016-01-03 14:00

hey

all

!!

look

here

!!

check

out

my

dubs

Name: Anonymous 2016-01-03 17:41

>>9
You became gay

Name: Anonymous 2016-01-04 12:50

>>18
Why are you being serious and making perfect points?

Name: Anonymous 2016-01-04 13:14

>>24
It was a good point except for "shit languages." Only one of {C, C++} is shit.

Name: Anonymous 2016-01-04 14:27

>>25
C xor C++ is shit flame war, go!

My take on it is that if you're going to use portable assembly, use C; if you want higher-level features, use a decent programming language that's both immensely more powerful and astonishingly easier to learn and use (i.e. fewer bugs).

Name: Anonymous 2016-01-04 20:24

>>26
So you mean C++

Name: Anonymous 2016-01-05 10:24

>>27
I see you missed "immensely more powerful" (it's marginally more powerful, especially compared to Lisp or whatever), and "astonishingly easier" (lol @ stupid ass-backwards C++ twattery all day long).

Name: Anonymous 2016-01-06 6:44

>>27
>>28
No, I meant if you want low-level use C; if you want high-level use Lisp or anything else rather than C++ which is kind of pointless.

Name: Anonymous 2016-01-06 7:50

>>28
>>29

Keep deceiving yourselves with "C++ is bad lang !!" meme, enjoy your non-productivity.

Name: Anonymous 2016-01-06 8:04

>>29,30
Please optimize your quotes and stop replying to yourself.

Name: Anonymous 2016-01-06 8:22

>>31
OPTIMIZE MEME XDD

as if you don't prefer LISP over C++. LE OPTIMIZE XDD, LE CHOOSE WORSE, LESS POWERFUL LANGUAGE BUT TALK ABOUT OPTIMIZATION MEME XD

Name: Anonymous 2016-01-06 8:23

optimize these dubs

Name: Anonymous 2016-01-06 9:06

>>26
C xor C++
That would be ++.

Name: Anonymous 2016-01-06 14:49

>>32
The facts on the ground are that LISP is unusable
for writing fast code. If instead of circle-jerking
about its power and expressiveness, the compilers were
optimized to the level of GCC, LISP would be taken
seriously and used for development of performance-critical
software instead of toy programs and scripts.

Name: Anonymous 2016-01-06 15:18

>>35
GC
development of performance-critical
software
Nice one, bro.

Name: Anonymous 2016-01-06 17:07

>>32
I said nothing about Lisp, idiot, I asked you to optimize your quotes.

>>36
Who are you quoting?

Name: Anonymous 2016-01-06 17:12

>>35
McCarthy had carte blanche to develop LISP. Billions of dollars and hundreds of MIT students were poured into the LISP swindle.

compilers were optimized to the level of GCC
GCC is a Free project. If billions of dollars in funding can't make LISP as fast as GCC, that isn't a problem with money, it's a problem with LISP. There are other important things besides being fast, but LISP, despite the MIT brain drain, fails at them too.

Name: Anonymous 2016-01-06 17:45

https://justindomke.wordpress.com/2009/02/23/the-stalin-compiler/

Name: Anonymous 2016-01-06 18:20

>>38
No one cared to optimize LISP, since they would just invent AI and make the AI do it. If you wanted speed, you would use Fortran. Lisp was not invented for that use case.

Name: Anonymous 2016-01-06 18:45

>>38
They did invent the best PL syntax in the world, though.

Name: Anonymous 2016-01-06 19:21

>>41
best in opinion of LISPers. Other programmers have different
preferences and I haven't seen one asking for LISP-like syntax
in any non-lisp language.

Name: Anonymous 2016-01-06 19:48

>>38
GCC is a Free project
and had billions in funding

Name: Anonymous 2016-01-06 20:21

>>40
since they would just invent AI and make the AI do it
They must have thought U.S. Generals are retards. If they believed that nonsense, maybe they are. It's really the citizens who lost though. It's easy to give away money when it's not yours.

Name: Anonymous 2016-01-06 20:50

Lisp machines were built to make Lisp fast.

Then Lisp compilers & standard hardware got even faster than that.

Lisp is as fast as C in microbenchmarks, if full type declarations are included.

Lisp scales complexity way better than C, and massive dynamic programs will be shorter & faster in Lisp than C.

Name: Anonymous 2016-01-06 21:15

>>42
I'm not a Lisper and I have asked for Lisp syntax in other languages. And I'm not the only one, judging from such projects as Dave, Liskell, L++ and Clojure.

Name: Anonymous 2016-01-06 21:18

I mean Dale, not Dave.

Name: Anonymous 2016-01-06 21:22

>>47
Nice try, Dave.

Name: Anonymous 2016-01-06 23:40

>>44
US budgets are a use-it-or-lose-it thing. If they (or any agency) don't use all the money, Congress will not only cut their budget to what they did spend, but tell them to apply the surplus to next year. That makes them pour the excess into really speculative research so they can get a budget increase.

Over all, it was probably worth it. It probably worked put to a few dollars from each taxpayer at most, and a lot of basic research in computer science was done.

Name: Anonymous 2016-01-07 6:13

>>42
Can you explain what is perfect in LISP-syntax that beat every other language? Serious question.

Name: Anonymous 2016-01-07 8:33

>>50
It is literally an AST, which almost all other-language compilers convert your source code into already, to better transform and analyze what the source is doing.

The source is literally a data structure, generally nested lists. Thus it is very regular, and you can read source code as data, or create data and run it as source code. With most other languages, the closest you'll ever get is messily building up opaque strings and passing that to a compiler or eval().

Name: Anonymous 2016-01-07 9:43

>>50
It's homogenous, which makes it easy to parse and to generate programmatically. There are no questions like "is the next element of this form a list or a vector" (I'm looking at you, Clojure). Plus, s-expressions are a joy to edit in a good text editor - go from start of a form to its end or vice versa, copy whole form, paste it, delete it, enclose it in another form. None of that is possible in a non-sexp language.

Another upside of s-exp syntax is that people who use it tend to not produce the Empty Space Abomination of C-like languages:
}
}
}
}
}
}
}
}

Don't know whether it's an intelligence thing or not, but s-exps somehow teach people to use the enlightened ))))))) to finish blocks of code.

Name: Anonymous 2016-01-07 13:06

>>52
It's homogenous

The term is homoiconic, you fuck ing homosexual.

Name: Anonymous 2016-01-07 13:51

>>53
No, dipshit. Homoiconicity is an entirely different concept from syntax homogeneity. For example, Clojure is homoiconic, but its syntax is not homogenous.

Name: Anonymous 2016-01-07 14:10

>>34
that would be undefined behavior

Name: Anonymous 2016-01-07 16:03

>>54
Then neither is Common Lisp homogenous, with all its sharpsign syntax, regarding arrays, structs, repetition, etc. It's not all just 1 homogenous syntax. I can't really think of a homogenous language, maybe one of the esoterics like Brainfuck.

Name: Anonymous 2016-01-07 16:17

>>56
Everything is a s-exp. All s-exps are delimited by (). That's homogenous enough for me, and much more comfortable than worrying about ([{;];};) bullshit.

Name: Anonymous 2016-01-07 16:19

>>57
All s-exps in Clojure are () as well, you clown. Things like parameter lists are not s-exprs, nor are they in Common Lisp. Stop backpedaling and trying to cover up your lack of vocabulary.

Name: Anonymous 2016-01-07 16:25

>>58
You're the clown here, for not knowing elementary Clojure syntax.

Name: Anonymous 2016-01-07 16:30

>>59
Fine, show a Clojure s-expression that isn't bounded with (). It's nearly a fucking tautological equivalence.

Name: Anonymous 2016-01-07 16:38

>>60
I can show you a Clojure form that is not an s-expression bounded with ().

Name: Anonymous 2016-01-08 11:27

>>61
You're the clown here, for not knowing elementary vocabulary.

Name: Anonymous 2016-01-08 11:39

>>62
Which part of

Everything is a s-exp. All s-exps are delimited by ()

didn't you understand? I tried to make it as simple as possible so even a dimwit like you would have a fighting chance to understand it, but you still miscomprehended that as

All s-exps are delimited by ()

How did you manage to graduate elementary school? Or am I overrating your achievements here? What grade are you in?

Name: Anonymous 2016-01-08 11:57

>>57
That's homogenous enough for me
Admission of using your own definitions.

Everything is a s-exp.
No, not everything is a s-exp.

All s-exps are delimited by ()
In contrast to Clojure? No, you doofus, it's the exact same thing in Clojure.

Name: Anonymous 2016-01-08 12:09

>>64
I'm using my own definitions because I'm smart unlike you.

Yes, in Common Lisp every form is a s-exp. The stuff you're wondering about like vectors are actually atoms, which makes them s-exps (although not every s-exp is an atom - is your pea-brain sufficient to understand this point?).

It is obviously not the same in Clojure. For instance the following is correct syntax there:

(let (x 5) (+ x 1))
(let ((x 5)) (+ x 1))

Instead, it forces you to use something that is not a s-exp:

(let [x 5] (+ x 1))

The creators of Clojure call it "extending the code-as-data system beyond parenthesized lists (s-expressions) to vectors and maps". This is obviously unhomogenous: not every form is a s-exp anymore, which is in stark contrast to Common Lisp and Scheme.

To learn more about Clojure, visit http://clojure.org/lisp

Name: Anonymous 2016-01-08 13:47

check
out
muh
dubs

Name: Anonymous 2016-01-08 21:36

>>65
In (let (x 5) (+ x 1)), (x 5) is NOT a s-expression, you dumb fuck! The s-expression is the let form! and +

That's like complaining about literal arrays or structs in Lisp forms: Some parameter to your s-expression happens to not be a cons list. So fucking what?

Let me guess, you throw out all reader macros besides ( in your Lisp rc file because everything else in the Common Lisp standard has the exact fucking issue you're whining about in Clojure? Fuck you, you retard.

Every time I point out how shit your terminology and explanations are, you try to dodge and defend. Just fuck off, already. You have no idea how to communicate, with no fucking ability to discuss concepts because you don't even know the words for them.

I can't even begin to start with how fucking not-even-wrong this bullshit is:
This is obviously unhomogenous: not every form is a s-exp anymore, which is in stark contrast to Common Lisp and Scheme.

You have no clue about the difference between an s-expression , a form, or parameters; or what homogenous means.

Kill yourself, you broken nigger.

Name: Anonymous 2016-01-08 21:54

>>67
Of course (x 5) is an s-expression. You're an idiot if you think it isn't.

From Wikipedia https://en.wikipedia.org/wiki/S-expression:
There are many variants of the S-expression format, supporting a variety different syntaxes for different datatypes. The most widely supported are:

Lists and pairs: (1 () (2 . 3) (4))

I'll repeat that for you several times to help it sink in:

Lists and pairs: (1 () (2 . 3) (4))
(2 . 3)
(2 . 3)
(2 . 3)

Now if you pull your head out of your ass and acknowledge that (x 5) is an s-exp, we will talk. But until you do, this conversation is on hold. Do your homework first.

Name: Anonymous 2016-01-08 22:18

(x 5) is a list, treated as data by the special operator let. It is not evaluated as an expression at all.

Here's a question for you: Since they have shared history, how would the "expression" (x 5) inside the let statement be expressed as an M-expression? Hint: It's all about the first term.

Name: Anonymous 2016-01-08 22:21

>>69
Is it an s-expression or not? I'm not talking about expressions or evaluation or special forms here, only s-expressions. Stop jumping topics.

Name: Anonymous 2016-01-08 22:27

I'll start with >>67.
https://en.wikipedia.org/wiki/S-expression
S-expressions are just syntax. Code and data both, indeed. S-expressions are atoms and lists of S-expressions. A list is delimited by parentheses. That is all there is to it.
The s-expression is the let form!
Not yet. That is a list of three S-expressions; starting with the atom let.
It just so happens that this form represents a valid program (for whatever implementation of Lisp this is that doesn't require double-parenthesised let bindings).
To compare, (let my ass) is also a valid S-expression, but not a valid program.
The let form will be part of the AST. The pipeline involved in parsing a valid Lisp program: characters -> tokens -> S-expressions -> AST.

>>65
Your error is less egregious.
This is obviously unhomogenous: not every form is a s-exp anymore
Much like '(a b c) is syntactic sugar for (quote a b c), so too is [a b c] sugar for (vector a b c). There being values other than plain lists and atoms does not imply un-homoiconicity (which I believe is the term you were looking for).
For example, (let [args (vector x 5)] (eval `(let ,args (+ x 1)))) would be equivalent to (let [x 5] (+ x 1)) (I think; I am tired).
Like quote, unquote, and quasiquote, the square brackets don't remove homoiconicity. They just add convenience.

Name: Anonymous 2016-01-08 22:28

>>71,68
I sure took my time.
The first part of >>71 applies still to >>69.

Name: Anonymous 2016-01-08 22:32

On reflection, it appears >>69 is deliberately misunderstanding the disctinction between the terms ``S-expression'' and ``expression''.
The former is a data structure often used for representing programs; the latter is the result of a computation that exists during the execution of a program.

Name: Anonymous 2016-01-08 22:47

>>71
There being values other than plain lists and atoms does not imply un-homoiconicity (which I believe is the term you were looking for).

Actually I've stated in >>54 that Clojure is homoiconic. Because it is.

the square brackets don't remove homoiconicity. They just add convenience.
To the contrary, they add inconvenience. Which is more convenient, (let (x 5) ...) or (let (vector x 5) ...)? To me it is obvious that the former. Why add a layer of indirection to heavily used core forms' syntax? You cannot car a [a b c], and the menagerie of various bracket types is harder to read too. Clojure syntax is inhomogenous, by which I mean that there is more than 1 way to combine atoms together, and what's worse, the different ways are not equivalent. This makes it much harder to work with that syntax.

Name: Anonymous 2016-01-08 22:54

>>74
Apologies. I did not read the whole thread, and we are on the same page. However, I do not understand what you mean by this:
there is more than 1 way to combine atoms together, and what's worse, the different ways are not equivalent.
They mean different things. [a b c] is no more similar to (a b c) than is (() a (b) c), because they represent different data.
If you traverse a program and come across let, you can vector-ref the next datum with just as much confidence as you could car it in a more conventional Lisp.

Name: Anonymous 2016-01-08 23:00

>>74
I understand your point of homogeneity now. However, (let (x 5) ...) is not homogeneous either: there is absolutely no reason to expect the datum following let to be anything but a list. By extension, the syntactic forms of a well-formed Lisp program are heterogenous. There's just fewer ways you can expect to have to manipulate them than in a Clojure program.

Name: Anonymous 2016-01-08 23:16

One other thing, >>74
To the contrary, they add inconvenience.
I disagree. [a b c] is a vector. It adds no more inconvenience than '(a b c) or, indeed, 4 or "ass".
The inconvenience is, as you say, in the language designers' choice to use a vector for the let bindings. That is a change for the sake of change. The decision to do so, however, is independent of the introduction of vector syntax itself.

Name: Anonymous 2016-01-09 16:48

I don't get it, what is the point of vectors?

Name: Anonymous 2016-01-09 18:12

>>78
Vectors have both magnitude and direction, so yes, they do point.

Name: Anonymous 2016-01-09 20:48

>>78
O(1) length and access. NEXT!

Name: Anonymous 2016-01-11 13:54

>>80
please italify your !s

Name: Anonymous 2016-01-11 21:13

>>80
O(1) length
Any data structure can have O(1) length.

Name: Anonymous 2016-01-11 21:20

>>82
A plain C string passed to your function.
Describe the O(1) way of computing its length:

Name: Anonymous 2016-01-12 0:16

>>83
Passing it with it.

Name: Anonymous 2016-01-12 5:37

>>84
Do you also pass it to strlen?

Name: Anonymous 2016-01-12 7:41

>>86
Why would you call strlen if you already know what it will give you back?

Name: Anonymous 2016-01-12 8:09

>>86
Thats the point: you need to calculate it somewhere, and C strings require O(n) length computation.

Name: Anonymous 2016-01-12 8:23

>>87
Check 'em

Name: Anonymous 2016-01-12 8:30

>>88
I see you've got dbus there

Name: Anonymous 2016-01-12 12:51

>>87
printf("%u\n", sizeof("hello I'm a C string") - 1);

Name: Anonymous 2016-01-12 14:03

>>87
As opposed to C++ strings, which magically know their length before they are even created? IHBT

Name: Anonymous 2016-01-12 14:19

>>90
%zu

Name: Anonymous 2016-01-12 15:22

>>91
http://www.cplusplus.com/reference/string/string/size/

Name: Anonymous 2016-01-12 16:13

I think what >>82 was trying to say is that you can add an O(1) length field to any datastructure, maintaining it in all mutating calls.

However, that means that you must perform all mutations via a single root object per data structure, and any structure sharing will probably ruin it.

Name: Anonymous 2016-01-12 22:13

Just use Java and don't think about that shit.

Name: Anonymous 2016-01-13 0:01

"I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone."
- Bjarne Stroustrup

Name: Anonymous 2016-01-13 2:12

>>95
because the computational cost of calculating the length of ArrayList vs LinkedList isn't the same fucking issue, right?

Name: Anonymous 2016-01-13 2:36

>>87
you need to calculate it somewhere
No, just keep track of it.

Name: Anonymous 2016-01-13 9:09

>>97
Most Java programmers have no clue about the difference and the software they write still works fine.

Name: Anonymous 2016-01-13 9:33

>>9
C programmers could also do the same, but they're too wrapped up their asshole to realize that their efforts are pointless.
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode + RSS -