[Boards: 3 / a / aco / adv / an / asp / b / bant / biz / c / can / cgl / ck / cm / co / cock / d / diy / e / fa / fap / fit / fitlit / g / gd / gif / h / hc / his / hm / hr / i / ic / int / jp / k / lgbt / lit / m / mlp / mlpol / mo / mtv / mu / n / news / o / out / outsoc / p / po / pol / qa / qst / r / r9k / s / s4s / sci / soc / sp / spa / t / tg / toy / trash / trv / tv / u / v / vg / vint / vip / vp / vr / w / wg / wsg / wsr / x / y ] [Search | Free Show | Home]

/dpt/ - Daily Programming Thread

This is a blue board which means that it's for everybody (Safe For Work content only). If you see any adult content, please report it.

Thread replies: 323
Thread images: 25

File: 1490130153557.jpg (182KB, 764x650px) Image search: [Google]
1490130153557.jpg
182KB, 764x650px
What are you working on, /g/?

Old thread: >>59521230
>>
>>59529672
Why does the editor portion of Visual Studio suck so much? All these years they've been at it and yet InteliJ still manages to do much better than them at helping the programmer.
>>
>>59529691
emacs - ultimate IDE.
>>
File: kill all anime.jpg (188KB, 1075x1069px) Image search: [Google]
kill all anime.jpg
188KB, 1075x1069px
Thank you for posting an anime pic.
>>
>>59529494
>It's this autist who thinks smart-pointers with RC is a Garbage Collector again
I've already explained it to you, Reference Counting is a method of garbage collection, but it isn't a Garbage Collector. Every complex C program has RC in some form or another, Linux kernel including - https://lwn.net/Articles/336224/ , the only difference being smart pointers automatize all the busywork, while C programmers have to do refcounting manually. None of the disadvantages of Garbage Collector apply to RC as a method, therefore "It has RC, meaning it has GC, meaning it's basically Java" is a stupid point to make.
>>
>>59529691
Have you considered using CLion?
>>
Reposting from /sqt/ because all things considered this might more be a /dpt/ question.

I've been trying to scoop up words that look like they're written in Japanese romaji in a DB column (only one word inside), using the following regexp I built up:

/^((c?ch|s?sh)?a|(c?ch|s?sh)?i|(c?ch|s?sh)?u|(c?ch|s?sh)?e|(c?ch|s?sh)?o|k?(ka|ki|ku|ke|ko)|g?(ga|gi|gu|ge|go)|t?(ta|tsu|te|to)|d?da|d?dzi|d?dzu|d?(de|do)|s?(sa|shi|su|se|so)|z?(za|zu|ze|zo)|ja|ji|ju|jo|n?(na|ni|nu|ne|no)|h?(ha|hi|hu|he|ho)|f?(fa|fi|fu|fe|fo)|b?(ba|bi|bu|be|bo)|(m|p)?(pa|pi|pu|pe|po)|m?(ma|mi|mu|me|mo)|(k|g|s|j|n|h|b|p|m|r)?ya|(k|g|s|j|n|h|b|p|m|r)?yu|(k|g|s|j|n|h|b|p|m|r)?yo|r?(ra|ri|ru|re|ro)|wa|wo|n)+$/


Is there a way to simplify that regexp while not creating more false positives?
>>
>>59529724
Rust has reference counted smart pointers but you're really supposed to avoid using them. Personally I've never found a need.
>>
>>59529736
yea, use a database of japanese words instead
>>
File: 1480812177365.png (207KB, 450x416px) Image search: [Google]
1480812177365.png
207KB, 450x416px
>>59529736
>regex
>>
File: bench.png (216KB, 1712x944px) Image search: [Google]
bench.png
216KB, 1712x944px
>
>>
>>59529724
any code that does garbage collection is a garbage collector, even if it isn't the main way to handle memory in the runtime

but i'll admit that other guy is pretty dumb
>>
>>59529772
I hate how this graph is designed.
>>
>>59529736
I think you're missing the following:
シェ|she

ジェ|je

ティ|ti
トゥ|tu

ディ|di
ドゥ|du

チェ|che

ファ|fa
フィ|fi
フェ|fe
フォ|fo

ウィ|wi
ウェ|we
ウォ|wo

ヴァ|va
ヴィ|vi
ヴ|vu
ヴェ|ve
ヴォ|vo
>>
>>59529772
haskell confirmed USELESS
>>
>>59529808
The f series is there, but for now I'd like to concentrate on purely Japanese words (that's why I omitted some of them)
>>
>>59529813
>Trusting a chart where C# is faster than OCaml
>>
writing an i/o-free language
>>
>>59529837
Why is that so hard to believe?
>>
>>59529772
Source?
>>
>>59529833
k
I don't think you could reduce the size of your regex any further. The only thing I can think of is parsing words per mora to test if they're in romanji.
>>
>>59529877
http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html
>>
I've been following this for a while now
https://github.com/sparky4/16
it looks extremely chaotic and I have no idea what's going on
what's his end game, /g/?
>>
>>59529871
Because I did tests a lot with those two languages and that's totally false.
>>
File: ti3wbSg.jpg (37KB, 512x512px) Image search: [Google]
ti3wbSg.jpg
37KB, 512x512px
>>59529889
>32.2% assembly
>>
>>59529886
Thanks Anon, I just wanted to know if it was possible.
>>
Any employed Python programmers here? That's employed AS a Python programmer.

Hello?
>>
>>59529966
I hope not, or we'd have to get the bats out again
>>
>>59529736
jesus there must be a simpler way to express that
does this work?
([khszytdgnmjraeiou|ch|shi][aeiou]*)+\w
>>
>>59529672
clojure or (((racket)))?
>>
fucking gdb keeps setting a breakpoint in the middle of operator new() for no apparent reason
and now my debugger back end keeps recursing and doing triple-faults
>>
>>59529974
Unfortunately it's matching non-Japanese words as well.

I had something that looked like what you posted but it also brought up non-japanese words:
/^((a|i|u|e|o)?(k|s|sh|t|n|h|b|p|m|r|g|d|z|b|ts|dz|ch|j|y)+(ya|yu|yo)?(a|i|u|e|o|n)+)+/
>>
>>59530036
Clojure if you want to do something useful, racket if you're an academic.
>>
>>59529925
it looks like he's pulling in all sorts of files from other projects which contain asm. his own code is just C, it seems
>>
>>59530043
English can be excluded because is has two different consonants adjacent to each other, none of which is n/m. Lightning as wewll.

Limited can be excluded because it ends with a consonant that isn't n/m.

Don't know how to translate that to regex though
>>
>>59529772
Rust faster than C++ when? Can't wait any longer.
>tfw literally costless abstractions
>>
>>59530225
It already is faster. You should ask when it's going to top C. The RustC is doing a pretty fucking amazing job, exceeding ~40 year old C++'s performance.
>>
File: 1478415807930.jpg (67KB, 800x557px) Image search: [Google]
1478415807930.jpg
67KB, 800x557px
>>59530259
>no classes
Why do I need it then?
>>
>>59530295
Not being OOP is good thing.
>>
File: hqdefault.jpg (52KB, 480x360px) Image search: [Google]
hqdefault.jpg
52KB, 480x360px
How do you make a Spring RESTFul Web Services CRUD ?
I have a problem with my javascript method that's supposed to send an object (that I fucking catched from my database in the first place so there shouldn't be a problem in the first place) but the expected delete method's telling me that the object received has not the right type.
Here's the code
deleteTask: function(value){
console.log(value);
axios.delete('/deleteTask',{
task: value
}
).then(function (response) {
console.log(value);
console.log(response);
});
}

