• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

Programming |OT| C is better than C++! No, C++ is better than C

Ambitious

Member
Does anyone else have issues with a customized prompt with oh-my-zsh? My prompt consists of two lines, and for some reason the second line disappears after a few seconds. It only happens a finite number of times, though:

shell26jry2.png


I launched the shell, and the second line disappeared. I pressed Enter and it happened again. I pressed enter another time, and it did not disappear. Neither did it the next few times. Sometimes, it happens a few more times before the second line stays visible. Sometimes, the issue doesn't occur at all.

But what's with these square brackets showing on the sides? There has to be something wrong with my prompt, no? This is how it's defined:

Code:
PROMPT='%{$fg[blue]%}%n%{$reset_color%} in %{$fg[blue]%}%~%b%{$reset_color%}$(git_time_since_commit)$(check_git_prompt_info)
> '

RPROMPT='%(?.. %{$fg[red]%}%?%{$reset_color%} - )%T'

However, I haven't touched my zsh settings in months. The only thing that changed recently is that I updated oh-my-zsh, so this is likely the cause of this issue. I was wondering whether anyone else here is affected by this.
 

Nelo Ice

Banned
Yep, the second link uses the moderncv package.

Here is a good intro if you haven't used Latex before. Just be aware that Latex can have a very steep learning curve if things don't work the first time around. It's nice if it works but it will you make fail miserably if you encounter the cryptic error-messages and have no idea why you can't build.

Download Miktex, and I recommend Texmaker as editor. The first build of your document could take a bit longer, since it downloads the missing packages on demand.
Thanks for the help. Well this looks like it should be fun. This may give me a headache but it'll probably beat formatting with word.
 
Sorry, can't help you with the prompt, but I've been kind of curious if anyone's done anything to modernize the traditional command line shell. Where the input is an actual text control, and command input and output is displayed in a GUI instead of a text-based interface.

I've been using iPython Notebook for interactive Python development and love it. It's still pretty limited and there's a lot of room for improvement but I hope that development tools expand among these lines. I think the fact that interactive computation tools (and for the most part even text editors) haven't evolved at all since the dawn of the GUI has more to do with stubbornness than any inherent superiority.


Windows comes with a PowerShell "Interactive Scripting Environment" (ISE) app which works okay but it's obviously something that was just slapped together without a lot of thought.
 
Sorry, can't help you with the prompt, but I've been kind of curious if anyone's done anything to modernize the traditional command line shell. Where the input is an actual text control, and command input and output is displayed in a GUI instead of a text-based interface.

I've been using iPython Notebook for interactive Python development and love it. It's still pretty limited and there's a lot of room for improvement but I hope that development tools expand among these lines. I think the fact that interactive computation tools (and for the most part even text editors) haven't evolved at all since the dawn of the GUI has more to do with stubbornness than any inherent superiority.



Windows comes with a PowerShell "Interactive Scripting Environment" (ISE) app which works okay but it's obviously something that was just slapped together without a lot of thought.

If you're on Windows, which it appears you are, try Python Tools for Visual Studio
 
However, I haven't touched my zsh settings in months. The only thing that changed recently is that I updated oh-my-zsh, so this is likely the cause of this issue. I was wondering whether anyone else here is affected by this.
I haven't touched my prompt since installing oh-my-zsh, but I ended up using one of the included themes and the prompt that came with it (agnoster) so mine's still just fine. However, a fellow grad student ended up complaining about something eerily similar to your problem (his prompt and colors both broke with an oh-my-zsh upgrade) sometime within the last month, and he ended up resetting his prompt to the default after trying to get it to work for a few hours.
 

Ambitious

Member
I haven't touched my prompt since installing oh-my-zsh, but I ended up using one of the included themes and the prompt that came with it (agnoster) so mine's still just fine. However, a fellow grad student ended up complaining about something eerily similar to your problem (his prompt and colors both broke with an oh-my-zsh upgrade) sometime within the last month, and he ended up resetting his prompt to the default after trying to get it to work for a few hours.

Not a bad idea, actually. I'm gonna reset my prompt and reassemble it piece by piece until I find the problematic part.
 

Koren

Member
I write this:

Code:
func multiply(a: Float, b: Float,  c: Float) -> Float{
    return a * b * c
}

and I want to go back to this:

Code:
let multiply a b c = a * b * c
And have different operators for floats, ints, complex, etc.? Like *. replace * for floats in CaML? Haskell become also really complicated as soon as you deal with non-integer values...

