Microsoft SDL и memcpy депрекация
Вы можете определить массив классов (classes) для переключения между классами, здесь ваши два символа-глифа:
const classes = ["glyphicon-volume-off", "glyphicon-volume-up"];
Используя этот код:
const index_b = span.classList.contains(classes[0]);
span.classList.remove(classes[+!index_b]);
span.classList.add(classes[+index_b]);
[1112 ] Вы можете переключаться между двумя глиф-иконками, определенными в массиве, когда нажимаете свою кнопку. Кроме того, я предлагаю либо переместить ваш код в конец ваших тегов (это можно сделать в настройках скрипта), либо добавить прослушиватель событий для DOMContentLoaded, чтобы ваш код знал, как ссылаться на элементы внутри него. [ 1112]
См. Рабочий пример ниже:
var mediaPlayer = document.getElementById('video');
var muteBtn = document.getElementById('mute-button');
const classes = ["glyphicon-volume-off", "glyphicon-volume-up"];
function changeButtonType(btn, value) {
btn.title = value;
btn.className = value;
btn.setAttribute("aria-label", value);
var span = document.getElementById(btn.id).children[0];
const index_b = span.classList.contains(classes[0]);
span.classList.remove(classes[+!index_b]);
span.classList.add(classes[+index_b]);
}
function toggleMute() {
if (mediaPlayer.muted) {
// Change the cutton to be a mute button
changeButtonType(muteBtn, 'volume-off');
// Unmute the media player
mediaPlayer.muted = false;
} else {
// Change the button to be an unmute button
changeButtonType(muteBtn, 'volume-up');
// Mute the media player
mediaPlayer.muted = true;
}
}
7 ответов
Ничто не мешает вам ошибиться в параметрах и в "безопасной" версии. Microsoft, кажется, думает, что вы всегда будете использовать что-то вроде:
errno_t e = memcpy_s (&dstbuff, sizeof(dstbuff), &srcbuff, sizeof(srcbuff));
и проверять ошибку.
Но это помогает только тем, кто не знает, что они делают с языком. На мой взгляд, этой группе людей либо не следует использовать язык, либо им следует изучить, как он работает должным образом.
Такой костыль не принесет им никакой пользы в долгосрочной перспективе, поскольку их код не будет портативный.
Возможно, Microsoft провела некоторый анализ и обнаружила, что было много проблем, вызванных неправильным использованием memcpy () , и они думали, что это исправит. Но если бы это было так,
Вы абсолютно правы. Если вы отслеживаете длину обоих буферов, memcpy безопасно использовать. В противном случае memcpy_s вас не спасет.
Дублирование информации - это всегда плохой дизайн - это просто дает вам больше шансов ошибиться. Когда дело доходит до дизайна API, Microsoft имеет потрясающую репутацию, и в прошлом ее спасло только превосходное качество документации. Утешает то, что они не могут удалить исходную функцию memcpy () - она является частью ANSI C.
You're not missing anything, I think this snippet from the article you linked to pretty much covers it:
If nothing else, memcpy_s makes you think about the size of the target buffer.
Согласно Microsoft, это немного упростит написание проверок качества кода for - вы можете убедиться, что программист не передает одно и то же значение обоим параметрам размера (что многие люди, вероятно, по-прежнему будут делать из-за лени). Другая вещь (на самом деле не связанная с безопасностью кода) заключается в том, что вы можете немного очистить свой код с помощью этого метода, потому что в вашем коде меньше проверок - функция memcpy_s проверит за вас что в целевом буфере достаточно места, что устраняет одну из ваших проверок.
И что самое важное, memcpy_s возвращает код ошибки, указывающий, прошла ли вся копия успешно, но с memcpy в этом нет никакой уверенности. Это то, что, по мнению Microsoft, делает memcpy_s более безопасным, чем memcpy .
Иногда я действительно обнаруживаю, что в мире больше не осталось многих из нас, настоящих программистов, которые видят машину такой, какая она есть, и любят перемещать биты. Немного не по теме, я знаю, но мне нравится точно знать, что происходит, и я определенно не хочу, чтобы какой-либо убогий сборщик мусора ходил в фоновом режиме, отчаянно пытаясь разобрать неаккуратные программисты в грязной куче. Я имею в виду, насколько сложно сопоставить вызовы free () с вызовами malloc () / strdup (), насколько сложно убедиться, что вы выделили достаточно буферного пространства, чтобы знать, что вы можете безопасно вызывать memcpy ()? Ответ: Не очень, но 99,9% программистов действительно не заботится о том, что они делают, потому что они занимаются этим только из-за денег, а не из-за страсти к написанию красивого и умного кода.
End Rant.
C-подобная сборка предназначена для людей, которые знают, что они делают, я не забываю читать что-то подобное прямо от K&R