The javascript method

@RequestMapping(value = "/deleteTask", method = RequestMethod.DELETE)
public void deleteTask(@RequestBody Task task){
tasksRepository.deleteTask(task);
}

The method in the controller

@Query("delete from Task t where t = :task")
void deleteTask(@Param("task") Task task);

The method that's supposed to delete it in the database.
I'm pretty sure it's a JSON problem, the object is sent but the method doesn't catch it because of it's structure but I don't know how to fix that and don't understant it since earlier I made an http get method in the other way (getting objects from the db and putting them in a javascript method) and it works.

This shit is driving me crazy.
>>
>>59530295
>classes
Eww
>>
>>59529736
Use language identification.
>>
File: --933.jpg (718KB, 700x933px) Image search: [Google]
--933.jpg
718KB, 700x933px
>>59530303
>>59530307
Zero-cost OOP when?
>>
>>59529889
Just ask him, looks like an interesting project
>>
>>59530347
Never. OOP is a cost itself.
>>
File: 15698156.png (365KB, 720x527px) Image search: [Google]
15698156.png
365KB, 720x527px
>>59529772
>Java faster than GO
Now this is a true defeat. Gotards were thinking they could compete with Rust lel
>>
>>59530387
What?
>>
>>59530387
On that benchmark, Java is literally the fastest GC'ed language.

It's still a shit language.
>>
>>59530306
Pretty sure you're sending an object with one field, "task", instead of sending an object with the fields expected by Task.
>>
I'm not trying to bash Rust, but the language syntax is fucking autistic.

'&
'label: foreach _; 0...10 {break 'label}/code]
let con = vec![1, 9,0];
for (index, value) in (5..10).enumerate()

Apart from that I got no issues. I think Rust is a good purist's language. If you cannot adopt to anything but C style syntax you'll have a hard time getting used to it.
I can trade some performance for nice syntax for developer friendliness.
t. D fag
>>
>>59530295
Does Rust have prototypes then?
>>
>>59530504
>foreach
for*
>>
>>59530387
Turns out if you spend 20 years perfecting JIT and GC you'll actually get a reasonable good product.
>>
>>59530517
Rust has traits, something similar to haskell typeclasses.
>>
>>59530504
Rust
istrash
>>
>>59530504
What don't you like in the examples exactly? The only unusual thing is using ' as a prefix for labels and ! for macros, but so does D IIRC.
I mean, if you really want to complain about Rust's syntax you should use some generic stuff with different lifetimes and trait bounds.
>>
>>59530366
OOP did nothing wrong.
>>
I'm attempting to implement a queue using a dynamically resizing array.

However, the issue I'm having is how to maintain the order of operations within the queue when it's dynamically resized. Resizing occurs when you attempt to insert into the queue when it's full.

e.g.
// the queue storage array
[1, 2, 3, 4]

// remove two oldest values from array
[null, null, 3, 4]

// insert two new values into array
[5, 6, 3, 4]

// insert new value, causing array to double
[5, 6, 3, 4, 7, null, null, null]

// remove the next two oldest values from array
[5, 6, null, null, 7, null, null, null]

// the next remove operation will remove 7
// it needs to remove 5 to truly behave like a queue


How do I solve this issue? I'm sure this is a fundamental part of dealing with an array based queue, I just don't know what to do to deal with it.
>>
>>59530746
>queue
>array

stop
>>
>>59530746
> using a dynamically resizing array
Why? You can just use pointers to the next and previous cells.
>>
>>59530769
lmao this scrub doesn't like cache efficiency

step it up
>>
>>59530774
I am, I have a reference to the most recently added and the oldest indexes within the array.

The issue is that I increment these references by one when a value is enqueued or dequeued. When the array has doubled as part of dynamic resize, this no longer works.
>>
Hey /dpt/ what is your opinion about those two ways of declaring a constant? What are pros and cons?

const int &x (42);

const int x (42);
>>
>>59530778
My algorithms are so blazingly fast they don't need cache.
>>
>>59530826
I'm more of a defconstant guy myself.
>>
>>59530746
If you are looking to make a performant list, just use delete (if your using a vector in c++). It's still more efficient (due to cache usage) due to how <vector> is contiguous in memory vs. <list>. If you google vector vs list mr stroustrup gave a talk about it.
>>
>>59530827
try working with data sets billions of items in size that have to be processed millions of times per second
>>
>>59530826
C++ initialisation syntax is so fucking stupid.
>>
>>59530799
Show the code.
>>
>>59530899
That's not the question.
>>
>>59530827
Damn, son
>>
>>59530799
>When the array has doubled as part of dynamic resize, this no longer works.
Why not?
>>
>>59530746
put 5 and 6 in at the right of 3 and 4 obviously
you need to make sure to shrink the array intermittently as well
>>
>>59530921
Random guess: When it doubles the array it is actually a new array (which means it will be somewhere else in memory)
>>
>>59530826
both are stupid, the first one especially since it's a reference to a hardcoded number. that makes no sense at all.