The problem I have with languages that avoid specifying types is that

- either you finish with a lot of polymorphism, which makes you check types (or methodes availability, duck typing style) afterwards, like in Python ;

- or you quickly have functions that replace operators (or dozen of operators), and you write
Code:
let multiply a b c = MultiplyComplex a ( MultiplyComplex b c ) )
and lose a lot of the simplicity you have with basic, built-in types.

That being said, there's plently of things I like in functionnal languages and miss in other languages...
 
I have a question, me and my groups are making an app and we have tabs for users to navigate. However, we didn't have an indicator that tells us that there are more than three tabs. I was wondering on how to add an arrow indicator that indicates more tabs? I'm using android studios. Also, one of my group members used code for the tabs navigation to work.
 
And have different operators for floats, ints, complex, etc.? Like *. replace * for floats in CaML? Haskell become also really complicated as soon as you deal with non-integer values...

The problem I have with languages that avoid specifying types is that

- either you finish with a lot of polymorphism, which makes you check types (or methodes availability, duck typing style) afterwards, like in Python ;

- or you quickly have functions that replace operators (or dozen of operators), and you write
Code:
let multiply a b c = MultiplyComplex a ( MultiplyComplex b c ) )
and lose a lot of the simplicity you have with basic, built-in types.

That being said, there's plently of things I like in functionnal languages and miss in other languages...
I don't know why something being polymoprhic would ever be bad. You hardly even notice when the compiler can just infer types for you.

Moreover, what you said is true of OCaml, but not F#. In F#, you merely add a static member to the datatype you're implementing and there you go, you've got whatever operator you want defined for that datatype. ]Here's an example for overloading "+" in F#.

In Haskell, Rust, and Scala, you implement their equivalent of an interface for the datatype.

As an example, let's suppose I had a datatype Pair which just represents two numbers. If I wrote out an instance of Num from the standard Prelude, which is just a typeclass which represents things that are "like numbers", then I could write this code:
Code:
let p1 = Pair 20 20
    p2 = Pair -2 18
    p3 = p1 + p2
in p3 == Pair -18 28
Which would evaluate to "True". Are my mathematical operations now polymorphic? Yes. Is this any less clear or simple than having a language without polymorphic operators? No, not at all.

And even if you were using a language without that kind of ad-hoc polymorphism, you could still just provide your own operator. This would work in OCaml, assuming a Complex number datatype was available:
Code:
 let (**) (Complex (a, b)) (Complex (c, d)) = Complex (a *.c  -. b *. d, a *. d -. b *. c) in
    Complex(2.0, 1.0) ** Complex(1.0, 1.0)
Which would yield Complex(1.0, 1.0). I don't see this as being much more than a "minor" annoyance.
 

Koren

Member
I don't know why something being polymoprhic would ever be bad. You hardly even notice when the compiler can just infer types for you.
When there's other people involved, especialy users, it can turn bad. The "other people" can even be you in a couple of years.

For example, let's suppose you've created a function in Python that take a list as an argument. Then someone calls it with a numpy array as the argument. The results can be quite catastrophic. At the same time, testing the argument types is more bothering than simply specifying them in the declaration.

That being said, just to be clear: I'm not against polymorphism (even less against functionnal programming), but in some case, I like the control I get when explicitely specifying types, which provide a safeguard against some kind of errors.

Moreover, what you said is true of OCaml, but not F#.
I haven't found time yet to learn F# (although I've wanted to), so I'll take your word on this.

Code:
let p1 = Pair 20 20
    p2 = Pair -2 18
    p3 = p1 + p2
in p3 == Pair -18 28
Which would evaluate to "True".
I hope it wouldn't ;)

I'm fine with this kind of example... But as much as I love Haskell in many cases, try dealing with non-integers and it becomes quickly harder to code even really easy things.


And even if you were using a language without that kind of ad-hoc polymorphism, you could still just provide your own operator. This would work in OCaml, assuming a Complex number datatype was available:

I don't see this as being much more than a "minor" annoyance.
I don't really mind myself, but I know several professionnal programmers that loathe CaML because of this.
 

Ambitious

Member
Not a bad idea, actually. I'm gonna reset my prompt and reassemble it piece by piece until I find the problematic part.