const int x { 42 };
>>
>>59530974
Just use indices, at least when transferring to the new array.
>>
>>59530860
I can always count on /g/ to autistically give serious replies to shitposts and jokes.
>>
>>59530826
do these do the same thing?
>>
>>59530826
I've seen grad students writing
void my_function (... const int& argument ...) {

Kill me famalam.
>>
>>59530981
>const int x { 42 };
that ain't c++98
>>
>>59530997
No exceptions?
>>
>>59529672
C++
confirmedfortrash.
>>
>>59531041

C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.

In other words: the choice of C is the only sane choice. I know Miles
Bader jokingly said "to piss you off", but it's actually true. I've come
to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really *would* prefer to piss
off, so that he doesn't come and screw up any project I'm involved with.

-- Linus T.
>>
>>59531061
Linus is sort of an idiot.
>>
>>59531090
Say the code monkey who loves C++.
>>
>>59531061
I guess he's grown up since, because his hobby project https://github.com/Subsurface-divelog/subsurface is 50.7% C++.
>>
>>59531024
Just use const int x = 42. Or #define x ((int) 42), that leaves less opportunity for undefined behavior, not to mention you want your constants to be inlined anyway.
>>
>>59531171
He also has less than 10% of the total commits on the project
>>
File: 1490042914320.png (594KB, 788x1024px) Image search: [Google]
1490042914320.png
594KB, 788x1024px
>>59531101
>code monkey
>C++
Be careful there.
If someone geniunely loves C++, keep in mind that he made his brain soak in C++ during 1 years.
>>
>>59531216
What's so bad about stacks?
>>
>>59531216
>10 years
fix
>>
>>59531211
Well good compilers would inline it even if you don't use const.
>>
>>59531101
Read what he wrote again and tell me he's not an idiot. And no, I've never even touched C++.
>>
>>59531237
No is not an idiot. I totally agree with him.
>>
>>59531237
>I've never even touched C++.
Ho, ignorance is an opinion now.
>>
>>59530043
well fuck ill learn regex someday
>>
>>59531211
Unfortunately C is borked and const ints apparently aren't actually constants when declared in toplevel.
Why the hell is it like this, it's fucking retarded.
>>
>>59531255
>"C++ is bad because people who program in C++ are idiots"
>"People who program in C++ are idiots because C++ is bad"
>is now programing in C++
yeah, he's an idiot.
>>
>>59531299
That's not what he said.
>>
In C:
char *function(char const *s) {
return s;
}


Gives the warning:
return discards 'const' qualifier from pointer target type


Why is this a problem? Once the function is finished, why would it matter that the parameter being returned is no longer constant, I only want it to be constant for the duration of that specific function.
>>
>>59531314
because of mismatch of return type and input argument type
>>
>>59529772
How do I read this kind of chart?
>>
how do i get my team to stop bugging me about notices in php? they all have their php.ini file set to maximum error reporting and they think when it gives a big fat yellow notice at the top for testing if a post variable is null that i broke the website. the deployed version won't have any error reporting at all anyways
>>
>>59531314
> cast constness away
> compiler gives a WARNING
It's like C-todlers hate themselves.
>Why is this a problem?
Because
char *function(char const *s) {
return s;
}

int main(int argc, char** argv) {
function("Hello world")[0] = '!'; //UB
}
>>
>>59531314
This means that the data it points to is constant.
For instance,
function("hello");

The string literal is in read-only memory, and if you try to overwrite it you will get a segfault. This is why the string literal has type "const char*". Trying to pretend that it's a mutable string "char*" is dangerous because you might overwrite it now and cause that segfault.

Did you mean to do this?
char* function(char* const s) {
return s;
}

This means that 's' (which points to mutable chars), is not allowed to be changed throughout the function
>>
>>59531377
You're a pig.
>>
>>59531337
Oooh. On stackoverflow people just say to cast it. Is this the correct way to handle it?
return (char*)s;
>>
>>59531396
Yes but why the fuck are you getting rid of const like this? There's practically no good reason to in this scenario
>>
>>59530493
You're maybe right but what should I change to send the whole object ?
>>
File: yoda-bait.jpg (146KB, 500x378px) Image search: [Google]
yoda-bait.jpg
146KB, 500x378px
>>59531396
>>
>>59531392
there's no other way to do it.. you can't initialize the post variable without wiping out the value if it exists
>>
>>59531409
This is the exercise, I don't know what the appropriate return would be.
>>
>>59531295
C's const is really "readonly" (meaning, that memory address can't be legally modified through that identifier, but it can be modified through other identifiers). #define is the way you're supposed to use actual constants. C++'s const is actually const (you can use it to declare sizes of arrays, for example) but unless you need the additional complexity you might as well just use a #define macro.
>>
is functional programming a meme
>>
>>59531439
Maybe.
>>
>>59531427
>initialize the post variable
Why?
>>
>>59531435
Return a pointer to the character that you were searching for. If you were searching for 'm' in "anime" you would point to the 4th character in the string.
>>
>>59531435
Oh that's a retarded function signature wow
I guess you have to cast it.
>>
>>59531463
because >>59531377
>>
>>59531435
Just assume the function should return const char*, it makes no sense otherwise.
>>
>>59531470
That's simple enough, I should've figured that out on my own.
>>
Oh wait this is because C can't deal with covariant/contravariant nature of subtyping, since " an 'int' is also a 'const int' " is a subtyping relation.
e.g. there's no good way to write a safe identity function on pointers in C.
int* my_identity (int* p) { return p; }
...
int x;
int* p = my_identity(&x); // OK
int const y;
int const* q = my_identity(&y); // requires casting

int const* my_identity (int const* p) { return p; }
...
int x;
int* p = my_identity(&x); // requires casting
int const y;
int const* q = my_identity(&y); // OK
>>
#include <iostream>

void fun (const char *str1, char *str2) {
std::cout << str1 << std::endl;
str2[0] = 'X';
std::cout << str1 << std::endl;
}

int main () {
char *str (new char [3]);
str[0] = 'a';
str[1] = 'b';
str[2] = 0;
fun (str, str);
delete [] str;
return 0;
}
>>
>>59531537
Generics are needless bloat. C is the best!
>>
>>59531546
:------------)
>>
>>59531552
>>
>>59531537
int *my_identity(const int *p)
{
return (int *)p;
}

#define my_identity(p) _Generic((p), \
int *: my_identity((p)), \
const int *: (const int *)my_identity((p)) \
)

int main()
{
int a;
const int b;

int *p = my_identity(&a);
const int *q = my_identity(&b);
int *r = my_identity(&b); // Warning
}
>>
>>59531643
GENERICS ARE BLOAT REEE
IF IT ISNT ANSI C COMPLIANT FROM 40 YEARS AGO ITS NOT REAL PROGRAMMING
>>
>>59531643
>generic
>it's just a disgusting macro hack
lol
>>
Is there a decent programming calculator? Something physical, with buttons for hex values, log base 2, bit shift, bitwise logical operations, etc.? Basically, I want the GNOME calculator programming mode, in physical form.
>>
>>59531728
Slide rule
>>
>>59531711
>>it's just a disgusting macro hack
The _Generic feature in C, while not a macro itself, it would only be useful inside of a macro.
>>
>>59531728
Why tho
What's wrong with a REPL of basically any scripting language
>>
>>59531738
I.e. it's a disgusting macro hack.
>>
File: 1489604059286.jpg (86KB, 1280x720px) Image search: [Google]
1489604059286.jpg
86KB, 1280x720px
>fired up Pascal
>such a clear language
I wonder, what could go wrong?
>>
File: vsdebug.png (80KB, 1282x593px) Image search: [Google]
vsdebug.png
80KB, 1282x593px
>>59529672
still working on my debugging back end.
I can debug dos programs in a virtual machine from within visual studio now.
>>
>>59531742
Because I like working out design on a white board or on paper. When calculating offsets, flags, sizes, etc., I don't want to stop what I'm doing to roll back to my computer and break my train of thought, which is what I currently do.
>>
>>59531757
>le macros are bad XDD
Good one.
>>
>>59531837
Text replacement macros certainly are.
>>
>>59531728
I have an HP 11C that I like, but it uses RPN.
>>
>>59531643
>int *r = my_identity(&b); // Warning
Any decent compiler would give you warning for casting away const anyway. No need for C11 autism.
>>
>>59531841
all macros do is replace text...
>>
>>59531858
https://play.google.com/store/apps/details?id=org.ab.x48&hl=en
>>
>>59531865
Therefore...
>>
>>59531643
why bother with the _Generic shit
just use function overloading jesus christ
>>
i-is it safe to use np++ now?
>>
>>59531865
Not in sane languages.
>>
>>59531879
No. Install emacs.
>>
>>59531101
Linus' view on C++ is so dated.
>>
>>59531863
>Any decent compiler would give you warning for casting away const anyway
I know. I was just demonstrating that it will still warn for the "bad" case.
>>
>>59531893
C++ coders are still the worst.
>>
>>59531893
Piling more shit onto C++ over the years hasn't made it any better.
>>
>>59531917
People who say "coders" when they refer to programmers/developers/hackers are truly worse than Hitler.
>>
>>59531890
I'm not really interested in
>hur durr this language is better than that language
The conversation was about C code, and C macros only do text replacement.
>>
>>59531933
C macros are shit.
>>
>>59531928
It most definitively have. Modern C++ has completely made languages like D and Rust obsolete.
>>
>>59531951
D was always obsolete, and Rust solves a different problem.
>>
>>59531879
It's as safe as you deserve to be.
Are you a terrorist or federal criminal? If not, you're safe.
If so, kill yourself.
>>
>>59531890
>muh Lisp macros
>>
>>59531951
>D
D was never relevant to begin with.
>>
>>59531960
>Rust solves a different problem.
Rust essentially just wants to be C++ with type safety.

Modern C++, with stuff like move semantics, is fully type safe.
>>
>>59531373

middle bar is average other bars are outliers
>>
>>59531931
You're so insecure about the term to describe what you do. Have you complex?
>>
>>59531967
>>59531960
D easily could have been the next big thing if they had made the GC optional from the start.

Non-deterministic garbage collection kills any language on embedded platforms.
>>
>>59531877
_Generic is how you would implement function overloading in C, although it's slightly more general than that.
>>
>>59531987
>insecure
I'm not insecure, anon, I merely think "coders" is bad wording.

You're not coding. You're not writing code. The intention of what you write is not to obscure or hide the content.

You're writing instruction, i.e. programming something.
>>
>>59531991
>Optional GC
That shit would never work.
Basically, you would be forced to use it if ANY of the libraries you want to use expects it, defeating the whole "option" of using it.
>>
>>59531971
C++'s move semantics require the type to support a null object. Embarrassing.
>>
I'm trying to play KS on arch but python is acting up. Pls help grand wizards
Full traceback:
File "/usr/share/renpy/renpy/bootstrap.py", line 295, in bootstrap
renpy.main.main()
File "/usr/share/renpy/renpy/main.py", line 419, in main
game.context().run(node)
File "/home/bob/ui_settings.rpyc", line 2, in script
File "/usr/share/renpy/renpy/ast.py", line 814, in execute
renpy.python.py_exec_bytecode(self.code.bytecode, self.hide, store=self.store)
File "/usr/share/renpy/renpy/python.py", line 1715, in py_exec_bytecode
exec bytecode in globals, locals
File "game/ui_settings.rpy", line 21, in <module>
File "/usr/share/renpy/renpy/defaultstore.py", line 92, in __setattr__
renpy.store._set_script_version(value) # E1101 @UndefinedVariable
File "renpy/common/00compat.rpy", line 134, in _set_script_version
config.window_auto_hide.remove("call screen")
File "/usr/share/renpy/renpy/python.py", line 618, in do_mutation
return method(self, *args, **kwargs)
ValueError: list.remove(x): x not in list


And this is the function or whatever from /usr/share/renpy/renpy/python.py
def mutator(method):

def do_mutation(self, *args, **kwargs):

global mutate_flag

mutated = renpy.game.log.mutated # @UndefinedVariable

if id(self) not in mutated:
mutated[id(self)] = ( weakref.ref(self), self._clean())
mutate_flag = True

return method(self, *args, **kwargs)

return do_mutation
>>
>>59532010
I'm a coder. You're an insecure pedantic coder who need to hide behind words.
>>
>>59529672

nice anime microcontroller art you queer
>>
>>59531971
>Rust essentially just wants to be C++ with type safety.
No. The borrowing system isn't just type safety. If you think it is, you haven't spent enough time looking at rust.
>>
>>59532012
Go has optional garbage collection, and /g/ thinks it's the best thing since sliced bread.

There's nothing preventing a library from providing semantics to specify expected behaviour. C++, for example, does this with nothrow and move.
>>
>>59532010
That's like saying a writer isn't a writer, they're a story-teller. I.e., dumb as shit.
>>
>>59531917
Scripting languages are like Java except they've abstracted out the separation of evaluation contexts.

Java is like C++ except it's abstracted out the memory management.

C++ is like C except it's abstracted out the notion of ADTs.

C is like assembly except it's abstracted out the register management.

Assembly is like binary except it's abstracted out the numbers.

Binary is like building a circuit except it's abstracted out the physical wiring and soldering process.

Building a circuit is like using an abacus except it's abstracted out the part where you have to actually move shit with your fingers.

Using an abacus is like counting in your head except it's abstracted out the part where you have to remember what number you're on.
>>
>>59532044
>Assembly is like binary
>binary
Stopped reading right there.
You're a fucking idiot who doesn't know what they're talking about.
>>
>>59531994
>implement function overloading in C
C already has function overloading though???
>>
>>59532016
>having autistic fits about nullptrs
Use boost::optional and boost::maybe then.

>>59532026
>you're hiding behind big fancy words
Learn English, faggot.
>>
>>59532044
What is the link with what I said?
>>
>>59532057
No it doesn't, idiot. It only does if you use _Generic.
>>
>>59532066
Or C++ could grow up and get affine types like Rust for RAII.
>>
>>59532066
>Learn English, faggot.
Idiot.
>>
>>59532056
>Insisting on using the longer term "machine language" just because other uses for the binary number system exist
kys autist
>>
File: 1404947307314.jpg (134KB, 1280x720px) Image search: [Google]
1404947307314.jpg
134KB, 1280x720px
>>59532066
>boost
AHAHAHAHAHAHAHAHAHHHAHAHAH
>>
>>59532042
A writer is a writer.

A programmer is a programmer.

You're neither encoding nor decoding. Coder isn't even a proper noun for fucks sake.
>>
>>59532056
You do realize that assembly is a representation of machine instructions, which are represented as binary, right? If I'm writing something below the level of assembly, I'm using some sort of numerical notation, of which binary is the most direct translation.
>>
How do I work on my side projects when I'm practically falling asleep at the end of the working day?
>>
>>59532085
boost is objectively good. Every feature implemented in C++11, 14 and 17 originated in boost.

/g/ just dislikes it because they can't comprehend how template magic and linking works.
>>
most of the examples of language implementation using racket seem to require racket to run the program on

is it possible to implement an assembler for a foreign architecture in it?
>>
>>59532106
Wait for the week-end.
>>
>>59532067
Notice how C++ is only a 3 out of 8 on this scale of badness.
>>
>>59532118
I don't have weekends.
>>
>>59532086
>Coder isn't even a proper noun for fucks sake.
Neither is programmer or writer...
In any case, you are using code to make a program, the way a writer uses writing to tell a story. You're being a pedantic asshole, and being bad at it.
>>
>>59532117
Sure, but the assembler will have to run on Racket.
>>
>>59532086
I am encoding my PM's design doc into a form which the computer can use.
>>
>>59532104
>which are represented as binary, right
EVERYTHING in a computer is "represented as binary"; that is a completely useless thing to say.
This post is binary. Those nude pics of ur mum is binary. If I'm going to view machine code in "human readable" form, I could easily look at it using hexadecimal, octal, decimal, or whatever number base I choose.
Even then, calling anything in a computer "binary" is misleading as well. We should be talking about high and low voltages.
>>
>>59532086
>proper noun
"Hello everyone, my name is Coder"
"Nice to meet you Coder, I'm Programmer"
>>
>>59532135
>Neither is programmer or writer...
??

They are?

>you are using code to make a program
But you're not. A programming language isn't code.