Uh, it keeps happening even if I completely remove both custom prompts. How strange. I have to check oh-my-zsh's commit log and issue tracker one more time. There has to be something.
 
When there's other people involved, especialy users, it can turn bad. The "other people" can even be you in a couple of years.

For example, let's suppose you've created a function in Python that take a list as an argument. Then someone calls it with a numpy array as the argument. The results can be quite catastrophic. At the same time, testing the argument types is more bothering than simply specifying them in the declaration.
Why would it be catastrophic? In a typesafe language, it would not be.

That being said, just to be clear: I'm not against polymorphism (even less against functionnal programming), but in some case, I like the control I get when explicitely specifying types, which provide a safeguard against some kind of errors.
I agree with this to an extent. The decision in Rust, for example, was to enforce a convention of local type inference because it made inference errors far more tractable. It's just also really nice when writing a higher order function to be able to let type inference do the thinking, so I think that's a bad trade-off.

I hope it wouldn't ;)
... whoops!

I'm fine with this kind of example... But as much as I love Haskell in many cases, try dealing with non-integers and it becomes quickly harder to code even really easy things.
I believe you but I would be very interested to see an example!

I don't really mind myself, but I know several professionnal programmers that loathe CaML because of this.
Having a small syntactic difference between float and integer arithmetic is pretty superficial, but the underlying reason (no overloading via ad hoc polymorphism) is a huge dealbreaker for me.
 

BakedYams

Slayer of Combofiends
From this explanation it probably sounds like static linking is the way to go, but I would strongly advise using dynamic linking unless you have a very very good reason to use static linking. These libraries are installed by default on most peoples' systems anwyay.

If MinGW is using libstdc++-6.dll, then yea you would need to distribute that. If you want to avoid that, the solution is to using static linking as I mentioned just now.

I'll google all this stuff and see what I come up with and come back sensei.

Sorry, I wasn't clear enough... It's an option for the compiler, so you have to put it in your gcc invocation line among other options.

How do you compile your code exactly?

I go through my directory where my .cpp file is on my command prompt (using Windows and not the developer console, just straight up good old command prompt) and just type in g++ filename.cpp -o filename.exe

I have to drag the library into the folder of the directory I'm in so it compiles. Where would I type that in within g++ filename.cpp -o filename.exe

Edit:

So apparently my library isn't found through dynamic linking is what the error is... Must learn dynamic linking but the internet isn't helping...

Edit 2:

The internet has failed me... I need visual studio c++ and I just wanna use a text editor and compiler and not an IDE. Link to walkthrough I found on microsoft's website

Edit 3:

I've thrown myself into the lion's den with this stuff, I think it may be a little too high level for me since it involves making header classes and then try importing the library into that and then call on it from main. Someone hold me... ;_;
 

Koren

Member
Throwing myself into this.

Operator overloading can die in a fire and never come back.
It's so often used badly that I agree to dome extend. When you define a complex class or a rational class, overloading + make more sense to me than using a add method. Overloading == can also sometimes make sense.

Do you think that stl is wrong in overloading [] for std::vector?

I admit I used it far too much at first, and I'm more cautious now. But when it make sense, I think it's a nice thing to have.

The only thing I'd like to be able to burn is templates in C++. Not because the idea is bad, but because the way they had to add it is awful. When you have more code in hxx than in cxx, it's stupid. When you need special case to handle things that could confuse the parser too.

Why would it be catastrophic? In a typesafe language, it would not be.
Because X*2 gives you a list twice as long if X is a list, an an array with values multiplied by two if X is an array.

Because X, X[j] = X[j], X swap two lines if X is a list of lists and duplicate a line if X is a 2D numpy array.

In these examples, you won't have any issue during execution, the types don't change so you can expect that everything went smoothly, but you'll get totallt wrong results with the wrong type.

And possibly kill people because of this...

I believe you but I would be very interested to see an example!
It could be a whole discussion, but for ecample, I remember that Haskell is the only language (out of probably close to 100) where I had troubles computing the mean of values when I learned it.

Having a small syntactic difference between float and integer arithmetic is pretty superficial, but the underlying reason (no overloading via ad hoc polymorphism) is a huge dealbreaker for me.
Again, I don't mind myself, but I'm also fine with specifying types explicitely. It all depends on what I'm coding afterwards.

I understand well that you can like it, but that people don't like it doesn't sound stranger to me...
 

Koren