>a writer uses writing to tell a story.
A writer uses TEXT to tell a story, the act of writing itself doesn't fucking tell a story.
>>
>>59532145
>>59532117
Now you see why nobody takes Lisp seriously. It's not actually useful for doing anything in the real world.
>>
>>59532158
>If I'm going to view machine code in "human readable" form, I could easily look at it using hexadecimal, octal, decimal, or whatever number base I choose.
Yeah, but you SHOULD look at it in binary, because many architectures use 5-bit opcodes. This is also why binary is how machine code is most often examined without disassembling it, which is in turn why "binary" is appropriate shorthand for "machine code."
>>
File: karlie-kloss.gif (2MB, 380x238px) Image search: [Google]
karlie-kloss.gif
2MB, 380x238px
>>59532135
Go kode with kloss if you think a program is some form of secret "code", you little piece of shit.
>>
>>59532158
>EVERYTHING in a computer is "represented as binary"
Yes, and the poster was talking about layers of abstraction. Assembly is indeed an abstraction of binary instructions.
>>
>>59532169
GIMP
>>
>>59532200
>1:1 mapped textual representation is an abstraction
No, it's merely a different representation.
>>
>>59532200
>Muh abstractions
Assembly maps 1-1 onto machine code
>>
>>59532198
Not all codes are secret. Placing a > when placed at the begging of a line encodes for making the line green.
>see
>>
File: assembly.2png.png (74KB, 661x716px) Image search: [Google]
assembly.2png.png
74KB, 661x716px
>>59532220
>>59532215
>muh 1:1 mapping
>>
>>59532220
Is machine code = to micro code?
>>
>>59532189
Why the fuck would you ever examine machine code without disassembling it?
>>
>>59532224
>he thinks > is 4chan code for maymays
>>
>>59532166
>They are?
No, they're not.
https://en.wikipedia.org/wiki/Proper_noun
Is "programmer," or "writer," referring to a class of things, or a specific, individual thing?

>A programming language isn't code.
Yes, it is.
https://en.wikipedia.org/wiki/Code
Do we use source code to represent information?

>A writer uses TEXT to tell a story, the act of writing itself doesn't fucking tell a story.
No more or less so than the act of coding makes a program.
>>
>>59532215
>>1:1 mapped textual representation is an abstraction
Yes. Yes it is.
>>59532220
>Assembly maps 1-1 onto machine code
Yes, it does, in such a way as to abstract it.


Also assembly provides assembler directives, which are not available in machine code
>>
>>59532198
I don't think the words you're using mean what you think they do.
>>
C++ question here:
class fag{
DT& foo() { return someObject};
}

int main()
{
DT bar = fag.foo();
}
how do I get a reference to bar?

if I try to do *(fag.foo()) it fails.

I'm returning an object from a linked list rather than a pointer to that object. I can manipulate the original linked list object by doing this
fag.foo().setSize() etc.
but I'd like to have an object opFag which points to whatever is returned from fag.foo()?
>>
>>59532256
>he puts two greater-than signs on one greentext line
>>
>>59532145
yeah i have no problem with it actually running in racket, but i was just wondering if it could generate binaries for non-racket stuff
>>
>>59532262
>different textual representations are abstractions
They're not.

A French translation of an English text does not mean that French is an abstraction over English.

>Also assembly provides assembler directives, which are not available in machine code
Not all do. Assembler directives are obviously out of band instructions that may constitute an abstraction.
>>
File: lol.gif (1014KB, 290x189px) Image search: [Google]
lol.gif
1014KB, 290x189px
>>59532275
>he uses a broken user-script that doesn't handle multiple >>>>
>>
>>59532274
fag post_59532274 = new fag()
>>
>>59532266
Yeah, sorry. I didn't mean "you little piece of shit", I actually meant "you pathetic waste of resources"
>>
>>59532314
throw NotAnArgument();
>>
>>59532274
DT &bar (fag.foo ())

It is what you want?
>>
>>59532274
DT& bar = fag.foo();

or even better
class fag
{
std::shared_ptr<some_thing> some_object { };
auto foo() { return some_object; }
}

int main()
{
auto bar = fag.foo();
}
>>
>>59532316
Not gonna lie, I love how much this pisses the two of you off.

So tell me, what experience do you have with coding theory?
>>
Some programmers, when confronted with a problem, think "I know, I'll use floating point arithmetic."
Now they have 1.999999999997 problems.
>>
>>59532339
None, because I don't work with cryptography, compression or signal processing.

"Coding theory" is not a fancy word for computer science you know.
>>
>>59532357
>what is precision
>>
>>59532327
yes.

Can you put this into words so next time I know what to google?

I tried "referencing a returned object" but that wasn't quite it.
>>59532330
I'll read up on auto thanks anon.

I understand that & on the return type means "return this object rather than a copy of it"
but what does & mean on declaration?
DT -> declare an object of type DT
DT* -> declare a refernce to an object of type DT
DT& -> ?
>>
>>59532330
>all that extra allocation space for no reason
stop programming in the master language brainlet
>>
>>59532383
Are you the guy that's complaining about how people space their posts as well?
>>
>>59532376
DT &bar (fag.foo ());

bar is a pointer to foo of fag. Modifying bar modify foo of fag

DT bar (fag.foo ());

bar is a copy of foo of fag. Modifying bar does not modify foo of fag
>>
>>59530535
>>59531041
EPPICK XDDDDDDDDDDDDDDDDDDDDDDDDDDDD
>>
>>59532363
lol says the person who interpreted "code is a form of code" as "I'm in a sekret club"
>>
>>59532376
int x = 3;
int& foo() { return x; }

int dt_value = foo(); // deep copies whatever the reference points to, into this variable
int* dt_pointer; = & foo(); // turn the reference into a program, so that we can manipulate it using pointer math. usually not what we want
int& dt_reference = foo(); // set this reference variable to the same reference returned by foo

std::cout << x << std::endl; // 3
dt_value = 4;
std::cout << x << std::endl; // still 3
*dt_pointer = 5;
std::cout << x << std::endl; // 5
std::cout << dt_value << std::endl; // still 3
dt_reference = 6;
std::cout << x << std::endl; // 6

std::cout << ((&dt_reference) == dt_pointer) << std::endl; // 1 (true)
std::cout << ((&dt_valu) == dt_pointer) << std::endl; // 1 (true)
>>
>>59532274
class fag {
DT& foo() {
// The object returned here must not be a non-static local variable declared in this function. Otherwise you'll get memory corruption.
return someObject;
} // You need a semicolon here.

int main() {
DT bar = fag.foo(); // I hope you realize bar is now a COPY of whatever object fag.foo() returned a reference to. It is NOT the original object.
// Furthermore, you need an actual instance of fag before you can call foo on it. You're trying to call foo on the abstract idea of a fag, you need an actual existing fag to call it on instead.
}


Your member function fag.foo() is returning a reference. The asterisk (*) is the dereference operator; it's used to convert pointers into references. By saying *(fag.foo()), you're trying to apply an operator used to convert pointers to references to something that's already a reference.

If you want a reference to bar (bearing in mind that bar is a COPY of fag.foo(), not the original object) then you can just do DT& myRef = bar;. The reference myRef will then be a reference to an object allocated on the callstack. If you want to be able to use references to bar outside of where you declare bar, you need to allocate bar on the heap, so that it will persist after the call to the function that made it terminates, and you won't get memory corruption.

DT& referenceToBar() {
DT* bar = new DT(instanceOfFag.foo());
return *bar;
}


However, keep in mind that the receiver of the reference to bar will need to later use it to deallocate bar from the heap, or else you'll get a memory leak.

int main() {
DT& bar = referenceToBar();
/* do things with bar */
delete &bar;
}


All this is assuming that you did in fact mean for bar to be a COPY of fag.foo(). If you meant for it to be the SAME OBJECT, you should have declared it as DT& bar = fag.foo();, in which case bar IS a reference to bar, as is fag.foo().
>>
>>59532439
*turn the reference into a pointer
*the last line should return 0 (false)

I need to post slower, sorry
>>
>>59532433
I clearly stated that coding is the act of encoding and/or decoding as well in my posts.

You just chose to focus on the code as the purpose of deliberately obscuring or hiding content because you either lack basic reading comprehension or you're a stupid troll.
>>
>>59532287
>They're not.
>A French translation of an English text does not mean that French is an abstraction over English.
If the French was objectively more readable than the English, from all conceivable perspectives, including those of people who speak English and not French, then, yes, the French translation would be an abstraction. Obviously that's not the case in any conceivable French translation of any text. But it IS the case in assembly versus machine code.
>>
>>59532468
In what fucking posts? I never said anything about secret codes, YOU did starting here:
>>59532198
>>
I should make IO functions have some special place in my AST, right?
>>
>>59532470
>If the French was objectively more readable than the English
Assembly isn't "objectively more readable". I work with plenty of people that are able to identify opcodes and operands on the spot by looking at hexdumps.

At best, it's subjectively more readable to you because you aren't accustomed to looking at hexdumps.

It is not an abstraction, it is a translation. If assembly was a literal abstraction, that would imply being able to formulate and express concepts in it that you couldn't do with machine code.

This is clearly the case with C programming, for example, but even remotely with assembly. At best, it provides assembler directives to perform menial tasks (such as fill N bytes with zeros, place this section at this location in memory, use this textual macro to represent this address offset etc), but these are all merely the property of assembly being a "human readable" translation.
>>
File: 1462970641659.png (754KB, 736x715px) Image search: [Google]
1462970641659.png
754KB, 736x715px
An assembler can be thought of as an isomorphic function.
Making the distinction between assembly and machine code then becomes pointless. They can be treated of as the same set.
Assembly "abstracts over" machine code for humans in the same way that machine code "abstracts over" assembly for computers.
>>
>>59532505
That's not me, mate. I'm >>59532086
>>
>>59532540
>treated of as
treated as*
>>
Rate my sieve of eratosthenes!
    char *a = (char *) calloc(LIMIT + 1, sizeof(char));
size_t i, j, sum = 0, sq = sqrt(LIMIT);
for (i = 3; i < sq; i += 2) /* skip even */
if (!a[i])
for (j = i * 2; j < LIMIT; j += i)
a[j] = 1;
>>
>>59532439

int* dt_pointer; = & foo();

Why do I need to add & on foo()? since foo returns an object, why isn't it *(foo())?

Will dt_pointer->x=2 change the value?
>>
>>59532540
>isomorphic
not really, it's many to many
>>
>>59532551
Then why are you replying to this thread, arguing that I'm not representing what you said, instead of the one where I actually responded to you here
>>59532258
>>
>>59532555
>Casting void pointers
>sizeof(char)
>Not declaring loop variables in the for loop
>>
>>59532220
>>59532229

If you have an add after a multiply it will become a fused instruction on most architectures


> what is
>>
>>59532555
>calloc
mixed code and declaration
no braces
useless comments
four spaces indentation
confusion between char and bool
implicit cast

1/20 because you try
>>
>>59532274
I'm trying really hard to understand what you even want right now. Your code, as you have it, should not even be compiling, much less failing at runtime. Here are some basic syntactical fixes to your code. Forgive me if I also clean up some stylistic stuff; I can't help myself.

class fag {
public:
DT& foo() { return someObject; }
};
int main () {
fag instance;
DT bar = instance.foo();
}


To get a reference to bar, you'd do
DT& ref = bar;


Your code, *(fag.foo()), would fail because:
1) fag is a class, not an instance
2) even if you DID have an instance, fag::foo() would already be a reference, you can't dereference something that's already a reference
3) finally, if you COULD dereference something that's already a reference, the result still wouldn't be a reference to bar, but instead a reference to the object from which bar was copied when you declared it as a plain object rather than a reference itself

>but I'd like to have an object opFag which points to whatever is returned from fag.foo()?
You can't have a pointer to a reference because any occurrence of a reference degenerates to an occurrence of the object to which it's a reference
>>
>>59532540

At some point you are going to use abstraction

the line is drawn between assembly and machine code
>>
>>59532579
>Then why are you replying to this thread
Because you literally said "you two", as in you (the poster you responded to) and me (as in the other guy you didn't respond to [me]), in >>59532339 you fucking moron. If you didn't want me to respond, then why did you address me in your post?
>>
>>59532606
If it was addressed to you, I would have linked to your post moron.
>>
>>59532593
>the line is drawn between assembly and machine code
Why? They are equivalent.
The distinction between assembly and a higher level programming language is much more important.
>>
>>59532537
>Assembly isn't "objectively more readable".
it is tho
>I work with plenty of people that are able to identify opcodes and operands on the spot by looking at hexdumps.
I said "objectively more readable," not "objectively readable whereas the other thing is objectively not."

>At best, it's subjectively more readable to you because you aren't accustomed to looking at hexdumps.
No, it's more readable to the people you work with too, just not by as much.

>It is not an abstraction, it is a translation. If assembly was a literal abstraction, that would imply being able to formulate and express concepts in it that you couldn't do with machine code.
On the contrary, if you can formulate and express concepts in a language L that you can't formulate and express in a language M, then L is definitively NOT an abstraction of M, but rather a superset of it.

>This is clearly the case with C programming,
No it's not. There's nothing you can do in C that you can't do in assembly. If there were, then running C would require specialized hardware.
>>
I think you are a moron (yeah, you, the "look at me i'm coding" guy).

I'm clearly not addressing you by not linking to your post, so there's no reason to respond to this. But if you don't respond, that only confirms that you are a moron.
>>
>>59532654
lol idk if english is your second language or you're just new, but I am thoroughly amused right now
>>
>tfw i'm growing accustumed to /dpt/
from my previous experience learning skills with dedicated generals here on 4chan that means i'm about ready to move away from the beginner stage
feels good
>>
>>59532445
I was just dotting down general idea syntax was not meant to be stop on. First time /g/ poster I wasn't actually expecting an answer. Thanks anons.

I wasn't clear on a difference between a pointer and a reference but now it makes a bit more sense.

I did in fact want a reference and not a copy which is how this problem came about.
I was thinking I need to have a DT* in order to achieve that. since pointers... point to things.
Out of curiosity, can I achieve this without using & and just use some combination of *?

DT& bar = fag.foo(); // Makes bar point to memory address returned by fag.foo() function, correct?
isn't bar a pointer then?
>>
>>59532653
>it is tho
It isn't. I'll agree that it is subjectively more readable, but I get confused when I see AT&T syntax for example. So it's not "objectively more readable".

>No, it's more readable to the people you work with too, just not by as much.
It's definitively not when they prefer to read hexdumps.

Not all instruction sets have 80 gorillean different instructions, like x86. Some only have a little over 40 different.

>On the contrary, if you can formulate and express concepts in a language L that you can't formulate and express in a language M, then L is definitively NOT an abstraction of M, but rather a superset of it.
By this reasoning, Lisp would be a superset of C, even though there are Lisp implementations written in C.

>There's nothing you can do in C that you can't do in assembly. If there were, then running C would require specialized hardware.
There are plenty of RISC/ZISC architectures that only implement a subset of proper C because of memory constraints. So C does in fact require specialized hardware.

On the flip side, most programming languages are implemented in C (Python and Java comes to mind). Would they be abstractions or supersets?
>>
>>59532698
Why did you respond? I didn't link to you.
>>
>>59532730
never said you did
>>
>>59532762
Then there were no reasons to respond, you moron. :^)
>>
>>59532628