Member
I go through my directory where my .cpp file is on my command prompt (using Windows and not the developer console, just straight up good old command prompt) and just type in g++ filename.cpp -o filename.exe

I have to drag the library into the folder of the directory I'm in so it compiles. Where would I type that in within g++ filename.cpp -o filename.exe
You just have to add the -static... nearly anywhere on that line... Where you would put a -Wall, -o3, -pg or any useful option.

I'd advice against the cpp extension, btw. It's widely used, but I'm pretty sure it's not an 'official' extension, and the reason why gcc use a C compiler on those files and not a C++ one.

.C .cxx and .c++ are better options.

I prefer the second which is not case sensitive and don't use non-alphanum chars in the filename...
 
It's so often used badly that I agree to dome extend. When you define a complex class or a rational class, overloading + make more sense to me than using a add method. Overloading == can also sometimes make sense.

Do you think that stl is wrong in overloading [] for std::vector?
Other people are allowed to overload operators. Just not you (that's the abstract "you" btw)

The only thing I'd like to be able to burn is templates in C++. Not because the idea is bad, but because the way they had to add it is awful. When you have more code in hxx than in cxx, it's stupid. When you need special case to handle things that could confuse the parser too.
What's funny is some people consider that an advantage. It's crazy. Luckily modules are solving this problem for the most part.

That said, templates are single handedly responsible for saving c++ imo. Just make sure only other people use them, never you (this applies to everyone)
 

Koren

Member
Other people are allowed to overload operators. Just not you (that's the abstract "you" btw)
I can agree with that (if I understand well that overloading should be restricted to people developping core functions of the language)

I still want to be able to use overloading if I develop a "arbitrary length integer" class because I need it in a program and "normal" solutions for it implies half a dozen dependencies and a 500kB executable.

Luckily modules are solving this problem for the most part.
I hope, but they took long enough to arrive...

That said, templates are single handedly responsible for saving c++ imo.
I agree, but I'm not sure it's such great news that C++ was saved instead of investing time in alternatives. I wish the same kind of effort went into D...

Don't take me wrong, I'm more a C++ programmer now than a D one, but that's mostly because the lack of D adoption, and the fact that C++ evolves faster. Maybe I'll use more Rust... (I gave up on Go after a Google developper convinced me in less than 120s than there's stupid things in the language... if even Google developpers refuse to use it, it's not a good sign).

Just make sure only other people use them, never you (this applies to everyone)
During my phd, someone so fond of it nearly forced me to use it everywhere, I'm more than happy letting others use it now. I far prefer inheritance for many of the templace uses.
 
I agree, but I'm not sure it's such great news that C++ was saved instead of investing time in alternatives. I wish the same kind of effort went into D...

Don't take me wrong, I'm more a C++ programmer now than a D one, but that's mostly because the lack of D adoption, and the fact that C++ evolves faster. Maybe I'll use more Rust... (I gave up on Go after a Google developper convinced me in less than 120s than there's stupid things in the language... if even Google developpers refuse to use it, it's not a good sign).

It's kind of a chicken and egg problem. People need the stability that comes with 30+ years of institutional backing behind C++, and nobody is going to adopt something that doesn't have that same level of industry hardness, which of course cannot be obtained without having a certain amount of institutional backing.

Worse, people need to continue improving their billions of lines of code, not replacing them with code from a new language. That doesn't mean D isn't better, it just means that as with so many things, the costs of developing a new language outweigh the benefits. I honestly don't expect to see anything unseat C++ in my lifetime. It might lose market share to other dynamically typed languages like Python etc, but for another language whose point is specifically to be a better alternative to C++, I don't think it's going to happen. Not Rust, not D, not anything else.

Maybe I'm wrong though.
 

Slavik81

Member
You will have to pry vector addition from my cold, dead hands, but God help he who implements dot product as operator*. Some things should be named functions.
 

Somnid

Member
Operator overloading is trash. In fact, I'd like a language that does away with most operators. Really math notation is just an old holdover that was writing optimized for when we had to use chalkboards. With keyboards, autocomplete and copious amounts of RAM it's unnecessary shorthand and should be more reading optimized (which is much of the point of high-level languages anyway). Just have natively implemented functions for those.

var result = 1.Add(2).Subtract(3);
 

Koren

Member
You will have to pry vector addition from my cold, dead hands, but God help he who implements dot product as operator*. Some things should be named functions.
Math doesn't allow multiplication of two columns vector, I don't see why you should allow * overloading in this case.

Now, if you have a class for column vectors and one for line vectors, it *could* make sense providing the other way gives you a 3x3 matrix.

I admit I've done it several years ago, but I wouldn't anymore. It's too error-prone, and a function is a far better solution usually.
 

Koren

Member
Operator overloading is trash. In fact, I'd like a language that does away with most operators.
Python, in a sense...

Operators are just syntaxic sugar. You don't need them.
Code:
In [1]: result = (1).__add__(2).__sub__(3)

In [2]: result
Out[2]: 0

At the same time, I don't think you can forbid them.
 
You will have to pry vector addition from my cold, dead hands, but God help he who implements dot product as operator*. Some things should be named functions.

That's why I said other people are allowed to overload operators, just not you :)

I mean, it's a joke, but as long as you live by this mantra 99.999999% of the time, you'll be fine (and by 99.999999 I mean 100)
 

Koren

Member
That's why I said other people are allowed to overload operators, just not you :)

I mean, it's a joke, but as long as you live by this mantra 99.999999% of the time, you'll be fine (and by 99.999999 I mean 100)

Code:
#include <stdio.h>

int main(int argc, char* argv[]) {
	float v = 99.999999;
	
	fprintf(stderr, "%f\n", v);
}
Prints 100.000000, so I guess you're right ;)
 
Math doesn't allow multiplication of two columns vector, I don't see why you should allow * overloading in this case.

Now, if you have a class for column vectors and one for line vectors, it *could* make sense providing the other way gives you a 3x3 matrix.

I admit I've done it several years ago, but I wouldn't anymore. It's too error-prone, and a function is a far better solution usually.

Code:
template<int N, int M>
class Matrix
{
    template<int S>
    Matrix<N,S> operator*(const Matrix<M, S> &other) const;
};

;-)

I do agree that functions are often a better solution. The only time where I really think you *need* operator overloading is when you want to write a generic function that can operate on Matrices, doubles, ints, etc.

Even then you don't *actually* need it, because if you have a version that takes a predicate, you can supply different predicates for different types.
 

Slavik81

Member
Math doesn't allow multiplication of two columns vector, I don't see why you should allow * overloading in this case.

Now, if you have a class for column vectors and one for line vectors, it *could* make sense providing the other way gives you a 3x3 matrix.

I admit I've done it several years ago, but I wouldn't anymore. It's too error-prone, and a function is a far better solution usually.
I'm not sure what you thought I meant. I was just saying that it pains me to see this:
Code:
// dot product
float operator*(vec2f l, vec2f r) {
  return l.x*r.x + l.y*r.y;
}

Though, on a related note, component-wise multiplication of matrixes is the .* operator in Matlab. It's rather useful for certain things. For example, you can use it for calculating the spectrum of light that bounces back from a surface. Like, for answering "What does redish-green light striking a yellow egg yoke look like?" The actual name for this operation is the Schur product. If it were not built into the language, however, that sort of thing is probably better reserved for a function.
 
I'm not sure what you thought I meant. I was just saying that it pains me to see this:
Code:
// dot product
float operator*(vec2f l, vec2f r) {
  return l.x*r.x + l.y*r.y;
}

Did you know... and I'm not even shitting you... that there is an effort amoung certain people on the standards committee to allow overloading operator .

I mean, what better operator to use for the dot product than operator.? Can't you see it?

Code:
template<typename T, int N>
T operator . (const Vector<T, N, 1> &lhs, const Vector<T, N, 1> &rhs)
{
    // impl
}

Vector<int, 3, 1> foo;
Vector<int, 3, 2> bar;

int baz = foo . bar;
 

BakedYams

Slayer of Combofiends
You just have to add the -static... nearly anywhere on that line... Where you would put a -Wall, -o3, -pg or any useful option.

I'd advice against the cpp extension, btw. It's widely used, but I'm pretty sure it's not an 'official' extension, and the reason why gcc use a C compiler on those files and not a C++ one.

.C .cxx and .c++ are better options.

I prefer the second which is not case sensitive and don't use non-alphanum chars in the filename...

Those options aren't available to me... The "environment" word keeps on being thrown around in forums and that probably isn't set for me which is why -static isn't a internal or external command as the command prompt tells me.
 

Slavik81

Member
You just have to add the -static... nearly anywhere on that line... Where you would put a -Wall, -o3, -pg or any useful option.

I'd advice against the cpp extension, btw. It's widely used, but I'm pretty sure it's not an 'official' extension, and the reason why gcc use a C compiler on those files and not a C++ one.

.C .cxx and .c++ are better options.

I prefer the second which is not case sensitive and don't use non-alphanum chars in the filename...
*.cpp is fine. I use *.cxx, but *.cpp pretty common. It's used by major projects like Qt and is mentioned in the GCC manual. I don't think the C++ standard specifies anything about file names, so that's about as good as it gets.

GCC Manual said:
3.2 Options Controlling the Kind of Output
For any given input file, the file name suffix determines what kind of compilation is done:
file.c
----C source code that must be preprocessed.
file.cc
file.cp
file.cxx
file.cpp
file.CPP
file.c++
file.C

----C++ source code that must be preprocessed. Note that in &#8216;.cxx&#8217;, the last two letters must both be literally &#8216;x&#8217;. Likewise, &#8216;.C&#8217; refers to a literal capital C.
https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html
 
Those options aren't available to me... The "environment" word keeps on being thrown around in forums and that probably isn't set for me which is why -static isn't a internal or external command as the command prompt tells me.

Compiling a static library:

Code:
g++ mylib.cpp -static -o mylib.lib

Compiling an executable:

Code:
g++ myapp.cpp -o myapp.exe

Compiling an executable and linking to mylib.lib if it's in the same directory:

Code:
g++ myapp.cpp -lmylib.lib -o myapp.exe

Compiling an executable and linking to mylib.lib if it's in a different directory:

Code:
g++ myapp.cpp -lmylib.lib -Lc:\foo\libdir -o myapp.exe

Note: None of these probably work because I don't use gcc and I don't really know the command line options off the top of my head, but this should get you close.

*.cpp is fine. I use *.cxx, but *.cpp pretty common. It's also supported in the GCC manual.
.cc is also widely used.
 

Kickz

Member
Just started my first soft dev job on Monday as a jr .Net developer.
Still in early days of getting trained on their existing code stack. One thing that has been bugging me is instead of having me shadow their senior .Net guy, they are making me work with their database guy and having me learn how to stage database migrations.. Kinda seems like what a database dev would do or something, I am afraid if I might get stuck in a "database role" and don't get to do much developement using C# on their in house webapp...
 

Makai

Member
Operator overloading is trash. In fact, I'd like a language that does away with most operators. Really math notation is just an old holdover that was writing optimized for when we had to use chalkboards. With keyboards, autocomplete and copious amounts of RAM it's unnecessary shorthand and should be more reading optimized (which is much of the point of high-level languages anyway). Just have natively implemented functions for those.

var result = 1.Add(2).Subtract(3);
There's always Lisp and COBOL
 
Operator overloading is trash. In fact, I'd like a language that does away with most operators. Really math notation is just an old holdover that was writing optimized for when we had to use chalkboards. With keyboards, autocomplete and copious amounts of RAM it's unnecessary shorthand and should be more reading optimized (which is much of the point of high-level languages anyway). Just have natively implemented functions for those.

var result = 1.Add(2).Subtract(3);

I'm not sure if this is serious, but as someone who really hates operator overloading, this has got to be one of the weirdest ideas I've ever seen :-/
 

Water

Member
Operator overloading can die in a fire and never come back.

I find it uncomfortable to work in a language without it. With math-heavy graphics or game logic code, the closer it is to standard math notation, the easier it is to think about, to shift between working out the formulae on paper and modifying code, and to spot discrepancies.

I also don't remember ever seeing a problem with overloading in practice. Are there serious arguments against it if we can assume there is no bad programmer on the team to abuse it?
 

Koren

Member
Those options aren't available to me...
Err... It's just not possible, I use them on MinGW myself and sometimes this option.

Just look what I get on my Windows laptop:
>>> /usr/bin/i686-w64-mingw32-g++ testopt.cxx -o testopt

>>> ./testopt.exe
testopt.exe: error while loading shared libraries: libstdc++-6.dll: cannot open shared object file: No such file or directory

>>> /usr/bin/i686-w64-mingw32-g++ -static-libstdc++ testopt.cxx -o testopt

>>> ./testopt.exe
Hello World

I'm not sure what you thought I meant. I was just saying that it pains me to see this:
Code:
// dot product
float operator*(vec2f l, vec2f r) {
  return l.x*r.x + l.y*r.y;
}
Yes, I understood. Or at least I think so...

What I meant is that if X is a 3-line, 1-column matrix (id est a vector) and Y is also a 3-line, 1-column matrix, X*Y is invalid in maths.

But transpose(X)*Y is the dot product, so if X2 is a 1-line 3-column matrix, X2*Y makes sense. But Y*X2 should return a 3x3 matrix.

What I meant is that I'm not fond of a*b to translate into transpose(a)*b, ilke it's done in your example. I'm not fond of the element-by-element multiplication either, in fact. Especially with implicit loops like int Matlab/Scilab/Numpy, although at least in Matlab/Scilab it makes some sense.


I mean, what better operator to use for the dot product than operator.? Can't you see it?
What? Somebody really used operator. for that?


*.cpp is fine. I use *.cxx, but *.cpp pretty common. It's used by major projects like Qt and is mentioned in the GCC manual.
Sorry, forget that, then. That's actually good to know.

But I'm positive that the GCC manual was saying that cpp was a *C* file extension. That may be some time ago, but the reason I'm using cxx since. It took me some time to understand why my code was not compiling with gcc before realizing that it was compiling with g++ and it was just an automatic classification error.
 

Somnid

Member
There's always Lisp and COBOL

You could implement this in several languages but I don't know of anything where this is the first-class and only way of doing things.

I'm not sure if this is serious, but as someone who really hates operator overloading, this has got to be one of the weirdest ideas I've ever seen :-/

It is definitely weird because nobody does it but I like the idea of simplifying what is generally a special case of function into actual functions. That's probably why so many languages have operator overloading, people want to think of them the same way but because they don't change for the most part it's too easy to expect them to be static.

I guess another idea would be the reverse, users start defining their own operators. A good unicode editor could probably make this work better as you'd have actual symbols to work with.

Did you know... and I'm not even shitting you... that there is an effort amoung certain people on the standards committee to allow overloading operator .

I mean, what better operator to use for the dot product than operator.? Can't you see it?

Code:
template<typename T, int N>
T operator . (const Vector<T, N, 1> &lhs, const Vector<T, N, 1> &rhs)
{
    // impl
}

Vector<int, 3, 1> foo;
Vector<int, 3, 2> bar;

int baz = foo . bar;

Sure why not? Let's add keyword and syntax overloading while we're at it. Anything can do anything!
 

upandaway

Member
I like operator overloading for mathematical stuff but my homework keeps asking me to override operators for dubious reasons (combining two movies into one longer movie for example) just to practice overloading, which is just giving everyone bad habits.

Overloading () in C++ though is the worst. It's so confusing and I don't feel like it adds anything that couldn't have been done better with more specific syntax
 

Koren

Member
Sure why not? Let's add keyword and syntax overloading while we're at it. Anything can do anything!
I haven't played with this recently, but how many C compilers raise an error if you ask the preprocessor to redefine keywords?

^_^

I'm sure some languages allow it. I haven't done much Forth recently, but can't you do it in Forth?
 

Somnid

Member
I haven't played with this recently, but how many C compilers raise an error if you ask the preprocessor to redefine keywords?

^_^

I'm sure some languages allow it. I haven't done much Forth recently, but can't you do it in Forth?

There's gotta be some academic/toy language that does this. The "power" and "flexibility" are just too enticing.
 
I like operator overloading for mathematical stuff but my homework keeps asking me to override operators for dubious reasons (combining two movies into one longer movie for example) just to practice overloading, which is just giving everyone bad habits.

Overloading () in C++ though is the worst. It's so confusing and I don't feel like it adds anything that couldn't have been done better with more specific syntax

It's like I said earlier. Only other people are allowed to overload operators, never you. For example, i think we can all agree std::function is a great use of operator (). But that's only because someone else thought of it, and they Know What They're Doing.
 
There's gotta be some academic/toy language that does this. The "power" and "flexibility" are just too enticing.

Scheme has an explicit language mechanism - the define-syntax special form - for creating new syntax, which I think is quite close in spirit what you are referring to. The Lisps in general have many different mechanisms for this kind of syntactic manipulation, owing to their homoiconicity. The design of C and C derived languages leaves a lot to be desired when compared against the Lisps in the area of metaprogramming. Scheme also, unfortunately, fit the description of 'academic/toy' language. I don't know of any widely used programs written primarily in Scheme.
 
Top Bottom