No they aren't

http://ref.x86asm.net/coder32.html

Notice how there are multiple for each instruction. That's because they are unique for each set of operands you have.

So when you

mov B,c
mov H,L


you are not doing a function call to mov(c,b) and mov(h,l) you are doing two seperate operations

and when you do

multiply c,b
pop


it gets changed to FMULP, a fused multiply and then pop instruction, without you ever having to worry about it
>>
>>59532781
But that's only because the assembler is able to do optimizations. A naive assembler would still do MUL and then POP.
>>
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 0 bytes in 0 blocks
suppressed: 0 bytes in 0 blocks


ah yes, finally
>>
>>59532773
do you not understand how 4chan works?
>>
>>59532781
>Notice how there are multiple for each instruction. That's because they are unique for each set of operands you have.
That's not important. They can still easily be disassembled back to the original.
Just because the human-readable mnemonic looks the same, it doesn't mean that they are the same instruction.
>it gets changed to FMULP
Don't bring optimising assemblers into this. I only mentioned "normal" assemblers.
>>
>>59532709
>isn't bar a pointer then?
It is, kind of. In C++, references are pointers, but they're special kinds of pointers.

1) References are neither *nullable* nor *reseatable*. This means, when you declare a reference, you MUST define what already existing object it points to, and you can't point it to another object later (non-reseatable)--nor can you point it nowhere, neither upon declaration nor afterward (non-nullable).

2) References are *degenerative*. This means, unlike other pointers, you can't manipulate references as data in their own right, because wherever a reference appears in your code, it "degenerates" into the object it refers to. This is convenient because it lets you type '.' instead of '->' to refer to the referenced object's properties, and also prevents accidental pointer arithmetic.
>>
>>59532812
>being this retarded
He's making a fucking point (see >>59532623) and you fell right into his shitty obvious trap, you fucking mongo.
>>
>>59532773
>>59532730
you're ultimately triggered
>>
>>59532721
>It isn't. I'll agree that it is subjectively more readable, but I get confused when I see AT&T syntax for example. So it's not "objectively more readable".
Well okay.

>By this reasoning, Lisp would be a superset of C, even though there are Lisp implementations written in C.
Not at all. You can't formulate and express any concepts in Lisp that you can't formulate and express in C.

>There are plenty of RISC/ZISC architectures that only implement a subset of proper C because of memory constraints. So C does in fact require specialized hardware.
Beside point. C as a whole is a superset of those specific architectures. However, C as a whole is not a superset of the sum of all architectures, nor is the subset of C implemented by any limited architecture a superset of that limited architecture.

>On the flip side, most programming languages are implemented in C (Python and Java comes to mind). Would they be abstractions or supersets?
Abstractions, if they're implemented in C. Definitely not supersets in any case, because if they're implemented in C, then you can formulate and express any concept in C that you can in them.
>>
>>59532540
Just because they are isomorphic doesn't mean that are exactly the same.
They are isomorphic in their resulting behavior, yes, but assembler is easier to write, understand and debug for humans. This is not "pointless"

>Assembly "abstracts over" machine code for humans in the same way that machine code "abstracts over" assembly for computers.
This is interesting; machine code is usually designed with the instruction set in mind. It's almost paradoxical
>>
template <class DT>
DT sort(DT a)
{
DT temp;
.......
}

I have this as a static method. Let's say I do sort(foo) where foo is of type LinkedList<int> or arraylikeClass<int>

My temp will be LinkedList<int> inside the sort(). How would I make a temporary variable of int?
Right now I have overloaded sort(LinkedList<DT>) and sort(arraylikeClass<DT>) to do so but I'd like to have one generic implementation.
>>
File: 1348764844816.png (2KB, 244x226px) Image search: [Google]
1348764844816.png
2KB, 244x226px
>>59532833
>trap
>>
>>59532898
>This is not "pointless"
I didn't say that assembly is pointless. I was saying that the (strong) distinction between them is.
>>
why is not public guys
>>
File: 1432194311104.jpg (1MB, 1920x1200px) Image search: [Google]
1432194311104.jpg
1MB, 1920x1200px
>>59532831

I understand now. Thanks
>>
>>59532889
>You can't formulate and express any concepts in Lisp that you can't formulate and express in C.
You can though.

Lisp machines are true Turing machines. C assumes a finite address space because it requires a bound size for its pointer types. Lisp does not have this restriction (in theory).

So this would make Lisp an abstraction, and not a superset, correct? Then your distinction between supersets and abstractions in >>59532653 is incorrect, because you can formulate and express concepts in language L (here: Lisp) that you can't in language M (here: C).
>>
>>59532930

because it didn't specify it to be public like
class derived: public basex

http://stackoverflow.com/questions/3811424/default-class-inheritance-access
>>
>>59532828

Who uses an assembler that doesn't automatically use a fused instruction when available?

My point is you are compiling object (that takes probably 6 times the memory of machine code) to machine code.
>>
>>59532287
French text is an abstraction over the Latin alphabet.
>>
>>59532961
>French = programming language
>Latin = instruction set of an architecture
That's quite a clever analogy actually, because you can express French using different "instruction sets" (vocally, sign languages, Braille etc).

That would also, however, mean that assembly is not an abstraction. You can't take assembly for x86 and assemble it for ARM, because they are different instruction sets.
>>
>>59532930
Because private is default for classes, *even for inheritance*.

Note the line
class derived : basex {};

The class "derived" actually PRIVATELY inherits from the class "basex" here, meaning anything that was public or protected in basex is private in derived. This contrasts with public inheritance, in which public and protected members of the base class retain their access modifiers, as well as with the rarely discussed protected inheritance, in which public and protected members of the base class are both made protected in the derived.
>>
can anyone suggest a c++ book for some just starting out? not completely new to programming have exp in java though

ty
>>
>>59532762
>>59532730
You're both cunts. Go grab a room and sodomise your shitty little argument
out, away from other humans.>>59532762
>>
>>59532986
Meant Latin alphabet, not Latin as the language Latin.
>>
>>59532831
>wherever a reference appears in your code, it "degenerates" into the object it refers to.
This doesn't help the beginner but: the semantics of C++ are actually that references only "degenerate" into objects when a copy needs to be made. Thus, whenever you see an expression of a variable or a field, this expression initially has a reference type, and it is only accessed (dereferenced) when it is casted into a non-reference type.
struct pt {
int x;
int y;
}

pt p;
// `p` has type `pt&`
// `p.x` has type `int&`

// Therefore
int& r = p.y;
// does not perform any dereferencing, because it never needs to. It just adds the offset for the field `y`.

int z = r;
// this does the dereference, because `int&` is casted into type `int`

// this nearly-invisible, but present change of semantics allows the following to be valid in C++, but not in C
int* k = &(some_cond ? r : z);

// we can think of the & operator as a no-op that promotes a reference into a pointer
A* operator& (A& ref);
// and the * operator as a no-op that demotes the pointer into a reference
A& operator* (A* ptr);
>>
>>59532990
Practical Common Lisp
>>
>>59532990
C++ Primer 5th edition by Lippman is often recommended
>>
>>59532941
>Lisp does not have this restriction (in theory).
Does it have it in practice?

If so, then IN PRACTICE, you can't formulate and express any concepts in Lisp that you can't formulate and express in C.

If not, then Lisp is not an abstraction over C. (At least not the implementations of Lisp that don't feature that limitation.)

>So this would make Lisp an abstraction, and not a superset, correct?
Only in the cases where the limitation is present. If the limitation is absent, Lisp is still an abstraction, but it's an abstraction of something else.

>because you can formulate and express concepts in language L (here: Lisp) that you can't in language M (here: C).
No, you can't, not if the limitation is present. And if it's absent, then the implementation in which it's absent is not an abstraction over C.
>>
>>59531765
Not sure why you'd want to do that, but okay.

>>59532104
>machine instructions, which are represented as binary
Actually, that's implementation-defined.
>>
If you can't formulate and express any concepts from any language in C, those concepts can't even be run on modern computers.
>>
>>59532941
(cont from >>59533037 ) More generally, I can PROVE to you, that if L is an abstraction over M, then you can't formulate and express any concept in L that you can't formulate and express in M.

Proof:
>take the language M
>the language L, as a concept, can be formulated and expressed in the language M (reasoning: it's been done, otherwise L wouldn't exist)
>suppose you have a concept C that you can formulate and express in the language L
>you want to formulate it and express it in the language M
>step 1: go ahead and formulate and express it in the language L
>step 2: formulate and express the language L in the language M
>step 3: feed the expression of C in L into the expression of L in M
>>
>>59529703
this
>>
>>59533037
>Does it have it in practice?
That's really besides the point, the point is that you're able to express something in Lisp that you can't in C because C has a restriction of memory assumptions.

>If so, then IN PRACTICE, you can't formulate and express any concepts in Lisp that you can't formulate and express in C.
Well, in practice, I may actually formulate and express such concepts (even though no current Lisp implementation would be able to run them). That's what we're discussing here, right? I am able to formulate and express concepts in Lisp (for example a recursion loop that fills infinite memory) that aren't possible in C (because C doesn't have support infinite memory).
>>
>>59533078
C isn't even Turing complete.
>>
>>59533118
ok lad
>>
>>59533078
>quantum computers doesn't exist
>>
>>59533117
>(because C doesn't have support infinite memory)
int main () { for (;;) malloc(1); }

This is a well formed program.
>>
>>59533086
>>the language L, as a concept, can be formulated and expressed in the language M (reasoning: it's been done, otherwise L wouldn't exist)
This assumes that L derives from M, which may or may not be the case.
>>
>>59532960
Wouldn't an optimising C (or whatever) compiler already make those sorts of transformations?
>>
>>59533144
That's not the point.
>>
>>59533148
>This assumes that L derives from M, which may or may not be the case.
We know L derives from M, because it's an abstraction over it.
Alternatively, if L does NOT derive from M, then it's NOT an abstraction over it. It's an abstraction over something else.
>>
>>59533144
this basically nukes your computer no matter how much ram you have
>>
>>59533144
It doesn't do the same thing (fill infinite memory).
>inb4 you show me a loop with calloc

My point is that someone can technically implement a Lisp machine that uses an infinite magnetic tape band for memory, whereas C assumes finite memory due to pointers having a bound size.
>>
>>59533167
>We know L derives from M, because it's an abstraction over it.
My argument all along has been that L is not an abstraction over M.

>Alternatively, if L does NOT derive from M, then it's NOT an abstraction over it. It's an abstraction over something else.
That may be so, but that doesn't rule out the fact that assembly and machine code have a relationship (that isn't one being an abstraction over the other).
>>
>>59529672
Is the universe a Lisp Machine?
>>
NEW THREAD!

>>59533197
>>
I need some program ideas which have nevar been dun befor.

Getting quite demotivated learning programming since all the
programming ideas I have came up with have been already done
or substituted by a different configuration of another program.
Doing examples in a C textbook is getting boring.
>>
>>59533173
>C assumes finite memory due to pointers having a bound size
C says very little about the representation of pointers.
It's feasible to imagine a C implementation which has some sort of dynamically sized pointer type.
>>
>>59533206
still better than many other varuiants
>>
>>59533214
>C says very little about the representation of pointers.
>It's feasible to imagine a C implementation which has some sort of dynamically sized pointer type.
sizeof is a bound operator that must terminate.

sizeof(int*) must return the same number every time in your program.
>>
>>59533249
Nothing says that the pointer "information" has to be stored in the same place as the pointer itself.
You could have it point to some dynamically sized block somewhere else.
This is pretty stupid, as you need a pointer to define a pointer, but maybe the implementation has a distinction between a "real" hardware pointer and an "abstract" C pointer.
Now I don't know of any real implementation that does anything remotely like this, and it's all pretty impractical, but I'm saying that I think its _possible_ to create a conforming C implementation like this.
Maybe a C interpreter would do something like this.
>>
>>59533284
But if a and b are pointers, and ((intptr_t)a) == ((intptr_t)b), then *a must change *b exactly, right? How could you possibly format (conforming) semantics so that this isn't true?
>>
>>59533318
intptr_t is an optional type, and not guaranteed to exist.
This implementation would simply not have those.
>>
>>59533318
>>59533325
Actually, I just realised I missed your point.
The compiler would simply never have the "real" pointers be equal, and every pointer defined would be a new allocation.
Any C companions between the two would be of the pointed-to values.
>>
>>59533284
The problem would then occur when you start doing pointer arithmetics and operations that assume contiguous memory (C does). Smaller size pointers cannot hold bigger size pointers etc.
>>
>>59533165

of course
>>
>>59533144
It's perfectly possible for malloc() to fail. In fact, it's possible to have a conforming implementation where malloc() is GUARANTEED to fail every time it's called.
>>
>>59533395
>>59533284
The problem is that the compiler would then never know what to do with sizeof as it could potentially be an infinite size
Thread posts: 323
Thread images: 25


[Boards: 3 / a / aco / adv / an / asp / b / bant / biz / c / can / cgl / ck / cm / co / cock / d / diy / e / fa / fap / fit / fitlit / g / gd / gif / h / hc / his / hm / hr / i / ic / int / jp / k / lgbt / lit / m / mlp / mlpol / mo / mtv / mu / n / news / o / out / outsoc / p / po / pol / qa / qst / r / r9k / s / s4s / sci / soc / sp / spa / t / tg / toy / trash / trv / tv / u / v / vg / vint / vip / vp / vr / w / wg / wsg / wsr / x / y] [Search | Top | Home]

I'm aware that Imgur.com will stop allowing adult images since 15th of May. I'm taking actions to backup as much data as possible.
Read more on this topic here - https://archived.moe/talk/thread/1694/


If you need a post removed click on it's [Report] button and follow the instruction.
DMCA Content Takedown via dmca.com
All images are hosted on imgur.com.
If you like this website please support us by donating with Bitcoins at 16mKtbZiwW52BLkibtCr8jUg2KVUMTxVQ5
All trademarks and copyrights on this page are owned by their respective parties.
Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.
This is a 4chan archive - all of the content originated from that site.
This means that RandomArchive shows their content, archived.
If you need information for a Poster - contact them.